Re: Who cares about side-channel attacks?
Ben Laurie [EMAIL PROTECTED] writes: Peter Gutmann wrote: Given the string of attacks on crypto in embedded devices (XBox, iPhone, iOpener, Wii, some not-yet-published ones on HDCP devices :-), etc) this is by far the most at-risk category because there's a huge incentive to attack them, the result affects tens/hundreds of millions of devices, and the attacks are immediately and widely actively exploited (modchips/device unlocking/etc, an important difference between this and academic proof-of-concept attacks), so this is the one where I'd expect the vendors to care most. But they've all been unlocked using easier attacks, surely? The published ones seem to be the (relatively) easy ones, but the ones that have been tried (and either not published or just had the easy outcome published) have been pretty amazing. This is another one of these things where real figures are going to be near-impossible to come by, even harder than my hypothetical public vendor survey of who uses SCA protection. You'd have to read about 20 blogs and a hundred mailing lists, many private, just to keep up, but from various informal contacts with people working in this area it seems you're not looking at anything like the conventional identify the weakest point, then attack there approach. Instead what's being done is more like the Iraqi weapons program prior to 1991 where they were using every imaginable type of approach, including ones like calutrons that had been abandoned decades earlier by everyone else, for a first-past-the-post finish, they'd try anything and everything and whatever got them there first would be declared the winner. It's the same with these attacks, whenever I've asked have you tried X the answer is invariably yes, we have. This style of attack is quite different from the usual academic model, it neatly illustrates Bruce Schneier's comment that a defender has to defend every single point along the line while an attacker only has to find a single weakness. In this case it seems to be literally true, and the weakness won't necessarily be the actual weakest point but merely the point where an attacker with sufficient skill and access to the right tools got in. Look at the XBox attacks for example, there's everything from security 101 lack of checking/validation and 1980s MSDOS-era A20# issues through to Bunnie Huang's FPGA-based homebrew logic analyser and use of timing attacks to recover device keys (oh, and there's an example of a real-world side-channel attack for you), there's no rhyme or reason to them, it's just hammer away at everything with anything you've got and exploit the first bit that fails. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Who cares about side-channel attacks?
Peter Gutmann wrote: Ben Laurie [EMAIL PROTECTED] writes: Peter Gutmann wrote: Given the string of attacks on crypto in embedded devices (XBox, iPhone, iOpener, Wii, some not-yet-published ones on HDCP devices :-), etc) this is by far the most at-risk category because there's a huge incentive to attack them, the result affects tens/hundreds of millions of devices, and the attacks are immediately and widely actively exploited (modchips/device unlocking/etc, an important difference between this and academic proof-of-concept attacks), so this is the one where I'd expect the vendors to care most. But they've all been unlocked using easier attacks, surely? The published ones seem to be the (relatively) easy ones, but the ones that have been tried (and either not published or just had the easy outcome published) have been pretty amazing. This is another one of these things where real figures are going to be near-impossible to come by, even harder than my hypothetical public vendor survey of who uses SCA protection. You'd have to read about 20 blogs and a hundred mailing lists, many private, just to keep up, but from various informal contacts with people working in this area it seems you're not looking at anything like the conventional identify the weakest point, then attack there approach. Instead what's being done is more like the Iraqi weapons program prior to 1991 where they were using every imaginable type of approach, including ones like calutrons that had been abandoned decades earlier by everyone else, for a first-past-the-post finish, they'd try anything and everything and whatever got them there first would be declared the winner. It's the same with these attacks, whenever I've asked have you tried X the answer is invariably yes, we have. This style of attack is quite different from the usual academic model, it neatly illustrates Bruce Schneier's comment that a defender has to defend every single point along the line while an attacker only has to find a single weakness. In this case it seems to be literally true, and the weakness won't necessarily be the actual weakest point but merely the point where an attacker with sufficient skill and access to the right tools got in. Look at the XBox attacks for example, there's everything from security 101 lack of checking/validation and 1980s MSDOS-era A20# issues through to Bunnie Huang's FPGA-based homebrew logic analyser and use of timing attacks to recover device keys (oh, and there's an example of a real-world side-channel attack for you), there's no rhyme or reason to them, it's just hammer away at everything with anything you've got and exploit the first bit that fails. Now you seem to answer the question yourself: SCA protections apply to a single class of attacks, while there are many. Going back to who cares, having done certification consulting assignments for some devices with crypto, when there was no checklist-based standard to apply, good practice security criteria (to be briefly documented in the report) would include the following questions: (A) Is the secret key inside a device unit applicable to this single unit, or is it a system-wide, or domain-wide key? That's a key management scheme question. (B) Is the attack destructive? Which device unit features (especially be in working order, but also be absent of actual tampering evidence or even remain under the control of the legitimate user without interruptions longer than X ) need to be impaired for a given class of attack to succeed? This question pertains to the secret key as in (A) and also to any public-key-to-be-integrity-protected which would prevent malicious code download. That's a product design question. (C) What are the incentives, if any, for the legitimate user to remain well-behaved in the human aspects of device protection? (E.g. a merchant has some incentive to maintain a payment authorization device in good working order.) This leads to the question of insider threats, so satisfactory answers in this area are seldom present. This is an application design question. This gives an idea of analyses that drives security-related spendings (in my limited experience). Clients (intend to) pay for protections that will prevent financial losses and major public relations impacts (and then cut operating budgets soon after the project gets its authorization!). The consultant study must clearly link attackers' motivations to impacts and to countermeasures. Refinements to the above analysis methodology call for the same creative mind that you assume from the part of the attackers. E.g. the usefulness of a device unit clone for the attacker should be considered for questions (B) and (C). Does SCA protection enter the picture? Marginally at best. Regards, -- - Thierry Moreau CONNOTECH Experts-conseils inc. 9130 Place de Montgolfier Montreal, Qc Canada H2M 2A1 Tel.: (514)385-5691 Fax: (514)385-5900 web site:
Re: the skein hash function
Eugen Leitl and Stephan Somogyi [EMAIL PROTECTED] wrote about the Skein hash function announcement. http://www.schneier.com/blog/archives/2008/10/the_skein_hash.html?1 http://www.schneier.com/skein.html One thing I noticed on a first read-through was a discussion of speed for ASICs vs. general CPUs. Their implementation on CPUs was about 4 Gbps/core, and their estimate of ASIC speed was about 5 Gbps using about 80K gates worth of ASIC, and their hash-tree mode makes parallelization efficient. Their conclusion was that ASICs don't give you much of a speedup, but may save power or cost. A quick google-look at ASICs showed a number in the range of 300K-20M gates, so hash-trees could probably get speedups of up to 20-100x if you can keep from becoming input-speed-bound. The 300K chips were about $6, 5M at $50 and 350MHz, which is somewhat faster than the Skein team estimate, and some of the denser chips didn't mention price but were starting to use 45nm technology. So if Skein becomes popular, ASIC accelerator hardware may be practical for higher-speed applications. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Parallel Skein Hash Construction based on the Subset Sum Problem?
On Wed, Oct 29, 2008 at 9:23 AM, Stephan Somogyi wrote: The Skein team has announced its submission to the NIST hash competition: http://www.schneier.com/skein.html Now that we've all had a chance to read the Skein algorithm, I've got a question for the list: Would it be possible to construct an efficient parallel version of Skein with output size N by creating intermediate results of size 2N, adding them as integers, and then hashing this sum of intermediate results as the final result? (That is, would such a construction be faster than the Skein tree hashing?) I suspect that this construction would be secure according to the computational difficulty of solving the Subset Sum problem (known to be NP-complete), but haven't rigorously confirmed this. Skein is able to efficiently create larger outputs, so such a construction like this would be easier with Skein than with, say SHA-512. For example, with Skein-256, you could hash each 256-bit (or larger, depending on leaf size choice) message chunk into a 512-bit, or 768-bit intermediate value. This value would then be added to all other similar hash results (mod 2^512 or 2^768), and this result would be hashed one more time for the final result. It's necessary to make the intermediate results at least 2x the final hash size because the best known solution to the subset sum problem is solvable in 2^(N/2) operations. There's also the issue of tying the complexity of an addition operation to the complexity of computing a single hash result (e.g., 1 N-bit Hash might equal 100 N-bit modular adds). For this reason, using 3x the final hash size for intermediates would be more conservative. General Comments on Skein: Overall, I'm very happy with the results of Skein, and the three-fish project. When Ron Rivest described his Halloween hashing function during Crypto 2008, I liked its simplicity (only simple operators), but disliked that it was slower than SHA-256 and SHA-512. Skein has both delivered on security (so we think) and is faster and simpler than existing NIST hashing functions and block ciphers. In my opinion, SHA-2 and AES have already pegged the meter on practical security (of course, this may one day be false...), but there hasn't been enough emphasis on efficiency, cost, and parallelism. By using 64-bit addition as one of Skein's basic operations, the resistance against Shamir's Cube attack increases, although the hardware complexity increases quite a bit over Ron Rivest group's choice of operators that have no carry. I suspect that (as with the AES competition), that all of the contestants of the final round with be secure, and the winner will be the one that is most efficient, and to some extend, most flexible (although too much flexibility causes implementation issues when non-cryptographers have to write code to support all the options, and the designers have to be smart enough to pick the correct configuration). With more submissions like this, I expect we will be poised for an exciting NIST hash competition! Cheers, -Matt Matt Ball, IEEE P1619.x SISWG Chair Cell: 303-717-2717 http://www.linkedin.com/in/matthewvball http://www.mavaball.net/ - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Donald Knuth stops paying for errata
It seems that Donald Knuth had his bank accounts attacked not once but three times using his checking account number off of checks he sent out for bounties for flaws in his books and software, and is thus ending a practice of nearly 40 years. Rather sad. I mark this as another milestone in the slow destruction of the idea that it is okay for an account number to be the secret used to effect payment in a transaction system. http://www-cs-faculty.stanford.edu/~knuth/news08.html Perry -- Perry E. Metzger[EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
