Found in 6 comments on Hacker News
garrettr_ · 2017-05-23 · Original thread
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]: [1]: [2]: [3]:

garrettr_ · 2017-04-05 · Original thread
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]: [1]:

un1xl0ser · 2015-02-12 · Original thread
Crypto is not about breaking in, but breaking codes. It is mostly a bunch of maths.

sillysaurus3 · 2014-12-21 · Original thread
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: time index 22:10, but the whole podcast is good.

Instead, he recommends Cryptography Engineering:

Another way to get a primer on crypto is to do the Matasano crypto challenges:

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.

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.


sanderjd · 2013-08-15 · Original thread
TLDR; Get "Cryptography Engineering"[0] instead.


Fresh book recommendations delivered straight to your inbox every Thursday.