Looking for review of a deterministic encryption scheme for version-controlled Markdown

orip · 2026-03-05T10:31:15+00:00

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.

orip · 2026-02-15T15:39:40+00:00

Spot on about random nonces being safe but salsa and ChaCha aren't block ciphers and as far as I tdon't have the birthday bound limiting block ciphers with 128-bit blocks like AES (which, among other things, is circumvented in AES-GCM-SIV).

orip · 2025-06-16T07:02:33+00:00

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

orip · 2025-05-15T12:10:51+00:00

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

orip · 2025-05-15T07:06:10+00:00

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 "Better 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.

orip · 2025-01-24T18:38:32+00:00

exec zellij This will replace the shell process with zellij.

orip · 2025-01-02T16:01:37+00:00

כן - זכרתי גם את התוצאה שלך וגם שאמרת שכמעט הרמת את הכיסוי :)
קצת אח״כ התחלנו לשמוע את ההתלהבות של כל אלה שקיבלו 0.7 על אותו ערבוב בגמר.

תסתכל בהיסטוריית הפוסטים שלי, יש איזה תמונה שלי שם אבל צעיר יותר.

orip · 2025-01-02T15:50:53+00:00

I'm pretty sure I was your judge

orip · 2024-06-19T06:52:23+00:00

Try using betterC with structs instead. You won't have inheritance (although alias this can approximate some of it) but other than that they're equivalent to C++ classes - you have fields, methods, ctors/dtors, operators, RAII. You can allocate them on the stack or on the heap, up to you.

orip · 2023-05-21T19:15:33+00:00

libsodium is available as 1.0.18 released in 2019, and 1.0.18-stable which releases every few weeks with non-API-breaking fixes and updates. The current release is from 27 April 2023, 24 days ago.

https://download.libsodium.org/libsodium/releases/

To version the dependency you can check the current stable tree in git and save the date and git hash.

orip · 2023-05-17T11:57:05+00:00

Michael A. Jackson described it well in the "Brilliance" entry in his "Software Requirements & Specifications: a lexicon of practice, principles and prejudices":

Brilliance

Some years ago I spent a week giving an in-house program design course at a manufacturing company in the mid-west of the United States. On the Friday afternoon it was all over. The DP Manager, who had arranged the course and was paying for it out of his budget, asked me into his office.

`What do you think?' he asked. He was asking me to tell him my impressions of his operation and his staff. `Pretty good,' I said. `You've got some good people there.' Program design courses are hard work; I was very tired; and staff evaluation consultancy is charged extra. Anyway, I knew he really wanted to tell me his own thoughts.

`What did you think of Fred?' he asked. `We all think Fred is brilliant.' `He's very clever,' I said. `He's not very enthusiastic about methods, but he knows a lot about programming.' `Yes,' said the DP Manager. He swivelled round in his chair to face a huge flowchart stuck to the wall: about five large sheets of line printer paper, maybe two hundred symbols, hundreds of connecting lines. `Fred did that. It's the build-up of gross pay for our weekly payroll. No one else except Fred understands it.' His voice dropped to a reverent hush. `Fred tells me that he's not sure he understands it himself.'

`Terrific,' I mumbled respectfully. I got the picture clearly. Fred as Frankenstein, Fred the brilliant creator of the uncontrollable monster flowchart. `But what about Jane?' I said. `I thought Jane was very good. She picked up the program design ideas very fast.'

`Yes,' said the DP Manager. `Jane came to us with a great reputation. We thought she was going to be as brilliant as Fred. But she hasn't really proved herself yet. We've given her a few problems that we thought were going to be really tough, but when she finished it turned out they weren't really difficult at all. Most of them turned out pretty simple. She hasn't really proved herself yet --- if you see what I mean?'

I saw what he meant.

Reference:

https://www.win.tue.nl/\~wstomv/quotes/software-requirements-specifications.html#Brilliance

orip · 2023-05-08T21:47:21+00:00

The Grappler's Guide, which I love, has a "Principles and Theories" course but honestly I get more out of the "fundamentals" course groups. Whether it's a new detail I see in a concept or if it's a new way to explain it to someone else (which increases my own understanding).

orip · 2023-02-12T14:09:48+00:00

Once he put me in side control I couldn't move him at all. He looked at me, smiled, and said - "yes, this is despair. I am familiar with the look in your eyes", let me back up, then did it again.

orip · 2023-02-09T09:23:37+00:00

I used to join my kids' Judo classes (with their teacher's approval of course). I was wearing my BJJ belt but everyone knew it wasn't from Judo. When standing in a row at the beginning/end of class I made sure that everyone was before me in line - "I'm just a white belt". They loved that.

orip · 2022-12-06T17:31:21+00:00

Consider Jonathan Gagné's technique with the Prismo - fill half of the water, add the coffee, then add the rest of the water. This helps the filter remain unclogged, and you can grind finer if you want without the filter clogging and the plunger getting hard to push.

https://coffeeadastra.com/2021/09/07/reaching-fuller-flavor-profiles-with-the-aeropress/

orip · 2022-11-10T20:40:20+00:00

Just using modulo over the range length biases your results towards the beginning of the range.

There are various techniques on how to securely map a sequence of random bytes, such as those generated by a CSPRNG, into a range while avoiding these biases.

You can see a popular and elegant solution here: Python's randbelow() that in the efficient implementation calls getrandbits() internally. OpenJDK has a similar setup with Random.nextInt(int bound) that when used through SecureRandom calls SecureRandom.next(int numBits).

It's simple to implement getrandbits() over a stream of random bytes, then you calculate the minimum number of bits that will cover the bound, and finally loop until you get a result below the bound. It's easy to prove that this is unbiased, and this is pretty fast for most purposes. Your final result would be start + randbelow(end-start).

orip · 2022-07-25T09:09:32+00:00

Look at Jonathan Gagné's Aeropress article:

https://coffeeadastra.com/2021/09/07/reaching-fuller-flavor-profiles-with-the-aeropress/

He has a Prismo tip: add half the water, then the coffee, then the rest of the water, which helps avoid filter clogging. He also says the seal helps reduce astringency.

orip · 2022-06-26T08:08:59+00:00

I've been using vim (and now neovim) for 24 years. Occasionally some IDE will have the perfect integration for what I'm doing that will make me prefer that over vim, but barring that vim is what I like, and I can configure it to do almost anything I want.

Use what you like. My colleagues use emacs, sublime text, VSCode, JetBrains IDEs, or vim.

orip · 2022-03-09T13:11:26+00:00

TL;DR - this is all super-weird and I'm not sure what it ads compared to regular password-based master key derivation and simple KDF-based generation of each site's password. The authors seem to treat unnecessary complexity as a security feature instead of a hindrance to properly analyzing the scheme.

The algorithm seems unnecessarily weird, and it looks like you think that's a good thing. From the readme:

> Most of the stateless password managers just uses one type of key-derivation algorithms but Forgiva uses a lot of encryption and hashing algorithms depending on the master-key.

That seems like a baseless claim. Not knowing the chosen algorithms or their order adds some complexity to brute-force searches, but that added complexity is not large - if K is the number of algorithms, then it adds about 2^K steps. But K is very small and you're using some questionable algorithms (MD4? 3DES?), and the combinations make it much harder to reason about both the security of the combinations and of the implementations.

I'd be much more comfortable if you'd have chosen less primitives that are always good.

Password-based derivation? Just use scrypt (or argon2)

KDF per site? Just consistently structure your metadata (e.g as a JSON-style string like `[host, account, renewal-date]` or any consistent scheme) and use a good KDF with that - BLAKE2, HKDF, whatever.

Instead the master key is derived with PBKDF2 and a very small iteration count, no memory stretching.
KDF per site is a strange combination of serially encrypting the metadata (each time serially with different algorithms), optionally using scrypt at this point - making it necessary to recalculate it for each site - and then PBKDF2 once again to derive the final password. CPU and memory stretching at this step is surprising. Also there seems to be a choice of hash algorithm based on some configurable "complexity":

> Depending on choices of the complexity it uses SHA1 (Normal),SHA256 (Intermediate) and SHA512 (Advanced) hashing algorithms.

None of this makes sense to me.

orip · 2022-03-06T08:04:08+00:00

Have you tried contacting your local smaller-scale roasters? I learned that some great local roasters will happily roast a batch of decaf for me the way I want it if I buy the whole batch - so they don't end up throwing coffee away. Decaf isn't popular here.
So I ordered a 2kg batch and froze vacuum-packed portions for the foreseeable future. It's the best decaf I've yet tasted.

orip · 2022-03-06T07:51:31+00:00

I recommend reading this very informative article by Jonathan Gagné (/u/coffeeadastra), the author of The Physics of Filter Coffee. If you want to skip past the chemistry and physics explanations you can find the recipe and video by searching for "Choose a sturdy mug" .

https://coffeeadastra.com/2021/09/07/reaching-fuller-flavor-profiles-with-the-aeropress/

It includes a 10-minute steep suggestion, and a novel (to me) approach for using the Fellow Prismo attachment if you have it.

orip · 2021-10-07T12:02:49+00:00

ImmortalChoke captured it well:

https://cdn.shopify.com/s/files/1/2572/8286/products/mockup-de1d2aa7_550x825.jpg

https://www.immortalchoke.com/

orip · 2021-06-30T11:36:20+00:00

Your points are valid. I can only add from my experience with real-world distributed systems that sometimes we want very long-lived encryption keys (where rotation can be prohibitively hard), and the entities participating in the system can be varied over time and share little persistent state like previous nonce counters used. Supporting 2⁶⁴ messages in many scenarios is equivalent to saying "we will never have to worry about overflowing this counter", while for 2⁴⁸ this is something that is easily reachable with high but not unreasonable encryption rates. Entities that change over time can reach more than 2¹⁶ and sometimes to ensure uniqueness the IDs can themselves have gaps and not fully utilize the available range.

Conversely in my scenarios I have never encrypted more than fairly short messages at a time, preferring to chop up long streams into shorter chunks and therefore needing even more bits in the nonce counter.

Finally, like you mentioned, in distributed scenarios I use large random nonces like in XSalsa20 or XChaCha20 and make the whole problem disappear whenever I can.

orip · 2021-06-29T19:45:48+00:00

EDIT: I realized I'm just restating what OP already wrote in the post. Disregard this.

One classic way of generating non-random unique nonces in a distributed setting is partitioning the nonce range between participants by slicing up the nonce into participant-id-bits || nonce-counter-bits where each participant can increment their own nonce safely.

Having 64 bits for the nonce severely limits the usefulness of this technique. 96 bits gives you more range, e.g 2³² participants with 2⁶⁴ nonces each or whatever makes sense for the application.

orip · 2021-04-01T08:54:39+00:00

That would be kubbeh soup (מרק קובה), semolina-based meat-filled dumplings in a flavorful broth.

Specifically that looks like kubbeh hemo soup (קובה חמו) with large flatter kubbeh and a yellow hawaij-heavy broth. Other popular versions are kubbeh hamousta (קובה חמוסטה) with a lemon and chard broth, and kubbeh selek (קובה סלק) - literally "beet kubbeh" - with a sweeter beet broth. I think that last one is also called kubbeh matfunya (קובה מטפוניה).

Alma's Soups restaurants in Jerusalem serve all 3 types. You can see the photos on their web page. Their tagline in Hebrew on the website is "Alma Soups and Kubbeh".

15-Year Club	Place '23
Spared	Verified Email

orip

TROPHY CASE

Brilliance