I noticed this request/issue < https://github.com/IronCoreLabs/recrypt-rs/issues/89 > , by @drbh , which mentioned being able to serialize and deserialize recrypt data structures (to store on disk etc.)

I notice that @clintfred mentioned (in the aforementioned feature/issue) that "We would consider a PR for this, but it's not a priority at this point".

Please consider the following PR and advise on what is required to successfully merge this new functionality.

What does this PR provide?

The aim of this PR is to provide users of recrypt-rs with a JSON/String representation of recrypt generated keys (PublicKey struct, PrivateKey struct etc.)

How does it work?

To enable a feature called serde (to their application), users of recrypt will simple update their Cargo.toml to include this new feature.

recrypt = { version = "~0.11.0",  features = ["serde"],  default-features = false }

Syntax for representing keys as JSON/String

Once keys are generated, the following syntax can be used to generate JSON/String representation.

 serde_json::to_string(&priv_key).unwrap()

Work performed so far

I have updated both recrypt-rs and gridiron so that they both implement serde as an optional feature. Users/calling-code can choose to take advantage of the feature in the event that they want to be able to read and write the PrivateKey and PublicKey fields to disk (or return these values back to the calling code etc.)

I have created a PR which demonstrates this serialization/deserialization. I hope this is helpful to the codebase and users. Here is a working implementation.

main.rs

use recrypt::prelude::*;

fn main() {
    // create a new recrypt
    let mut recrypt = Recrypt::new();

    // generate a plaintext to encrypt
    let pt = recrypt.gen_plaintext();

    // generate a public/private keypair and some signing keys
    let (priv_key, pub_key) = recrypt.generate_key_pair().unwrap();
    println!("Private Key: {:?}", serde_json::to_string(&priv_key).unwrap());
    println!("Public Key: {:?}", serde_json::to_string(&pub_key).unwrap());
}

Cargo.toml

[dependencies]
serde = { version = "^1.0", features = ["derive"] }
serde_json = "^1.0"
recrypt = { git= "https://github.com/tpmccallum/recrypt-rs", branch = "optional_serde_feature", version = "~0.11.0", features = ["wasm", "serde"], default-features = false }

Output

Private Key: "{\"bytes\":[65,87,140,167,200,98,231,79,144,36,254,60,165,139,82,127,77,18,160,138,228,152,244,23,142,178,210,193,53,156,46,212],\"_internal_key\":{\"value\":{\"limbs\":[344237537,189664523,903829374,1976569010,712921401,287292289,1656743474,2113130108,110]}}}"
Public Key: "{\"x\":[28,6,74,23,3,173,239,177,82,1,81,76,208,140,83,102,200,169,71,97,43,161,15,107,145,224,154,54,84,122,83,96],\"y\":[82,96,170,240,15,127,153,54,205,154,91,30,65,67,49,78,192,73,156,207,50,216,33,34,175,107,174,35,108,164,2,185],\"_internal_key\":{\"value\":{\"x\":{\"limbs\":[556943096,1982674010,1216135794,1701197264,1016537482,1179852127,1656387065,390134280,99]},\"y\":{\"limbs\":[341939558,159841115,1987058143,76820373,1677678398,2112994737,1738790866,1872574136,89]},\"z\":{\"limbs\":[1123696276,871041335,1082750262,1179880934,640986614,1564709300,1793041940,1343582089,36]}}}}"

Please note

The reason that I am using my github repo as the recrypt dependency in the above is example is that I also had to update gridiron so that pub struct Monty was serde compatible. There is a second PR for gridiron at https://github.com/IronCoreLabs/gridiron/pull/31 which will require merging so that recrypt and gridiron can interoperate.

Moving forward

If it is Ok with you all I would like to work through all of this code to ensure that it adds features and functionality to your users but poses no risk or issues whatsoever.

My next step is to run the tests (as apposed to just focussing on the PrivateKey PublicKey structs) and add this same serialization/deserialization functionality to other parts of recrypt and IronCoreLabs software. I believe that this will add value in terms of using this software as a service via RPC, JS, JSON etc.

Feedback

Please provide any feedback and advice which will enable me to achieve the above goals. Happy to alter/update code as well as perform any testing required in order to complete this task.

Kind regards Tim

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.

Would need to bump MSRV to 1.48 because of this addition to Rust. We could possibly make do with an implementation available start in 1.43, but it doesn't seem as clean.

Open to opinions on if the bump to 1.48 is acceptable, or if we should make an attempt at the 1.43 version instead.

CI changes:

• More resilient way of installing rustfmt, as it's not always available on nightly.
• Switch to using rust_cache, which we've been moving towards already as we've been adding sccache. This is just an intermediate step towards that with less noise and some bugfixes built in

Updates the requirements on arrayvec to permit the latest version.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

Updates the requirements on proptest to permit the latest version.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

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

see #107

These changes should prevent private keys from getting written to disk by the operating system. I went through and looked for any memory that we were zeroing out and added the protections there. All unit tests continue to work well.

Do we run unit tests in a Windows environment? If so, I'll attempt to add Windows support to this.

One ugly: in memlock.rs I have conditional compilation so this only happens on unix platforms, but there are empty no-op functions on non-unix. But I have to annotate each function with the conditional compilation. I initially used mod memlock { ... } and had two of those blocks each with an annotation. So then the file only had two of those, which was nice. But Clippy whined about inception. The use would be use crate::internal::memlock::memlock which is ugly. I couldn't find a way around this. Any ideas? I went for the thing I think is least ugly there.

One other ugly: there's no way to call out to these functions without unsafe code. I don't believe it's dirty in this case; it just is what it is. We don't mutate the data values.

Updates the requirements on criterion to permit the latest version.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

The need for this feature arose from testing performed in https://github.com/IronCoreLabs/recrypt-rs/issues/112

This will allow 3rd-party applications the flexibility to choose different build combinations (32-bit, 64-bit or wasm)

For example, 3rd-party applications will be able to use the newly proposed optional Serde feature (once implemented) via 32-bit, 64-bit or wasm i.e.

Adding the optional Serde feature - 64-bit + serde

[dependencies]
recrypt = { version = "~0.11.0", features = ["serde"] } 

Adding the optional Serde feature - 32-bit + serde

[dependencies]
recrypt = { version = "~0.11.0", features = ["serde", "u32"], default-features = false } 

Adding the optional Serde feature - wasm +serde

[dependencies]
recrypt = { version = "~0.11.0", features = ["serde", "wasm"], default-features = false } 

One of the main drivers for this additional explicit 32-bit mode is that 3rd-party Rust applications (which use recrypt) are not able to perform the following long-hand dependency declaration in their Cargo.toml

recrypt = { version = "~0.11.0", features = ["ed25519-dalek/u32_backend"] } 

The above causes the following error

error: feature names may not contain slashes: `ed25519-dalek/u32_backend`

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"

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();

Hi!

I think I understand how to use the transform encryption feature of this lib, thanks to the documentation example. But I do not understand why we need a signing key pair when encrypting or generating a transform key. According to my tests, encryption/transformation/decryption seems to work even if I generate a new signing key pair every time one is needed.

So I wonder:

• Is it OK to do that? (Generate new key pairs and not keeping them)
• Could you explain/document what is the point of these keys and how to use them?

Have a nice day!

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().

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.

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.

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.