Joe Armstrong: Crypto Tutorial [pdf]

> as an example, imho, the _idea_ conveyed by "salting" is correct

I agree, the idea is correct, but it is actually dangerous and incomplete. I know because admittedly, I had personally fucked up IVs and stuff a long time ago and even then I knew more than this guide. False sense of crypto wizardry is really bad.

P.S. I also think using the precise, standard, terminology is of utmost importance in introductory texts (enables you to continue learning) and especially in crypto.

It's hard to say. I did not read the whole thing, but red flags were glaring. I don't have anything against the author. In fact, I, myself, have implemented poor crypto based on (various levels at various times of) understanding it and later realized I didn't know nearly enough about it. For that reason, honestly, my suggestion is stop looking for a fix to this guide and study up basic crypto concepts from scratch from a proper source (like the one I mentioned) and then try to find a good library that does it in your favorite language. Understand what the library does first and let it do it on your behalf.

I don't think this guide is written by a fundamentally cryptographically well-informed person (edit: despite being by a great PL theory expert). At the cosmetic level, it calls AES the "Advance Encryption standard" and says RSA was invented by "Don Rivest".

OK, maybe these are typos in an early draft. But then it tells you that "the problem" with a LCG stream cipher with a 32-bit internal state "is that if we encrypt the same text many times with the same password the encrypted text is always the same" and that appending a random string to the password will "remedy this" (implying that this fix has made the stream cipher secure!). No, "the problem" with this LCG is that its effective key space is 32 bits and you can brute force it with 2³² trial decryption operations without even doing any algebra.

The text supplies an AES implementation that uses MD5 as a KDF, it supplies sample stream cipher code that uses RC4, it also goes on to recommend SHA-1 and says that "In practice I usually encrypt something like an SHA1 checksum (160 bits) with a 800 bit [RSA] key. 800 bits is fast enough for me and sufficiently difficult to crack that for most purposes can be considered secure."

(Hint: expert advice urged phasing out keys of that length by around the year 2000, and an academic group publicly announced breaking a 768-bit key back in 2009. https://en.wikipedia.org/wiki/RSA_numbers#RSA-768 ... which the author even knows about because it is mentioned in footnote 14!)

More than a decade ago there had already been "20 years of attacks against the RSA cryptosystem".

https://crypto.stanford.edu/~dabo/papers/RSA-survey.pdf

Do you understand these attacks? Do you know about the next decade of attacks that followed them? If not, you shouldn't be implementing the RSA code that you're going to use in production! (Let me emphasize that I don't understand all of these attacks, which is why I don't try to implement the RSA code that I use in production.)

The tutorial even criticizes some of its own recommendations (on p. 45). If it's really oriented toward teaching people crypto that they're supposed to use in deployed systems -- which I see plenty of indications of -- this is kind of a menace. Like a section on "Curing Cancer" that says "People cure cancer with powdered rhinoceros horns", then 20 pages later "Note: I know doctors don't actually think rhinoceros horns can cure cancer".

I really like crypto education that helps people understand the big ideas and what's going on behind the scenes. I think it's great for people to get the opportunity to get to see how their crypto works. This guide could be that, if only it made clear that its advice and examples are NOT SAFE TO USE IN PRODUCTION and that you should use implementations developed and reviewed by experts. The author does not seem to have that point of view, instead saying "[coding it yourself from scratch] is possible for algorithms such as RSA, where the core RSA algorithm can be coded in a handful of lines of code. This fits in with my philosophy of programming. I think it is better to completely understand RSA implemented using Erlang bignums, rather than not understand a fast RSA algorithm written in thousands of lines of assembler and using hardware acceleration which I cannot myself validate."

That's no excuse, it's still bad crypto. If anything it's worse, because as we've just seen from your reply, some people think that experience in language design somehow translates to knowledge of cryptography.

I have nothing against the author. I just don't think the text is a proper intro to cryptography and I also think it is dangerous for a noob to read this and go implement crypto.

That being said, creating a programming language does not necessarily qualify one to do proper cryptography: they are two quite separate skill sets. In fact he himself readily admits he is not a cryptographer. There's nothing wrong with that.

EDIT: When I think about it, the fact that something like this comes from a person with stellar reputation makes it doubly scary.

> Do you realise the author is also the creator of the Erlang programming language and not some random noob from the internet?

yes. so ? would einstein make a good car mechanic ?

Appeal to accomplishment fallacy.