seanwatters

v0.7.0 to be released later in the week.

public verifying key: [86,10,27,184,67,57,76,92,187,198,164,56,154,224,189,35,72,85,79,149,217,241,238,155,33,64,193,202,178,136,183,50]

public exchange key: [222,204,53,153,33,212,247,174,180,162,45,216,108,13,79,187,183,21,57,109,201,247,102,189,30,155,165,169,213,33,100,78]

not sure why all the existing crates have gone so far out of date. i feel like generating bindings isn't that hard if you've done it before but can be a blocker for people who haven't so maybe this will help.

some of the existing crates had the -sys suffix but it didn't seem like they were actually checking for it on the system (i'm not sure that LMDB is installed by default on most systems anyway?) so opted to not use it.

chose to keep the version in step with LMDB (current looks like 0.9.70 in the lmdb.h).

will regenerate anytime i become aware of a version bump for LMDB.

currently playing around with X25519/chacha20 (and its AEAD counterpart chacha20poly1305) to do some PGP-esque encryption stuffs.

based on my understanding of stream ciphers, "nonce reuse" refers more specifically to "nonce reuse with a given key, for different plaintexts."

basically the thing that i'm trying to evaluate is whether there is any risk to "reusing" a single nonce with a bunch of keys that are guaranteed to be random.

the process for encryption is as follows:

1. Generate one-time and ephemeral components

    - nonce

    - one-time content key

    - ephemeral private key

    - one-time public key

2. Sign plaintext to generate content signature

3. Encrypt plaintext and content signature with one-time content key

4. Encrypt one-time content key for all recipients

    - Generate shared secret with recipient public key and ephemeral private key
    
    - Encrypt one-time content key with shared secret

in the current setup the "content key" (think PGP session key) is always randomly generated, and the Diffie-Hellman shared secrets—used to encrypt the "content key" for each recipient—are created with an ephemeral/throw-away private key that's also randomly generated (and if you have a duplicated public key in your recipient set, it's still same-key-for-same-nonce-for-same-plaintext so no violation).

additionally, if there was somehow an overlap on a recipient's DH shared secret and the content key (statistically very low likelihood) i'm not sure that there is any additional vulnerability, or way to analyze without having already either gotten the content key or the shared secret, and in either of those cases you're already in.

NOTE: this whole thing is mostly just about saving storage space; ideally just wouldn't have to store an additional 24 bytes per recipient. with benchmarking, the time overhead of generating a nonce for each recipient is negligible.

but like... in a semi-neutral, slightly-positive kinda way?

Bicycle is a framework for defining database schemas whose access patterns are generated as code and compiled into each server binary.

We're striving to reduce dynamic query parsing at run time.