> That said, it would be helpful for us i² [i squared] folks to have some of the more basic terms explained. Although "encryption at rest" is somewhat understandable, it would be pleasant to have it explained.

That's helpful feedback, actually. What terms seemed opaque or misleading to you as you read it? I'm always happy to fix mistakes in blog posts to improve clarity.

> For example what are the other kinds?

I contrast "encryption at rest" with "encryption in transit" (i.e., TLS) and "end-to-end encryption" (E2EE for short; i.e., what Signal gives you).

As writing advice, it went from very understandable and approachable to stuff like:

"You can get this property by stapling HKDF onto your protocol (once for key derivation, again for commitment). See also: PASETO v3 and v4, or Version 2 of the AWS Encryption SDK.

It may be tempting to build a committing AEAD scheme out of, e.g., AES-CTR and HMAC, but take care that you don’t introduce canonicalization risks in your MAC."

I would almost suggest breaking stuff like this into two articles, one which is very technical and correct, and one that conveys the high-level message. The high-level one can link to the technically correct one whenever the urge would come to explain something more fully.

Thanks for the reply. It is an interesting question, because the truth is that I don't know. At one point, very long ago, (VLG) I knew nothing about computers at all but would by "Byte" magazine (I told you VLG) and read it. It was complete gibberish. Then after some time (six months?) I could suddenly understand.

I actually did learn quite a bit from your article. The use of tech terms like HDKF & AEAD was helpful rather than a hindrance. For example the phrase "stapling HKDF onto your protocol" is surprisingly helpful. I looked up HKDF, and the use of "stapling" gives me a concept of how it is used. So good.

Going back over it, I believe the real problem is that your previous post, "Lucid Multi-Key Deputies Require Commitment" is required to reading (or knowledge) for this post. Once I read that much of this was easier. You hid that reference is in the "why should you believe me" and yet to my reading the this article builds on that one. You define the terms and provide a context that is missing.

So concrete suggestions (easy to come up with after the fact!):

- ask yourself if this is a continuation of a thought, topic, etc and give refs if so. - in addition to "why you should believe" maybe add a section "for i²" readers :-)

Cool things are ones where you never see the world the same. Just to reiterate, I don't see the world of cryptography the same after reading your article, despite the quibbles, so thanks.

Thanks for the feedback. I'll add a note after that section to make sure it's referenced appropriately.

And especially thanks for taking the time to share your experiences and observations with me. That's how I improve as a writer.

You're the author? Cool, I liked the article a lot. You do use a lot of terms that won't make sense to non-crypto nerds, like OAED, IND-CCA secure, etc. A lot of posters here are fixating too much on the "stolen hard disk" picture which I think the article addressed by declaring it out of scope. So the real points aren't getting through.

> A lot of posters here are fixating too much on the "stolen hard disk" picture which I think the article addressed by declaring it out of scope. So the real points aren't getting through.

This is a crypto nerd blog post though. The whole point is to talk about cryptographic library design!

As you identify in the second paragraph, it is not true to say that “you don’t know what you don’t know.” There are indeed things that you do know that you don’t know. I know I don’t know how to fly a plane.

Basically I am complaining that you choose to rephrase a perfectly good description of a problem (with a lot of history) into an incorrect statement.

So it would be more accurate to say that “there are some things that I don’t know that I don’t know.” However, “unknown unknowns” and “known unknowns” are more succinct. And, thanks to that idiot Rumsfeld, more commonly understood.

I get what you are saying that it is more succinct. However the next statement "it is not true to say ..." confuses me. In fact there are many cases where I did not know that I did not know something important.

I was cross country skiing across a frozen lake. The ice was 24 inches thick. I knew it was that thick. I did not know that where a lake narrows there can be current that prevents ice from forming. Moreover, I was unaware that there were major issues about frozen lakes that I was unaware of. I was not aware there was any risk and therefore came much to close to falling through the ice. Those little "crack crack crack" sounds stick with me. There have been other examples when I was unaware that I was ignorant of life threatening issues.

My use of that phrase is perhaps particular to the fact that most of my realization of "unknown unknowns" has been when they are life threatening.