3 ms·

What needs to be added to this guide to make it comprehensive enough for use?

mehrdada 11y ago
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.
schoen 11y ago
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 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 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."

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.

schoen 11y ago

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