Hi,
The Cargo.toml specifies u64_backend for default features and u32_backend for the wasm feature.

When adding a new feature such as features = ["serde"] would you prefer u32 or u64 i.e.
32

serde = ["ed25519-dalek/u32_backend", "serde_crate"]

64

serde = ["ed25519-dalek/u64_backend", "serde_crate"]

It is worth considering that a new feature like serde may be used a) in isolation or b) in conjunction with another feature like the wasm feature. This leads me to believe that a new feature like the serde feature should use u32_backend. Happy to be guided by you on this though.

Kind regards
Tim

I noticed that our cache sizes are getting pretty big.

According to https://levans.fr/rust_travis_cache.html, Travis is caching all old versions of our dependencies, so that number will only get bigger over time. Since Travis has to fetch and unpack that cache each build, it may not be saving more time than it's costing -- at least at some point it won't.

We should try a PR with the caching policy adjusted and see how things perform.

I'm following the single hop example and would like to store the encrypted_val in some persisted datastore.

How can I serialized and then deserialize this structure to store on disk and then decrypt later?

Snippet in question

let encrypted_val = recrypt
    .encrypt(&pt, &initial_pub_key, &signing_keypair)
    .unwrap();

In order to optimize WASM builds we should export a feature from Recrypt that allows us to toggle the appropriate features for ed25519-dalek to use their 32 bit backend instead of the 64 bit default backend. This will allow us to reduce the size of the generated WASM binary since it only supports 32 bit. As part of this we also notices that the clear_on_drop no-cc feature was somehow getting enabled for all builds, which isn't what we want.

We currently have a .cargo/config file of

rustflags = ["-C target-cpu=native"]

This is not of the correct format and is therefore being ignored. To test, you can compile with the existing file, change native to gibberish, re-compile, and note that no compilation is necessary.

If this is a feature we'd like to use (and I don't see a reason not to), the file should be:

[build]
rustflags = "-C target-cpu=native"

We should also discuss if other repos could benefit from this.

Hi,
I am receiving the following error when compiling my application. The error is as follows.

Error

error: failed to run custom build command for clear_on_drop v0.2.3

Please see below for the verbose error.

Rust source code

// Recrypt
use recrypt::prelude::*;

// Serde
use serde::{Deserialize, Serialize};
use serde_json;

// Bindgen
use wasm_bindgen::prelude::*;

#[no_mangle]
#[wasm_bindgen]
pub fn generate_key_pair() {
    let mut recrypt = Recrypt::new();
    let (priv_key, pub_key) = recrypt.generate_key_pair().unwrap();
}

Cargo.toml dependencies

[dependencies]
serde = { version = "^1.0", features = ["derive"] }
serde_json = "^1.0"
wasm-bindgen = "^0.2"
recrypt = "0.11.0"

Verbose error message

error: failed to run custom build command for `clear_on_drop v0.2.3`

Caused by:
  process didn't exit successfully: `/media/nvme/wasm-learning/example/target/release/build/clear_on_drop-11c6cc1c8c572c26/build-script-build` (exit code: 1)
--- stdout
TARGET = Some("wasm32-unknown-unknown")
OPT_LEVEL = Some("3")
HOST = Some("x86_64-unknown-linux-gnu")
CC_wasm32-unknown-unknown = None
CC_wasm32_unknown_unknown = None
TARGET_CC = None
CC = None
CFLAGS_wasm32-unknown-unknown = None
CFLAGS_wasm32_unknown_unknown = None
TARGET_CFLAGS = None
CFLAGS = None
CRATE_CC_NO_DEFAULTS = None
DEBUG = Some("false")
running: "clang" "-O3" "-ffunction-sections" "-fdata-sections" "-fPIC" "--target=wasm32-unknown-unknown" "-Wall" "-Wextra" "-o" "/media/nvme/wasm-learning/example/target/wasm32-unknown-unknown/release/build/clear_on_drop-1cd78e41925c3a8c/out/src/hide.o" "-c" "src/hide.c"
cargo:warning=error: unable to create target: 'No available targets are compatible with this triple.'
cargo:warning=1 error generated.
exit code: 1

--- stderr


error occurred: Command "clang" "-O3" "-ffunction-sections" "-fdata-sections" "-fPIC" "--target=wasm32-unknown-unknown" "-Wall" "-Wextra" "-o" "/media/nvme/wasm-learning/example/target/wasm32-unknown-unknown/release/build/clear_on_drop-1cd78e41925c3a8c/out/src/hide.o" "-c" "src/hide.c" with args "clang" did not execute successfully (status code exit code: 1).



warning: build failed, waiting for other jobs to finish...
error: build failed
Error: Compiling your crate to WebAssembly failed
Caused by: failed to execute `cargo build`: exited with exit code: 101
  full command: "cargo" "build" "--lib" "--release" "--target" "wasm32-unknown-unknown"

As a developer
I want to be able to measure the effect various changes have on the performance of recrypt's public API

AC:

• - generate_key_pair
• - generate_ed25519_key_pair
• - generate_plaintext
• - generate_transform_key
• - compute_public_key
• - derive_symmetric_key
• - encrypt
• - transform_to_level_1
• - transform_to_level_2
• - transform_to_level_3
• - decrypt_from_level_0
• - decrypt_from_level_1
• - decrypt_from_level_2
• - decrypt_from_level_3

optional:

• - surface performance numbers in the README

We currently have a way to generate the key pairs for ed25519, but don't have a way for external users to sign and verify using them.

impl PrivateSigningKey {
  fn sign<A:Hashable>(&self, message:&A) -> Signature;
}

impl PublicSigningKey {
  fn verify<A:Hashable>(&self, message:&A, sig:Signature) -> bool;
}

This is roughly what we should add.

Make any breaking API changes to cleanup recrypt from an external perspective. Consuming this library has shown a few things that could be improved. We should get all of these to a good state and break things one last time before publishing 1.0.0.

Using the 256-bit Recrypt API requires several common imports. It would be nice if these were provided as a prelude. This should not be everything, but simply a minimal set of imports to get going.

Usage should look something like
use recrypt::prelude::*;

All the derived eq operations are not constant time. HomogeneousPoint and TwistedHPoint also are not constant time. We shouldn't need any of them for our algorithms, but will need them for the tests. Either we need instances in tests or we should make them constant time.

We use one and zero all over the place to great effect, but the traits force the implementation of is_one and is_zero.

We should either comment on them warning about this issue, or we should remove them... That would lead to errors that people wouldn't expect so I'd recommend the former.

Why is the length of plaintext fixed

In Recrypt Scala/JS we exposed a method createTransformKeyBytes which took a transform key and returned raw bytes in a particular order. This is to be able to sign over TransformKeys and be able to verify them by knowing the order of the bytes being signed. This functionality doesn't yet exist within Recrypt Rust.

One option would be to just expose Hashable to the public API and have a toBytes on TransformKey. The bigger question then becomes whether we expose this for all types or just limit it and only expose it in places where we think it's needed.

If you take 2 private keys and add them together using +, it will not work with the public keys which are created from the resulting PrivateKey.

This is because the keys are cyclic in Fp, but the curve order is Fr. This means that when we want to augment PrivateKeys for Private Key Rotation, we need to instead rotate them in Fr instead of Fp.

https://blog.rust-lang.org/2019/02/28/Rust-1.33.0.html

... and update dependencies

In order to publish our WebAssembly bindings, we need to consume the currently unreleased version of the rand crate which will be published as 0.6. There are a number of breaking changes but we've proved that they work so the changes shouldn't be too difficult.

rust-random/rand#520

We should decide if we want Debug implementations on secret data. Patrick was removing it as part of his memory protections PR, but I think it warrants a larger discussion.

We've discussed that we could conditionally remove the Debug as part of a feature flag, which would allow people who don't want to be able to use Debug in their codebases while still allowing it for others. This feature could be on by default if we wanted to be safe by default (which is always a good goal).

Even if we do remove it, logging the bytes is still possible with {:?}, prv_key.bytes().

Prep and cleanup to be able to ship 1.0.0 of recrypt.

• Settled public API
• Cleanup of README/documentation
• Consume from bindings to make all those 1.0.0 releases.

We should write a function + that takes a 2nd PrivateKey and adds the underlying numbers together.
Also add - for subtracting them.

We should mention in the recrypt Scala repo the state of things and how the Rust SDK has somewhat subsumed the Scala repo.

Currently we're using double/add which is very clearly not constant time. In order to get to constant time we can use Mongomery laddering algorithm without secret-dependent branches.

(r0, r1) <- (0, P)
for each bit of n from next to MSB down to LSB
   constant_time_swap_if(r0,r1,bit)
   r0 = r0 + r1
   r1 = r1.double()
   constant_time_swap_if(r0,r1, bit)

return r0

I think that's roughly the algorithm we want...

Since gridiron >= 0.4 provides constant time primitives, we should be able to implement HomogeneousPoint double in constant time.

stdweb is unmaintained

The author of the stdweb crate is unresponsive.

Maintained alternatives:

• wasm-bindgen
• js-sys
• web-sys

See advisory page for additional details.

Readme cleanup, additional explanations, etc.

Documentation cleanup of anything we find that should be improved.

ironoxide should, ideally, provide better in memory security measures for private keys and other sensitive data types.

Starting points for research:

• https://users.rust-lang.org/t/handling-sensitive-data-in-memory/14388
• https://github.com/quininer/memsec
• https://github.com/quininer/seckey
• https://github.com/stouset/secrets
• https://github.com/myfreeweb/secstr

the encrypted message must be in GT, if I set the message in F_p^12, encryption, re-enryption, and decryption still works. So
(1) why we can not set the message in F_p^12?
(2) In your scheme, how to solve the problem? If we randomly choose the message in F_p^12, and use some method to convert the message into GT(M), then set the symmetric key to SHA256(M). I want to know whether there is an efficient way for client to generate symmetric key instead of generating by us.

Does sharing the sigKeys.privateKey with the party who is running generateTransformKey leak any information?

I'd like to have person A encrypt data and then let person B receive a userToDeviceTransformKey and do the transformation and decrypt.

If person B has the sigKeys.privateKey could they potentially decrypt the cipher without transforming it?

Use of lazy_static 1.2 is blocking downstream from updating other dependencies.

Check other deps as well. Except rand. Leave rand alone.

We should see how much work it would take to try and get recrypt to compile without the Rust standard library. This would make it much more portable and let it work in environments such as Alpine linux. Probably a feature flag and not something we'd do by default. This ticket will just be the investigation work and we'll write up subsequent tickets on things to change if the investigation goes well.

to_fp2 being none is an error condition which represents the algorithm not being correct. In all cases we just panic and so to make it constant time we should just return the final fp2 elem.

Maybe we should have debug asserts to verify that the other elements are zero to ensure we haven't broken something?

Now that we have complete algorithms for add/double we can take out the special cases for neg.

Should have more tests that run hard-coded values through the recrypt algorithms to verify that the expected outputs are produced. For example:

• For a fixed RNG (all zeroes, all ones, or a known sequence of some kind), make sure we get the expected value from GeneratePlaintext
• For a fixed RNG, make sure we get the expected output from GenerateKeyPair
• For a fixed RNG and fixed input, make sure we get the expected TransformKey

Similar checks for encrypt operations and transform operations.

Hi,
Just wondering if recrypt could cargo publish so that recent changes i.e. the new 32/64 backend features in the Cargo.toml and the Serde documentation etc. are made available via crates.io?
Thanks so much!

To date we've been relying on people making different versions of the recrypt api to do multi-threading. It would be better if we made that a part of the base library.

Clint's done some work on #77

We should stay in montgomery form as long as we're in our internal types. This should speed up things ~40%.

We do not want/need to make all the multiplications times known constants be constant time. They can reveal the constant. We should add comments saying that it does indeed reveal the constants.

Note that these cannot reveal the secret values only the u32.

As a user, I want my secrets are zero'd out when no longer needed so that attackers can't easily grab them.

AC:

• PrivateKey, PrivateSigningKey and (probably) "K" values we unroll should take this approach

It would be nice to keep up with new rand versions.

The major hurdle to upgrading is that we have dependencies that don't want to upgrade.

Perhaps we can import two different versions of rand and re-work things so that recrypt holds a separate RNG for ed25519? It would take some experimentation to see if this is possible.

This paper specifies for single-hop but multi-hop may follow. The major contribution is reducing single-hop re-encryption to DLog without pairings.

https://eprint.iacr.org/2018/1136

A Provably-Secure Unidirectional Proxy Re-Encryption Scheme Without Pairing in the Random Oracle Model

S. Sharmila Deva Selvi and Arinjita Paul and C. Pandu Rangan

Abstract: Proxy re-encryption (PRE) enables delegation of decryption rights by entrusting a proxy server with special information, that allows it to transform a ciphertext under one public key into a ciphertext of the same message under a different public key. It is important to note that, the proxy which performs the re-encryption learns nothing about the message encrypted under either public keys. Due to its transformation property, proxy re-encryption schemes have practical applications in distributed storage, encrypted email forwarding, Digital Rights Management (DRM) and cloud storage. From its introduction, several proxy re-encryption schemes have been proposed in the literature, and a majority of them have been realized using bilinear pairing. In Africacrypt 2010, the first PKI-based collusion resistant CCA secure PRE scheme without pairing was proposed in the random oracle model. In this paper, we point out an important weakness in the scheme. We also present the first collusion-resistant pairing-free unidirectional proxy re-encryption scheme which meets CCA security under a variant of the computational Diffie-Hellman hardness assumption in the random oracle model.

Category / Keywords: public-key cryptography / Proxy Re-Encryption, Random Oracle Model, Chosen Ciphertext Security, provably secure, unidirectional.

We are required to announce the use of our patented technology, so we should add mentions to the README.

Patent numbers:

US10,659,222
US11,146,391

WO2018201062A1
KR2020027921A
EP3616384 A4

Implement PartialEq.eq for PrivateKey, Plaintext, DerivedSymmetricKey using a constant time function.

AC:
[ ] These three types all have PartialEq.eq implementations.
[ ] The implementations are data-invariant / constant time - the evaluation of the equality between two values of the same type will always execute the same number of operations, regardless of the contents of either value.

Hi,
Getting one single error on this PR.

The PR has been updated with the new backend features (then rebased with master etc.). No conflicts now, and all of the code related tests pass.

Just not sure what the additional .github/... "Files changed" and githubGithubException error pertains to.
Any help would be greatly appreciated.

 Run harupy/comment-on-pr@c0522c42s
github.GithubException.GithubException: 403 {"message": "Resource not accessible by integration", "documentation_url": "https://developer.github.com/v3/issues/comments/#create-a-comment"}
Run harupy/comment-on-pr@c0522c4
/usr/bin/docker run --name c27d3120b9ecbd68154e9a9b2dec1d8f765e55_b9eee0 --label c27d31 --workdir /github/workspace --rm -e GITHUB_TOKEN -e INPUT_FILENAME -e INPUT_DOMAIN -e HOME -e GITHUB_JOB -e GITHUB_REF -e GITHUB_SHA -e GITHUB_REPOSITORY -e GITHUB_REPOSITORY_OWNER -e GITHUB_RUN_ID -e GITHUB_RUN_NUMBER -e GITHUB_ACTOR -e GITHUB_WORKFLOW -e GITHUB_HEAD_REF -e GITHUB_BASE_REF -e GITHUB_EVENT_NAME -e GITHUB_WORKSPACE -e GITHUB_ACTION -e GITHUB_EVENT_PATH -e RUNNER_OS -e RUNNER_TOOL_CACHE -e RUNNER_TEMP -e RUNNER_WORKSPACE -e ACTIONS_RUNTIME_URL -e ACTIONS_RUNTIME_TOKEN -e ACTIONS_CACHE_URL -e GITHUB_ACTIONS=true -e CI=true -v "/var/run/docker.sock":"/var/run/docker.sock" -v "/home/runner/work/_temp/_github_home":"/github/home" -v "/home/runner/work/_temp/_github_workflow":"/github/workflow" -v "/home/runner/work/recrypt-rs/recrypt-rs":"/github/workspace" c27d31:20b9ecbd68154e9a9b2dec1d8f765e55
Traceback (most recent call last):
  File "/entrypoint.py", line 99, in <module>
    main()
  File "/entrypoint.py", line 95, in main
    pr.create_issue_comment(new_comment)
  File "/usr/local/lib/python3.7/site-packages/github/PullRequest.py", line 443, in create_issue_comment
    "POST", self.issue_url + "/comments", input=post_parameters
  File "/usr/local/lib/python3.7/site-packages/github/Requester.py", line 319, in requestJsonAndCheck
    verb, url, parameters, headers, input, self.__customConnection(url)
  File "/usr/local/lib/python3.7/site-packages/github/Requester.py", line 342, in __check
    raise self.__createException(status, responseHeaders, output)
github.GithubException.GithubException: 403 {"message": "Resource not accessible by integration", "documentation_url": "https://developer.github.com/v3/issues/comments/#create-a-comment"}

As a user of the Revealed wrapper for sensitive recrypt types
I want to be able to test for equality of a Revealed type without be forced to clone() the target struct

Upfront reminder that usage of Revealed means that the wrapped type is less protected against side-channel attacks. Use of Revealed should be limited and thoughtful.

A prime example of this is the implementation of Revealed for api::Privatekey

impl PartialEq for Revealed<PrivateKey> {
    fn eq(&self, other: &Revealed<PrivateKey>) -> bool {
        self.0.bytes[..] == other.0.bytes
    }
}

If this were instead defined as

impl PartialEq for Revealed<&PrivateKey> {
    fn eq(&self, other: &Self) -> bool {
        self.0.bytes() == other.0.bytes()
    }
}

The second implementation avoids the caller having to clone their type into the Revealed wrapper. Since this is sensitive data, fewer clones is good (not to mention the runtime cost of clone)

It might also be good to say that Revealed can only contain references:

pub struct Revealed<'a, T>(pub &'a T);

normalize returning option causes some algorithms to have or_else for decisioning. When we use this in constant time algorithms we should instead just normalize and return x,y.

Maybe this means we have 2 normalize functions for when we need to detect the zero point?

A good starting point is what we are doing for gridiron. https://github.com/IronCoreLabs/gridiron/actions/runs/83301015
AC:

• show Linux, OSX, Windows, Android, iOS comparability
• run tests and benches on at least some architectures

On Travis we run the before/after benchmarks on Linux. There is value there, but sometimes because the machine is shared the results can give false positives. Probably shouldn't be handled here, but we could run the benches on some dedicated machine somewhere as that's something GA supports.

Open questions:

• should we build with and without the wasm feature?
• what targets do we want to run tests on?

@clintfred commented on Mon Oct 08 2018

Now that we have #4 we should have benchmarks running consistently, somewhere. It looks like there has been some success in running benchmarks on Travis, even though it's not ideal. Hopefully criterion's statistical analysis will make the results somewhat reasonable.

https://beachape.com/blog/2016/11/02/rust-performance-testing-on-travis-ci/
https://sunjay.ca/2017/04/27/rust-benchmark-comparison-travis

We recently changed the library to expose the RecryptErr type which was accidentally not being exposed out of the library. Now I noticed that we have the same problem with the Ed25519Error type. From what I can tell it's only ever used as part of the SigningKeypair methods, so maybe the better path forward here would be to get rid of it in favor of the RecryptErr type.