Re: [Cryptography] RSA recommends against use of its own products.
----- Forwarded message from Jerry Leichter <leichter@lrw.com> ----- Date: Wed, 25 Sep 2013 14:12:25 -0400 From: Jerry Leichter <leichter@lrw.com> To: ianG <iang@iang.org> Cc: cryptography@metzdowd.com Subject: Re: [Cryptography] RSA recommends against use of its own products. X-Mailer: Apple Mail (2.1510) On Sep 25, 2013, at 12:31 PM, ianG <iang@iang.org> wrote:
Hi Jerry,
I appreciate the devil's advocate approach here, it has helped to get my thoughts in order! Thanks! :-)
My conclusion is: avoid all USA, Inc, providers of cryptographic products. In favor off ... who?
We already know that GCHQ is at least as heavily into this monitoring business as NSA, so British providers are out. The French have been playing the "oh, we're shocked, shocked that there's spying going on" game - but they have a long history of their own. It's been reported for many years that all Air France seats are bugged by the French security services and the information recorded has been used to help French economic interests. And even if you don't think a particular security service has been going after in-country suppliers, recall decades of US spiking of the Swiss Crypto AG machines. It's a really, really difficult problem. For deterministic algorithms, in principle, you can sandbox the implementation (both physically and in software) and compare inputs and outputs to a specification. That leaves you to worry about (a) holes in the specification itself; (b) physical leakage of extra information (Tempest-like). Both of these can be dealt with and you can gain any degree of assurance you consider necessary, at least in principle. Sure, someone can spike your hardware - but if it only does what the spec says it's supposed to do, what does that gain them? (Storing some of your secrets within the sandboxed system does them no good if they can't get the information out. Of course, physical security is essential, or your attacker will just walk the system, with all its contained information, out the door!) For probabilistic algorithms - choosing a random number is, of course, the simplest example - it's much, much harder. You're pretty much forced to rely on some mathematics and other analysis - testing can't help you much. There are really no absolutes; you really have to think about who you want to protect yourself from and how much you are willing to spend, because there's no limit on how much you *could* do. Build your own foundry? Create your own circuit synthesis code? You very quickly get yourself into a domain where only a handful of companies or countries can even begin to go. My take on this: I don't much worry about attacks against general-purpose hardware. The difficulty of modifying a processor so that you can tell when it's implementing a cipher and then do something useful about it seems insurmountable. The exception is when the hardware actually gets into the crypto game - e.g., the Intel AES extensions and the random number generator. If you're going to use these, you need to do so in a way that's secure even if those features are spiked - e.g., use the random number generator only as one of a couple of sources. Still, *much* more worrisome are the badly implemented, insecure extensions to allow remote control of the hardware, which are being discussed in a separate thread here. These are really scary - there's no protection against an attacker who can send a magic packet to your network interface and execute code with full privileges. Code, at least for symmetric cryptography primitives and modes, is simple enough that you can find it all over the place. Realistically, the worst attacks against implementations these days are timing attacks. Bernstein's ciphers have the advantage of being inherently secure against these, showing that this is possible (even if you don't necessarily trust his particular constructions). Denker's ideas about how to get random numbers whose safety is based on physical principles are great. You do have to be careful of the hardware and software you use, but since the hardware is designed for entirely different purposes (A/D sound converters) it's unlikely anyone has, or really could, spike them all. It's the asymmetric algorithms and implementations that seem to be the most vulnerable. They are complex and difficult to get right, much less to get both efficient *and* right, and protocols that use them generally need to be probabilistic - so "black box testing" isn't feasible. At the same time, they have rich mathematical structures in which we know things can be hidden. (In the symmetric case, the algorithms are generally have little mathematical structure, and we *assume* nothing can be hidden in there - but who can really say with absolute confidence.) I had a long debate here earlier on this subject, and my own conclusions remain: Use symmetric crypto as little as you possibly can. (What would be really, really nice is something like DH key exchange without all the mathematical structure.) -- Jerry _______________________________________________ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://ativel.com http://postbiota.org AC894EC5: 38A5 5F46 A4FF 59B8 336B 47EE F46E 3489 AC89 4EC5
There was a time when non-official crypto wizards recommended: From best to worst: 1. Roll your own, keep it quiet, change it often, monetize as a last resort before a cheated partner cuts your throat. 2. Avoid commercial giants most inevitably in bed with officials to screw users mercilessly laughing on the way to SWIFT. 3. Avoid products of the most powerful nations and their satellites and gangsters bypassing export controls in service to those very nations' covert armaments-economic policies. 4. Avoid any widely touted, admired, promoted as the best due to long history of dupery by this magic bullet. 5. Use off-market, black market, deep web, blacknet, onionized, layered, piggy-backed, scatalogically provened reliable based on total avoidance of the many hegemons working the cypto fleece terrain, expect to be reamed, dosed and sausaged. 6. Go back to No. 1, repeat, daily, hourly, minutely, pause, wonder is this nuts, pound delete, backspace, esc, ctrl-alt-del, smash the EENT device. 7. Pick nose, ear, tooth, scratch crotch, hmm, scratch some more, log onto revenge porn, spot your ex-partner leaking your perfect privacy prophylactic. At 08:09 AM 9/27/2013, you wrote:
----- Forwarded message from Jerry Leichter <leichter@lrw.com> -----
Date: Wed, 25 Sep 2013 14:12:25 -0400 From: Jerry Leichter <leichter@lrw.com> To: ianG <iang@iang.org> Cc: cryptography@metzdowd.com Subject: Re: [Cryptography] RSA recommends against use of its own products. X-Mailer: Apple Mail (2.1510)
On Sep 25, 2013, at 12:31 PM, ianG <iang@iang.org> wrote:
Hi Jerry,
I appreciate the devil's advocate approach here, it has helped to get my thoughts in order! Thanks! :-)
My conclusion is: avoid all USA, Inc, providers of cryptographic products. In favor off ... who?
We already know that GCHQ is at least as heavily into this monitoring business as NSA, so British providers are out. The French have been playing the "oh, we're shocked, shocked that there's spying going on" game - but they have a long history of their own. It's been reported for many years that all Air France seats are bugged by the French security services and the information recorded has been used to help French economic interests. And even if you don't think a particular security service has been going after in-country suppliers, recall decades of US spiking of the Swiss Crypto AG machines.
It's a really, really difficult problem. For deterministic algorithms, in principle, you can sandbox the implementation (both physically and in software) and compare inputs and outputs to a specification. That leaves you to worry about (a) holes in the specification itself; (b) physical leakage of extra information (Tempest-like). Both of these can be dealt with and you can gain any degree of assurance you consider necessary, at least in principle. Sure, someone can spike your hardware - but if it only does what the spec says it's supposed to do, what does that gain them? (Storing some of your secrets within the sandboxed system does them no good if they can't get the information out. Of course, physical security is essential, or your attacker will just walk the system, with all its contained information, out the door!)
For probabilistic algorithms - choosing a random number is, of course, the simplest example - it's much, much harder. You're pretty much forced to rely on some mathematics and other analysis - testing can't help you much.
There are really no absolutes; you really have to think about who you want to protect yourself from and how much you are willing to spend, because there's no limit on how much you *could* do. Build your own foundry? Create your own circuit synthesis code? You very quickly get yourself into a domain where only a handful of companies or countries can even begin to go.
My take on this: I don't much worry about attacks against general-purpose hardware. The difficulty of modifying a processor so that you can tell when it's implementing a cipher and then do something useful about it seems insurmountable. The exception is when the hardware actually gets into the crypto game - e.g., the Intel AES extensions and the random number generator. If you're going to use these, you need to do so in a way that's secure even if those features are spiked - e.g., use the random number generator only as one of a couple of sources.
Still, *much* more worrisome are the badly implemented, insecure extensions to allow remote control of the hardware, which are being discussed in a separate thread here. These are really scary - there's no protection against an attacker who can send a magic packet to your network interface and execute code with full privileges.
Code, at least for symmetric cryptography primitives and modes, is simple enough that you can find it all over the place. Realistically, the worst attacks against implementations these days are timing attacks. Bernstein's ciphers have the advantage of being inherently secure against these, showing that this is possible (even if you don't necessarily trust his particular constructions).
Denker's ideas about how to get random numbers whose safety is based on physical principles are great. You do have to be careful of the hardware and software you use, but since the hardware is designed for entirely different purposes (A/D sound converters) it's unlikely anyone has, or really could, spike them all.
It's the asymmetric algorithms and implementations that seem to be the most vulnerable. They are complex and difficult to get right, much less to get both efficient *and* right, and protocols that use them generally need to be probabilistic - so "black box testing" isn't feasible. At the same time, they have rich mathematical structures in which we know things can be hidden. (In the symmetric case, the algorithms are generally have little mathematical structure, and we *assume* nothing can be hidden in there - but who can really say with absolute confidence.) I had a long debate here earlier on this subject, and my own conclusions remain: Use symmetric crypto as little as you possibly can. (What would be really, really nice is something like DH key exchange without all the mathematical structure.)
-- Jerry
_______________________________________________ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://ativel.com http://postbiota.org AC894EC5: 38A5 5F46 A4FF 59B8 336B 47EE F46E 3489 AC89 4EC5
Remember - did at least 3 of these, 20 years ago. :) Still true - still valid - still good advice. I avoid the scratching, but maybe also this helps. --Michael Am 27.09.2013 um 14:47 schrieb John Young <jya@pipeline.com>:
There was a time when non-official crypto wizards recommended:
From best to worst:
1. Roll your own, keep it quiet, change it often, monetize as a last resort before a cheated partner cuts your throat.
2. Avoid commercial giants most inevitably in bed with officials to screw users mercilessly laughing on the way to SWIFT.
3. Avoid products of the most powerful nations and their satellites and gangsters bypassing export controls in service to those very nations' covert armaments-economic policies.
4. Avoid any widely touted, admired, promoted as the best due to long history of dupery by this magic bullet.
5. Use off-market, black market, deep web, blacknet, onionized, layered, piggy-backed, scatalogically provened reliable based on total avoidance of the many hegemons working the cypto fleece terrain, expect to be reamed, dosed and sausaged.
6. Go back to No. 1, repeat, daily, hourly, minutely, pause, wonder is this nuts, pound delete, backspace, esc, ctrl-alt-del, smash the EENT device.
7. Pick nose, ear, tooth, scratch crotch, hmm, scratch some more, log onto revenge porn, spot your ex-partner leaking your perfect privacy prophylactic.
At 08:09 AM 9/27/2013, you wrote:
----- Forwarded message from Jerry Leichter <leichter@lrw.com> -----
Date: Wed, 25 Sep 2013 14:12:25 -0400 From: Jerry Leichter <leichter@lrw.com> To: ianG <iang@iang.org> Cc: cryptography@metzdowd.com Subject: Re: [Cryptography] RSA recommends against use of its own products. X-Mailer: Apple Mail (2.1510)
On Sep 25, 2013, at 12:31 PM, ianG <iang@iang.org> wrote:
Hi Jerry,
I appreciate the devil's advocate approach here, it has helped to get my thoughts in order! Thanks! :-)
My conclusion is: avoid all USA, Inc, providers of cryptographic products. In favor off ... who?
We already know that GCHQ is at least as heavily into this monitoring business as NSA, so British providers are out. The French have been playing the "oh, we're shocked, shocked that there's spying going on" game - but they have a long history of their own. It's been reported for many years that all Air France seats are bugged by the French security services and the information recorded has been used to help French economic interests. And even if you don't think a particular security service has been going after in-country suppliers, recall decades of US spiking of the Swiss Crypto AG machines.
It's a really, really difficult problem. For deterministic algorithms, in principle, you can sandbox the implementation (both physically and in software) and compare inputs and outputs to a specification. That leaves you to worry about (a) holes in the specification itself; (b) physical leakage of extra information (Tempest-like). Both of these can be dealt with and you can gain any degree of assurance you consider necessary, at least in principle. Sure, someone can spike your hardware - but if it only does what the spec says it's supposed to do, what does that gain them? (Storing some of your secrets within the sandboxed system does them no good if they can't get the information out. Of course, physical security is essential, or your attacker will just walk the system, with all its contained information, out the door!)
For probabilistic algorithms - choosing a random number is, of course, the simplest example - it's much, much harder. You're pretty much forced to rely on some mathematics and other analysis - testing can't help you much.
There are really no absolutes; you really have to think about who you want to protect yourself from and how much you are willing to spend, because there's no limit on how much you *could* do. Build your own foundry? Create your own circuit synthesis code? You very quickly get yourself into a domain where only a handful of companies or countries can even begin to go.
My take on this: I don't much worry about attacks against general-purpose hardware. The difficulty of modifying a processor so that you can tell when it's implementing a cipher and then do something useful about it seems insurmountable. The exception is when the hardware actually gets into the crypto game - e.g., the Intel AES extensions and the random number generator. If you're going to use these, you need to do so in a way that's secure even if those features are spiked - e.g., use the random number generator only as one of a couple of sources.
Still, *much* more worrisome are the badly implemented, insecure extensions to allow remote control of the hardware, which are being discussed in a separate thread here. These are really scary - there's no protection against an attacker who can send a magic packet to your network interface and execute code with full privileges.
Code, at least for symmetric cryptography primitives and modes, is simple enough that you can find it all over the place. Realistically, the worst attacks against implementations these days are timing attacks. Bernstein's ciphers have the advantage of being inherently secure against these, showing that this is possible (even if you don't necessarily trust his particular constructions).
Denker's ideas about how to get random numbers whose safety is based on physical principles are great. You do have to be careful of the hardware and software you use, but since the hardware is designed for entirely different purposes (A/D sound converters) it's unlikely anyone has, or really could, spike them all.
It's the asymmetric algorithms and implementations that seem to be the most vulnerable. They are complex and difficult to get right, much less to get both efficient *and* right, and protocols that use them generally need to be probabilistic - so "black box testing" isn't feasible. At the same time, they have rich mathematical structures in which we know things can be hidden. (In the symmetric case, the algorithms are generally have little mathematical structure, and we *assume* nothing can be hidden in there - but who can really say with absolute confidence.) I had a long debate here earlier on this subject, and my own conclusions remain: Use symmetric crypto as little as you possibly can. (What would be really, really nice is something like DH key exchange without all the mathematical structure.)
-- Jerry
_______________________________________________ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://ativel.com http://postbiota.org AC894EC5: 38A5 5F46 A4FF 59B8 336B 47EE F46E 3489 AC89 4EC5
participants (3)
-
Eugen Leitl -
jd.cypherpunks＠gmail.com -
John Young