Hacker News Comments on
Cryptography Engineering: Design Principles and Practical Applications
·
7
HN comments
- This course is unranked · view top recommended courses
Hacker News Stories and Comments
All the comments and stories posted to Hacker News that reference this book.David Wong's _Real World Cryptography_: https://www.manning.com/books/real-world-cryptographyJean-Philippe Aumasson's _Serious Cryptography_: https://nostarch.com/seriouscrypto
Ferguson and Schneier's _Cryptography Engineering_: https://www.amazon.com/Cryptography-Engineering-Principles-P... --- dated, a little wrong about some things, but not insane (like _Applied Cryptography_ is).
Hoffman, Pipher, and Silverman's _Introduction to Mathematical Cryptography_: https://www.amazon.com/Introduction-Mathematical-Cryptograph... --- a good first step into theoretical cryptography.
⬐ muggermuch>> dated, a little wrong about some things, but not insane (like _Applied Cryptography_ is).Why is "Applied Cryptography" insane? As an interested bystander, I'm curious to know more.
⬐ tptacek⬐ mintyDijonYoink! https://sockpuppet.org/blog/2013/07/22/applied-practical-cry...⬐ rstuart4133⬐ pvgYou have to actually read all of _Applied Cryptography_ before it becomes obvious what the central theme is. Its a big book, but unlike other may big computer books over the years it isn't padded. It's literally a compendium of crypto.Including all the failed crypto. By the end of it, you've got used to reading the (usually very impressive) credentials of the researchers, and through explanation of what they did, and then how it all fell apart after a few years of attacks. If read about how people far clever than you got it wrong over and over again, it is near impossible to come away without the impression "here be dragons - really big and mean ones", and the corollary "don't even think of trying to do this stuff yourself - just stuff on the shelf that has been proven over time".
⬐ tptacekIt depends on whether descriptions of things you should never, ever do, without any explanation of whether or not you should do them, count for you as "padding".You can get multiple seasons of this clip show by putting 'author:tptacek applied cryptography' in the search box. A recent episode:I just finished serious cryptography, and I'm looking for the next step forward. I have little to know real programming experience, and my math skills aren't the greatest, (only high school with basic understanding beyond that, I think I understand the math behind RSA, but not the implementation so much)Would cryptography engineering be too advanced for me? I plan on developing my programming skills after I get a computer, but until then want to continue learning.
⬐ tptacekCryptography Engineering is less advanced than Serious Cryptography (but it's "take-y-er"; there's a lot of opinion / best practices stuff in it, and a lot of that is good).I'd say that if you've read and grokked Serious Cryptography, and you don't want to write code, something like _IMC_ (Silverman, above) is an interesting next step, in that you'll mostly be reasoning about math, and you'll be working at a much lower level than the basic RSA formulae.
It also depends on what aspects of cryptography are interesting to you. If you want, for instance, to get a much better grip on how bulk cryptography works, as opposed to signatures and key exchanges, your best next step might be papers. For instance, a good next step on block cipher cryptography would be the Heys tutorial: https://ioactive.com/wp-content/uploads/2015/07/ldc_tutorial...
⬐ mintyDijonThank you for your reply and guidance.Looks like I can't pick up IMC at my local library, so I'll have to wait a tad on that one, but I can start with papers right away. I can't quite say what my particular interests in cryptography are, but (I guess not too surprisingly) I have a desire to know more about Hash functions. Now I'm going to try to hunt down the papers for Skein. Thanks again!
A quick look at the source code shows the generate_key() function [0] to be insecure. It generates 32 random bytes (good, that's what you need for an AES-256 key), but then it uses those random bytes to sample from a distribution which only has 62 characters. This significantly reduces the security of the key, from 256 bits of entropy to ~190 bits (log2(62^32)). And that would be in the best case, if it were sampling uniformly from the distribution - it is not.I recommend reading Section 9.7 of Cryptography Engineering [1] to understand why choosing random elements from a set is harder than it seems. A good example of a similar bug is the nasty bug in Cryptocat's PRNG from 2013 [2].
I assume this step was done so the AES key could be included in the URL fragment, since a set of random bytes may not be url safe. I recommend feeding the random bytes of the key directly into the underlying cryptographic functions, and using a urlsafe encoding at a higher level when necessary.
Also, it appears you are using AES [3], a block cipher, but I cannot figure out what block cipher mode you are using. I'll have to dig into the CryptoJS code a little more to see what it defaults to, but I have a sinking feeling that it's ECB, which is completely insecure. Dan Boneh's Crypto I course on Coursera is a good way to learn the basics of block cipher modes.
[0]: https://github.com/jes/hardbin/blob/c77c2d7eb93586e0e009ea4b... [1]: https://www.amazon.com/Cryptography-Engineering-Principles-P... [2]: https://nakedsecurity.sophos.com/2013/07/09/anatomy-of-a-pse... [3]: https://github.com/jes/hardbin/blob/c77c2d7eb93586e0e009ea4b...
⬐ forgotpwtomain> to understand why choosing random elements from a set is harder than it seemsThere is no sample from a set problem involved, just convert b256 -> b62, there is a correct way to do this.
⬐ jstanleyI'm aware it's only 190 bits of keyspace. I mentioned this in my blog post[0], and would in fact be more likely to decrease it than increase it, in order to make the URLs shorter. I don't think it's a problem, but am interested in being proven wrong.It's using CBC mode.
[0] http://incoherency.co.uk/blog/stories/hardbin.html
EDIT:
> And that would be in the best case, if it were sampling uniformly from the distribution - it is not.
Can you please point out how it's not? It's intended to sample uniformly. It would be non-uniform if it were "randombytes[i] % alphabet.length".
EDIT2:
I see now how it's non-uniform. 256 values in randombytes doesn't map 1:1 onto 62 values in alphabet. I will fix this tonight, thanks for pointing it out.
⬐ garrettr_> I'm aware it's only 190 bits of keyspace. I mentioned this in my blog post[0], and would in fact be more likely to decrease it than increase it, in order to make the URLs shorter. I don't think it's a problem, but am interested in being proven wrong.I understand that you're trying to balance the tradeoff between security and usability here, which is tricky. If quantum computers are part of your threat model, remember that Grover's algorithm provides a quadratic speedup for brute-forcing a symmetric key, so 2^190 would become 2^95 against a quantum adversary. Personally I prefer the margin of safety provided by using a full-strength 256-bit key :)
> It's using CBC mode.
Phew! That would've been truly catastrophic.
⬐ erikbyeYou mean truly catastrophic if it was codebook?⬐ CiPHPerCoderCBC mode isn't exactly a saving grace here, since it's unauthenticated.⬐ jstanleyThe code and data are shipped together out of IPFS. If you don't trust the data, you don't trust the code anyway, so it makes no difference whether the data is authenticated.⬐ CiPHPerCoderFirst, read this: https://tonyarcieri.com/all-the-crypto-code-youve-ever-writt...Second, what is the threat model where you trust IPFS but still need to encrypt client-side? Unauthenticated CBC mode totally defeats the point of encryption, but encryption totally defeats the point of trusting IPFS.
Why not just-- crazy idea!-- use authenticated encryption even if you trust IPFS?
⬐ jstanleyI don't think you understand IPFS.If you trust your IPFS node, you know that you're retrieving the correct content. You still don't want others to be able to read it.
EDIT: (Since HN won't let me reply to you): There is no mode of operation in which it's safe to use Hardbin without trusting the messages you're receiving, authenticated encryption or not.
Since the code and the data are both served out of IPFS at the same time, checking the message integrity is pointless. If somebody controlled the IPFS node you're using and wanted to do something malicious, they could more easily just add some code to ship the decryption key off to a remote server than perform an attack on the unauthenticated encryption.
⬐ CiPHPerCoderA lot of crypto engineering problems go out the window if you just trust the messages you're receiving. That doesn't mean it's okay to use unauthenticated encryption in 2017.> EDIT: (Since HN won't let me reply to you): There is no mode of operation in which it's safe to use Hardbin without trusting the messages you're receiving, authenticated encryption or not.
> Since the code and the data are both served out of IPFS at the same time, checking the message integrity is pointless. If somebody controlled the IPFS node you're using and wanted to do something malicious, they could more easily just add some code to ship the decryption key off to a remote server than perform an attack on the unauthenticated encryption.
http://www.cryptofails.com/post/121201011592/reasoning-by-le...
⬐ jstanleyYour HN profile describes you as a Cryptography Engineer, and I'm sure that's true.You're just not presenting a convincing argument for why it's OK to trust the code but not the data when they're both served out of the same place. Do you understand that they're both served from the same place? If somebody can modify the data, they can just as easily modify the code and make it do whatever they want. Do you understand that?
You're just linking me to things other people have written instead of presenting a persuasive argument. So I'm not going to bother doing what you say. Sorry.
⬐ CiPHPerCoderIf you call your project "the most secure X" and you're doing something related to X in a very sub-optimal way (i.e. not using AEAD modes), what happens if someone uses your code as a reference point for writing their own crypto for a protocol that doesn't use IPFS? What if, instead of a specific instance of copying code out of context, people learn bad habits from your code and then defend their choices until they're blue in the face because they copied it off of "the most secure" reference implementation?A lot of problems, many unforeseeable, are easily prevented by using authenticated encryption.
> You're just not presenting a convincing argument for why it's OK to trust the code but not the data when they're both served out of the same place. Do you understand that they're both served from the same place? If somebody can modify the data, they can just as easily modify the code and make it do whatever they want. Do you understand that?
Yes, and this has been covered to death to the point that I'm sick of hearing it: https://www.nccgroup.trust/us/about-us/newsroom-and-events/b...
One could easily build a Chrome extension that still uses your IPFS gateway for shipping ciphertext. Now you've got the code at rest (so transport-layer integrity doesn't undermine the code being executed), but the data is still reliant on IPFS.
Let's do a thought experiment.
First, move your code to a Chrome extension (which makes the code immutable), then give the attacker an enormous amount of power. For a moment, assume that an attacker can totally defeat IPFS. It doesn't matter how they do it. Is your application-layer cryptography protocol still secure?
⬐ jstanley> First, [completely change your application and its core security assumptions]. Is your application-layer cryptography protocol still secure?No.
⬐ CiPHPerCoderIf your application-layer cryptography protocol is not secure in isolation, what argument do you have against making it secure in isolation?⬐ jstanleyI have none. I'd merge a sensible pull request.But characterising it as a huge security flaw is disingenuous. It's neither here nor there.
⬐ CiPHPerCoderI'm characterizing it as a protocol/design flaw in something that bills itself as the most secure X, sure, but I haven't done anything to describe it as "huge".Are you being needlessly defensive?
Cryptography Engineering [0] is a great book that covers key topics in cryptography with a focus on best practices for implementors and system/protocol designers.Matthew Green's blog, A Few Thoughts on Cryptographic Engineering [1], has a wealth of interesting posts that are often aimed at explaining cryptography to a "technical but non-cryptographer" audience, and tend to be motivated by recent events in security/cryptography news.
[0]: https://www.amazon.com/Cryptography-Engineering-Principles-P... [1]: https://blog.cryptographyengineering.com/
Crypto is not about breaking in, but breaking codes. It is mostly a bunch of maths.http://www.amazon.com/Cryptography-Engineering-Principles-Pr...
Tptacek said it's a bad idea to read Applied Cryptography. "Take that book Applied Cryptography that's on your bookshelf and burn it. Do that as a commitment to really learning crypto. But absolutely don't read it. If you don't read it, you have nothing to unlearn, so you're much better off." Source: http://wiki.securityweekly.com/wiki/index.php/Episode292 time index 22:10, but the whole podcast is good.Instead, he recommends Cryptography Engineering: http://www.amazon.com/Cryptography-Engineering-Principles-Pr...
Another way to get a primer on crypto is to do the Matasano crypto challenges: http://cryptopals.com/
The solutions aren't (yet?) published, but don't let that stop you. It will be fairly obvious when you've come up with a solution that solves the challenge. It's also an excellent way to get you really thinking about all of the problems with crypto. And it will hopefully scare you from ever implementing your own crypto scheme, which is always a good thing.
Make sure to do all the challenges though. They get exponentially more difficult, but the best ones are near the end.
⬐ bostik> Instead, [tptacek] recommends Cryptography Engineering*So do I, by the way - CE is a modern book and it shows just how hard it really is to build a secure protocol. But it assumes a certain baseline background.
AC is old. I do not dispute that. But as to why certain types of constructs are used, it's still a properly readable book.
And quite true, the threat models in AC do not account for active attackers who are flipping bits to do real-time differential cryptanalysis. When the book was written, "data at rest" was the most common problem.
If there is an equally readable, modern book which explains the whys of the constructs, I'd love to know. CE is a great book once you understand the basics - but IMO it's not really fit for a first pass.
⬐ tptacekThis came up often enough that I wrote a blog post about it:http://sockpuppet.org/blog/2013/07/22/applied-practical-cryp...
I would highly recommend reading Cryptography Engineering [0] cover to cover. It's amazingly readable, covers the basics, the theory necessary to understand how things works and includes ample practical advice and observations on the industry.The first thing I did after the Snowden leaks was read through the entire thing and after doing so I really wished I had done this years earlier. There's very few books that I think should be required reading across the board for software engineers, but this is one that I do think everyone writing code should read every page of.
[0] http://www.amazon.com/Cryptography-Engineering-Principles-Pr...
⬐ mehrdadaI don't. This book recommends, say, MAC-then-Encrypt and tries to justify it in 2010 by perpetuating FUD about provable crypto (proofs are only valid if your primitives are ideal, therefore you should worry about--one set of--risks that you can't measure, so trust us instead of proofs). There's no excuse for doing that.In general, the authors seem to subscribe to "crypto is black magic" school of thought, which doesn't make for good pedagogy.
TLDR; Get "Cryptography Engineering"[0] instead.0: http://www.amazon.com/Cryptography-Engineering-Principles-Pr...