5 ms·

Please, please, please, do not implement any crypto after reading this. The simplistic explanation of symmetric encryption (talking about using "salts" to get d

Please, please, please, do not implement any crypto after reading this. The simplistic explanation of symmetric encryption (talking about using "salts" to get distinct ciphertext each time to "make attacker's life more difficult") is superficial and you should not feel comfortable implementing crypto after studying this tutorial. Go study something properly written by a real cryptographer. For the record, the AES algorithm itself does not encrypt arbitrarily sized data: it works on 128-bit blocks only. To make it work on arbitrary data, there's a ton of techniques that work together to make it happen that need far more care than just "adding salt". Also, read about authenticated encryption and why it is necessary. I've heard Dan Boneh's Coursera course is a good intro to basic crypto. Once again, please stay away of this guide.</scare>

arsenide 11y ago
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."
signa11 11y ago
> Please, please, please, do not implement any crypto after reading this. well, i would rather take it more as an "introduction to crypto algorithms in erlang" rather than a comprehensive guide to implementing crypto. probably more in line with dan ingalls vision of "If a system is to serve the creative spirit, it must be entirely comprehensible to a single individual", than anything else. as an example, imho, the _idea_ conveyed by "salting" is correct. however, implementing a secure financial system with that idea is not, and the author alludes this in section:1.4 of the document.
- mehrdada 11y ago
  > 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.
sjtgraham 11y ago
Do you realise the author is also the creator of the Erlang programming language and not some random noob from the internet?
- mehrdada 11y ago
  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.
  - sjtgraham 11y ago
    I must admit I find it somewhat amusing that you so vehemently attack this document when the author has published it in order for it to be verified and corrected by others.
    - jacquesm 11y ago
      The scary thing is that if it weren't from Joe Armstrong it wouldn't be taken serious at all but because it is it might get people to take his reputation and extrapolate to another field and accidents could very well happen as a consequence of that. And I'm saying that as a big fan of both Erlang and Joe Armstrong.
- jsnell 11y ago
  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.
  - sjtgraham 11y ago
timmclean 11y ago
To expand on this, here are a few mistakes that I caught while scrolling quickly: > For production applications some AES variant or RC4 would be a better choice. RC4 is not at all a good choice for new applications[1]. > SHA1 SHA-1 is broken (although not as badly as MD5). SHA-2 or SHA-3 should be preferred. > 800-bit RSA 800 bits is alarmingly low. Browsers are currently upgrading from 1024-bit certificates[2]. [1] http://blog.cryptographyengineering.com/2013/03/attack-of-week-rc4-is-kind-of-broken-in.html http://blog.cryptographyengineering.com/2013/03/attack-of-we... [2] https://blog.mozilla.org/security/2014/09/08/phasing-out-certificates-with-1024-bit-rsa-keys/ https://blog.mozilla.org/security/2014/09/08/phasing-out-cer...

arsenide 11y ago

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

signa11 11y ago

> Please, please, please, do not implement any crypto after reading this. well, i would rather take it more as an "introduction to crypto algorithms in erlang" rather than a comprehensive guide to implementing crypto. probably more in line with dan ingalls vision of "If a system is to serve the creative spirit, it must be entirely comprehensible to a single individual", than anything else. as an example, imho, the _idea_ conveyed by "salting" is correct. however, implementing a secure financial system with that idea is not, and the author alludes this in section:1.4 of the document.

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

sjtgraham 11y ago

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

mehrdada 11y ago
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.
- sjtgraham 11y ago
  I must admit I find it somewhat amusing that you so vehemently attack this document when the author has published it in order for it to be verified and corrected by others.
  - jacquesm 11y ago
    The scary thing is that if it weren't from Joe Armstrong it wouldn't be taken serious at all but because it is it might get people to take his reputation and extrapolate to another field and accidents could very well happen as a consequence of that. And I'm saying that as a big fan of both Erlang and Joe Armstrong.
jsnell 11y ago
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.
- sjtgraham 11y ago

timmclean 11y ago

To expand on this, here are a few mistakes that I caught while scrolling quickly: > For production applications some AES variant or RC4 would be a better choice. RC4 is not at all a good choice for new applications[1]. > SHA1 SHA-1 is broken (although not as badly as MD5). SHA-2 or SHA-3 should be preferred. > 800-bit RSA 800 bits is alarmingly low. Browsers are currently upgrading from 1024-bit certificates[2]. [1] http://blog.cryptographyengineering.com/2013/03/attack-of-week-rc4-is-kind-of-broken-in.html http://blog.cryptographyengineering.com/2013/03/attack-of-we... [2] https://blog.mozilla.org/security/2014/09/08/phasing-out-certificates-with-1024-bit-rsa-keys/ https://blog.mozilla.org/security/2014/09/08/phasing-out-cer...