orip
u/orip
Feed options
Hot
New
Top
View
Card
Compact
"Blood Relation"
It's a poetry collection by Zvia Ben-Yosef Ginor (there are several alternate English spellings of her name online).
This is its entry in the National Library of Israel:
https://www.nli.org.il/en/books/NNL_ALEPH990010422060205171/NLI
Also the photo is upside down.
It seems to me that your design achieves your stated goals.
Some suggestions:
-
Calculate the 2 MACs with different derived keys, as you yourself suggested. Using different keys for different purposes makes it obvious that there are no unwanted interactions.
-
Although I think the way you encrypt each paragraph achieves your goal for deterministic encryption - consider using constructs that match this better. For example, Google's Tink library recommends using AES-SIV in "deterministic encryption" mode - you can achieve the same by using noble's AES-SIV with an all-zero nonce. Internally AES-SIV already generates an efficient data-dependent encryption and MAC. Maybe AES-GCM-SIV will have the same properties. This also has the effect of reducing the ciphertext size.
-
Don't be agile with the scrypt parameters. If you want future-proofing consider whitelisting the only scrypt parameters you support in encryption and decryption and refusing to encrypt or decrypt if the scrypt parameters don't match.
Seems to be a defunct bjj brand based on old lists like this one: https://maxbjj.blogspot.com/2015/06/le-marche-dei-gi-del-brazilian-jiu.html?m=1
This could be the designer - has the text and figure on the page https://jimheathdesign.com/cartoon-land
That depends on the chance you want to maintain to prevent leakage. NIST recommends 2^-32, which means that more than 2^32 encryptions with random 96-bit nonces are an issue. Good info in the introduction to https://eprint.iacr.org/2017/702.pdf
You're correct that random nonces would have a high probability of collision. Even if you could ensure no collisions you would still have a problem with the birthday bound and AES-256's 128-bit blocks, given billions of encryptions.
Deriving a new key per row based on a "master key" is a good way to overcome these limitations. UUIDv4 only has 122 random bits so you can still have collisions, but if you add another 96 bits of random nonce per row you're working with 218 random bits which shouldn't collide even with many billions of encryptions.
S. Gueron and Y. Lindell wrote a paper describing the issue and this solution called "Bett er Bounds for Block Cipher Modes of Operation via Nonce-Based Key Derivation".
Gueron has described a similar scheme with 192 bits where he uses a 256 bit master key and 120 random nonce bits to derive an effective key, and encrypt with AES-GCM using another 72 bits.
He calls it "Double Nonce Derive Key AES-GCM (DNDK-GCM) ", https://datatracker.ietf.org/doc/draft-gueron-cfrg-dndkgcm/
If your UUIDs are generated with a good random then you should be ok.
If you're not sure of they're generated well (I have definitely encountered UUIDs generated with bad random and many collisions in the wild) consider adding your own generated bits to derive with instead of relying on the UUID, if you have the space.
But if you're free to choose your encryption algorithms and don't have to only use NIST-approved algorithms, consider using an algorithm without these limitations such as AEGIS-256. You can just use a 192-bit (or larger) random nonce with it and be fine, and the performance would be significantly better than HKDF + AES-GCM.
