11 ms·

Good thing Satoshi wasn't scared of cryptography or we wouldn't have bitcoin. Also good thing the Truecrypt devs weren't scared of it, or the Debian devs, or th

Good thing Satoshi wasn't scared of cryptography or we wouldn't have bitcoin. Also good thing the Truecrypt devs weren't scared of it, or the Debian devs, or the OpenBSD devs and others who gave us OpenSSH. Moxie Marlinspike doesn't seem to be scared of it either. According to him it's not impossible to learn simple, tried and true methods for crypto engineering that are all spelled out in Schneier's books and various white papers. These standards were completely ignored by the cryptocat guys (and ignored repeated warnings from auditors). So if you can read, comprehend and do bare minimum research of NIST standards you're pretty safe rolling your own crypto software if you know about attention to detail, the doom principal, PRNGs and their flaws, and know not to attempt to make your own primitives. If you guy's can push out incredibly complex and relatively secure financial trading software there's no reason you can't roll your own SHA-256 on your Android phone replacing SHA-1 FDE or even design Redphone like Moxie did. Would also help if you hung around hashcat forums, read Schneier's cryptogram newsletter, and watched some lectures about software crypto engineering.

betterunix 13y ago
"Good thing Satoshi wasn't scared of cryptography or we wouldn't have bitcoin." ...a system for which there is no security definition, no security proof, a known polynomial time attack (for some vague notion of "attack"), etc. I do not think this is the best example you can come up with. One of the problems here is that cryptography cannot just be cobbled together from component pieces. Things do not always compose securely. Bitcoin is not a signature system, so even if the ECDSA implementation is perfect it does not guarantee that Bitcoin is secure. One of the things that makes cryptography, especially in the public-key setting, difficult is the very precise assumptions and very precise definitions of security; it is easy to make an assumption that is not implied by a security definition, and very easy to violate a key assumption without even realizing it. Worse, cryptosystems must be composed with other software, and such compositions can be insecure (which is basically what happened with Skype). It's not that people should be scared away. Rather, we need to develop better tools that help programmers catch or avoid these kinds of bugs.
dfc 13y ago
Satoshi is more than likely one or more individuals with significant crypto experience. Open{SSH/BSD/SSL} developers have significant crypto experience. Don't get me wrong I am a huge Debian fanboy, but how much crypto code do Debian developers write?
- betterunix 13y ago
  "Satoshi is more than likely one or more individuals with significant crypto experience" I doubt that very much, based on reading the original Bitcoin paper and his posts to the cryptography mailing list. More than likely Satoshi was an amateur/enthusiast.
- dllthomas 13y ago
  > how much crypto code do Debian developers write? The historical answer seems to have been "too much"...
  - mcguire 13y ago
    Didn't they break OpenSSL quite significantly?
    - dllthomas 13y ago
      http://www.debian.org/security/2008/dsa-1571 http://www.debian.org/security/2008/dsa-1571 "Luciano Bello discovered that the random number generator in Debian's openssl package is predictable. This is caused by an incorrect Debian-specific change to the openssl package (CVE-2008-0166). As a result, cryptographic key material may be guessable."
  - dfc 13y ago
    The openssl keys were a disaster, no doubt. Are there other examples?
    - dllthomas 13y ago
      Not that I'm aware of; I was just referencing the one. But the one certainly provides some support for "don't touch crypto" as a good guideline.
tptacek 13y ago
No, some "tried and true" methods of using crypto are in one of Schneier's books, _Practical Cryptography_. _Practical_ is great, but it's not complete, a fact mitigated by the effort Schneier and Furgusen go to in that book to convince people not to write casual crypto. The methods described in _Applied Cryptography_ are unfortunately well-tried, but few of them are true. _Applied_ is an almanac of cryptographic concepts. Where _Practical_ tries hard to present best practices at every point in the book, _Applied_ instead strives for the broadest coverage; it's a survey, not an instruction guide. Unfortunately for all of us, ~20 years of _Applied_ readers have tried to put directly into practice the material in that book, much of which is (relevant to modern standards) half-baked. It's also important to know that _Practical_ is also showing its age. There are very common, very serious vulnerabilities that _Practical_ does very little to prevent. For instance, "Design Rule 4" in _Practical_, "The Horton Principle", implies that message authentication should precede encryption. This construction is now disfavored; protocols that use mac-then-encrypt have been broken with side channels abetted by attacker chosen ciphertext. Other concepts missing from _Practical_: elliptic curve --- particularly given endangered status of RSA, which would be a nit if not for the extremely detailed coverage Schneier gives to more theoretical threats to AES, (EC)DSA parameter tampering, the notion of minimizing randomness from cryptosystems, the modern AE modes, an in-depth treatment of side channels (where "in-depth" might mean "at least as much coverage as is given to the question of what block cipher mode to use") --- particularly error oracles, applications of hash collisions, RSA message formatting (it doesn't even cover OAEP), and secure key derivation. I write this from a place of love; _Practical Cryptography_ is one of my all-time favorite software security books. It's one of those books you can "read backwards" to learn how to break systems in addition to learning how to build them. With age, though, _Practical_ is becoming more useful as a breaker's guide and less and a builder's guide. There is no book anywhere that a generalist developer can read to learn how to build a secure cryptosystem from scratch, and generalist developers should be relying instead on high-level libraries like Keyczar and Nacl. I don't know a think about Satoshi's competence (I couldn't, because nobody knows who he is), but Moxie Marlinspike has spent over 15 years building his competence. If you're Moxie, build whatever you want.
- stplsd 13y ago
  Any comments about "Handbook of Applied Cryptography"? http://cacr.uwaterloo.ca/hac/ http://cacr.uwaterloo.ca/hac/
23david 13y ago
Thanks for sharing your perspective and knowledge here. Really important to know how to be safe and what to look out for. I wasn't getting the feeling that many infosec professionals on HN were able/willing to outline reasonable guidelines for experienced devs/admins to follow.
- tptacek 13y ago
  This too is an irritating statement given that me, Sean, and Marcin have been having 1:1 manual email correspondences with something like eight thousand strangers to teach them crypto attacks (the current standings are level 0 (8152), level 1 (608), level 2 (181), level 3 (61), level 4 (58), level 5 (42), level 6 (51) --- http://tinyurl.com/mtsocrypt http://tinyurl.com/mtsocrypt). What I perceive is that the problem isn't really that "infosec professionals on HN" are unwilling to teach developers, but rather that we're not teaching developers what they want to hear about crypto.
  - 23david 13y ago
    Thanks for your hard work and for setting that up. Sounds like an awesome program. If I had more time right now, I'd love to check it out more. I think we're on the same page here, but coming at it from different perspectives. I often have to find ways to secure as best as possible insecure systems that are already built. And I'm trying to find ways to incrementally improve systems over time so they get more and more secure. I can't wait to deploy code until its 100% secure, or the startups I've worked for would just find someone else to do the job who wouldn't be a 'blocker'.
    - tptacek 13y ago
      I appreciate your appreciation, and note also that we're well compensated in other ways for doing that work. The challenges will be around for several more months. I'm just rebutting the idea --- which maybe you didn't mean --- that elitist infosec people were trying to set themselves up as gatekeepers. The opposite is true. Sean and I are working hard on getting as much of what we know about breaking cryptosystems into the challenges (set 7 is coming out probably next week, and I'm working on ECC stuff for set 8 now). We want the info out. But look at the numbers I just posted: 8100 people have started the challenges. Just 51 people have managed to finish. I like the challenges a lot, but candidly: on the scale of professional cryptographic research, it's pretty basic; being among the 0.5% of challenge finishers wouldn't qualify you to design cryptosystems.
josephlord 13y ago
For Bitcoin what would the consequences have been of getting it wrong at the beginning? Essentially no money would have been lost, no lives lost etc. Also it appears that the person who did create it had a good understanding of crypto and the recent literature (and may even have written it). It is possible to learn it but learn it first and ship it to the public later or if you must with great big experiment/insecure warnings all over it.
dobbsbob 13y ago
What I've been doing is just reading the code of already audited inplementations of cryptography to understand it better. For example Skein/Threefish. As a test to see what kind of speed SHA-3 would have on a mobile device I implemented my own Threefish SHA3 on Android for full disc encryption. First I looked at Pyskein, Java skein and all the other implementations released by pros. Then I looked at everything the authors who submitted other NIST3 finalists wrote, blogged and argued about on mailing lists. Then I read about the android SHA-1 design decisions. Then I watched lectures on crypto software engineering. Then I looked up everything about accelerometer side channels, PRNGs problems and gotchas, Moxies blog posts, and his yaffs source he used for whispercore, and went through tons of Dos and Dont comments both here and on Schneier's blogs about writing secure software. Then I watched BSDcon coding the openbsd secure way, and talked with maintainers who implement crypto on the openbsd mailing list. Result is SHA3 full disk for Android. Its certainly not foolproof or nor do I claim its secure but a lot of people are digging through the source and forensics hackers are interested in seeing what they can do with it. I realize I broke cardinal rule of using something that hasn't been proven for decades first (like AES 256) but its been a good learning experience thats for sure.
- tptacek 13y ago
  I think it's hard to know what you don't know.
bigiain 13y ago
You're right, but there's still a valid point I think. I'm a reasonably competent home mechanic. I happily rebuild engines and gearboxes for cars and motorcycles at home. I can modify and tune engines. I easily do all my households vehicle maintenance. And I happily help friends out with their repairs and maintenance. One thing I won't do though, is fix a friends brakes. I'm happy working on my own brakes, and happy to accept the responsibility for my actions. I won't take hat responsibility on for friends though. If you're not happy/capable of fixing your own brakes, take it to someone qualified and insured. I think crypto is the same. There's nothing wrong with learning about and writing your own crypto as a curious amateur. But deploying that crypto where it can get other people killed is a bigger deal. Don't be "the cryptocat guy", "Oh yeah, I just found out you can't use water for brake fluid, turns out it boils when it gets hot! Who knew? Anyway, I just put brake fluid in my brakes, you should probably upgrade yours too sometime…" I think if you want to _deploy_ crypto to other people, you owe it to yourself to have at least as much "professional training" as an auto mechanic gets before they're allowed to repair your brakes. And to further stretch the analogy - I'll point out tha most mechanics these days don't "repair" much in brake systems, they'll just replace large components - its becoming more common to not be able to buy seals and pistons any more - you're expected to just replace entire calipers or master cylinders. In my head that's the same approach as saying "I'll choose to use GPG or OpenSSL, but I won't 'do my own crypto'" - for someone who's _not_ prepared to put in a few hundred hours of proper crypto training, I think "rolling your own crypto software" is something best left to personal/educational projects, and never deployed I a way that other people might rely upon it.
lightyrs 13y ago
Please provide evidence that Satoshi exists.
- kevinwallace 13y ago
  http://bitcoin.org/bitcoin.pdf http://bitcoin.org/bitcoin.pdf
  - lightyrs 13y ago
    I'm sorry — I should have said 'proof'.

betterunix 13y ago

"Good thing Satoshi wasn't scared of cryptography or we wouldn't have bitcoin." ...a system for which there is no security definition, no security proof, a known polynomial time attack (for some vague notion of "attack"), etc. I do not think this is the best example you can come up with. One of the problems here is that cryptography cannot just be cobbled together from component pieces. Things do not always compose securely. Bitcoin is not a signature system, so even if the ECDSA implementation is perfect it does not guarantee that Bitcoin is secure. One of the things that makes cryptography, especially in the public-key setting, difficult is the very precise assumptions and very precise definitions of security; it is easy to make an assumption that is not implied by a security definition, and very easy to violate a key assumption without even realizing it. Worse, cryptosystems must be composed with other software, and such compositions can be insecure (which is basically what happened with Skype). It's not that people should be scared away. Rather, we need to develop better tools that help programmers catch or avoid these kinds of bugs.

dfc 13y ago

Satoshi is more than likely one or more individuals with significant crypto experience. Open{SSH/BSD/SSL} developers have significant crypto experience. Don't get me wrong I am a huge Debian fanboy, but how much crypto code do Debian developers write?

betterunix 13y ago
"Satoshi is more than likely one or more individuals with significant crypto experience" I doubt that very much, based on reading the original Bitcoin paper and his posts to the cryptography mailing list. More than likely Satoshi was an amateur/enthusiast.
dllthomas 13y ago
> how much crypto code do Debian developers write? The historical answer seems to have been "too much"...
- mcguire 13y ago
  Didn't they break OpenSSL quite significantly?
  - dllthomas 13y ago
    http://www.debian.org/security/2008/dsa-1571 http://www.debian.org/security/2008/dsa-1571 "Luciano Bello discovered that the random number generator in Debian's openssl package is predictable. This is caused by an incorrect Debian-specific change to the openssl package (CVE-2008-0166). As a result, cryptographic key material may be guessable."
- dfc 13y ago
  The openssl keys were a disaster, no doubt. Are there other examples?
  - dllthomas 13y ago
    Not that I'm aware of; I was just referencing the one. But the one certainly provides some support for "don't touch crypto" as a good guideline.

tptacek 13y ago

No, some "tried and true" methods of using crypto are in one of Schneier's books, _Practical Cryptography_. _Practical_ is great, but it's not complete, a fact mitigated by the effort Schneier and Furgusen go to in that book to convince people not to write casual crypto. The methods described in _Applied Cryptography_ are unfortunately well-tried, but few of them are true. _Applied_ is an almanac of cryptographic concepts. Where _Practical_ tries hard to present best practices at every point in the book, _Applied_ instead strives for the broadest coverage; it's a survey, not an instruction guide. Unfortunately for all of us, ~20 years of _Applied_ readers have tried to put directly into practice the material in that book, much of which is (relevant to modern standards) half-baked. It's also important to know that _Practical_ is also showing its age. There are very common, very serious vulnerabilities that _Practical_ does very little to prevent. For instance, "Design Rule 4" in _Practical_, "The Horton Principle", implies that message authentication should precede encryption. This construction is now disfavored; protocols that use mac-then-encrypt have been broken with side channels abetted by attacker chosen ciphertext. Other concepts missing from _Practical_: elliptic curve --- particularly given endangered status of RSA, which would be a nit if not for the extremely detailed coverage Schneier gives to more theoretical threats to AES, (EC)DSA parameter tampering, the notion of minimizing randomness from cryptosystems, the modern AE modes, an in-depth treatment of side channels (where "in-depth" might mean "at least as much coverage as is given to the question of what block cipher mode to use") --- particularly error oracles, applications of hash collisions, RSA message formatting (it doesn't even cover OAEP), and secure key derivation. I write this from a place of love; _Practical Cryptography_ is one of my all-time favorite software security books. It's one of those books you can "read backwards" to learn how to break systems in addition to learning how to build them. With age, though, _Practical_ is becoming more useful as a breaker's guide and less and a builder's guide. There is no book anywhere that a generalist developer can read to learn how to build a secure cryptosystem from scratch, and generalist developers should be relying instead on high-level libraries like Keyczar and Nacl. I don't know a think about Satoshi's competence (I couldn't, because nobody knows who he is), but Moxie Marlinspike has spent over 15 years building his competence. If you're Moxie, build whatever you want.

stplsd 13y ago
Any comments about "Handbook of Applied Cryptography"? http://cacr.uwaterloo.ca/hac/ http://cacr.uwaterloo.ca/hac/

23david 13y ago

Thanks for sharing your perspective and knowledge here. Really important to know how to be safe and what to look out for. I wasn't getting the feeling that many infosec professionals on HN were able/willing to outline reasonable guidelines for experienced devs/admins to follow.

tptacek 13y ago
This too is an irritating statement given that me, Sean, and Marcin have been having 1:1 manual email correspondences with something like eight thousand strangers to teach them crypto attacks (the current standings are level 0 (8152), level 1 (608), level 2 (181), level 3 (61), level 4 (58), level 5 (42), level 6 (51) --- http://tinyurl.com/mtsocrypt http://tinyurl.com/mtsocrypt). What I perceive is that the problem isn't really that "infosec professionals on HN" are unwilling to teach developers, but rather that we're not teaching developers what they want to hear about crypto.
- 23david 13y ago
  Thanks for your hard work and for setting that up. Sounds like an awesome program. If I had more time right now, I'd love to check it out more. I think we're on the same page here, but coming at it from different perspectives. I often have to find ways to secure as best as possible insecure systems that are already built. And I'm trying to find ways to incrementally improve systems over time so they get more and more secure. I can't wait to deploy code until its 100% secure, or the startups I've worked for would just find someone else to do the job who wouldn't be a 'blocker'.
  - tptacek 13y ago
    I appreciate your appreciation, and note also that we're well compensated in other ways for doing that work. The challenges will be around for several more months. I'm just rebutting the idea --- which maybe you didn't mean --- that elitist infosec people were trying to set themselves up as gatekeepers. The opposite is true. Sean and I are working hard on getting as much of what we know about breaking cryptosystems into the challenges (set 7 is coming out probably next week, and I'm working on ECC stuff for set 8 now). We want the info out. But look at the numbers I just posted: 8100 people have started the challenges. Just 51 people have managed to finish. I like the challenges a lot, but candidly: on the scale of professional cryptographic research, it's pretty basic; being among the 0.5% of challenge finishers wouldn't qualify you to design cryptosystems.

josephlord 13y ago

For Bitcoin what would the consequences have been of getting it wrong at the beginning? Essentially no money would have been lost, no lives lost etc. Also it appears that the person who did create it had a good understanding of crypto and the recent literature (and may even have written it). It is possible to learn it but learn it first and ship it to the public later or if you must with great big experiment/insecure warnings all over it.

dobbsbob 13y ago

What I've been doing is just reading the code of already audited inplementations of cryptography to understand it better. For example Skein/Threefish. As a test to see what kind of speed SHA-3 would have on a mobile device I implemented my own Threefish SHA3 on Android for full disc encryption. First I looked at Pyskein, Java skein and all the other implementations released by pros. Then I looked at everything the authors who submitted other NIST3 finalists wrote, blogged and argued about on mailing lists. Then I read about the android SHA-1 design decisions. Then I watched lectures on crypto software engineering. Then I looked up everything about accelerometer side channels, PRNGs problems and gotchas, Moxies blog posts, and his yaffs source he used for whispercore, and went through tons of Dos and Dont comments both here and on Schneier's blogs about writing secure software. Then I watched BSDcon coding the openbsd secure way, and talked with maintainers who implement crypto on the openbsd mailing list. Result is SHA3 full disk for Android. Its certainly not foolproof or nor do I claim its secure but a lot of people are digging through the source and forensics hackers are interested in seeing what they can do with it. I realize I broke cardinal rule of using something that hasn't been proven for decades first (like AES 256) but its been a good learning experience thats for sure.

tptacek 13y ago
I think it's hard to know what you don't know.

bigiain 13y ago

You're right, but there's still a valid point I think. I'm a reasonably competent home mechanic. I happily rebuild engines and gearboxes for cars and motorcycles at home. I can modify and tune engines. I easily do all my households vehicle maintenance. And I happily help friends out with their repairs and maintenance. One thing I won't do though, is fix a friends brakes. I'm happy working on my own brakes, and happy to accept the responsibility for my actions. I won't take hat responsibility on for friends though. If you're not happy/capable of fixing your own brakes, take it to someone qualified and insured. I think crypto is the same. There's nothing wrong with learning about and writing your own crypto as a curious amateur. But deploying that crypto where it can get other people killed is a bigger deal. Don't be "the cryptocat guy", "Oh yeah, I just found out you can't use water for brake fluid, turns out it boils when it gets hot! Who knew? Anyway, I just put brake fluid in my brakes, you should probably upgrade yours too sometime…" I think if you want to _deploy_ crypto to other people, you owe it to yourself to have at least as much "professional training" as an auto mechanic gets before they're allowed to repair your brakes. And to further stretch the analogy - I'll point out tha most mechanics these days don't "repair" much in brake systems, they'll just replace large components - its becoming more common to not be able to buy seals and pistons any more - you're expected to just replace entire calipers or master cylinders. In my head that's the same approach as saying "I'll choose to use GPG or OpenSSL, but I won't 'do my own crypto'" - for someone who's _not_ prepared to put in a few hundred hours of proper crypto training, I think "rolling your own crypto software" is something best left to personal/educational projects, and never deployed I a way that other people might rely upon it.

lightyrs 13y ago

Please provide evidence that Satoshi exists.

kevinwallace 13y ago
http://bitcoin.org/bitcoin.pdf http://bitcoin.org/bitcoin.pdf
- lightyrs 13y ago
  I'm sorry — I should have said 'proof'.