4 ms·

> 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 understan

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

throwaway81523 2y ago
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.
- CiPHPerCoder 2y ago
  > 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!
llarsson 2y ago
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.
talkingtab 2y ago
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.
- CiPHPerCoder 2y ago
  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.

throwaway81523 2y ago

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.

CiPHPerCoder 2y ago
> 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!

llarsson 2y ago

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.

talkingtab 2y ago

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.

CiPHPerCoder 2y ago
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.