Re: non 2048-bit keys
... 2048-bit keys performing at 1/9th of 1024-bit. My own internal benchmarks have been closer to 1/7th to 1/8th. Either way, that's back in line with the above stated 90-95% overhead. Meaning, in Dan's words 2048 ain't happening. Can I abuse a phrase and call this binary thinking? There is no reason that the next step after 1024 bits has to be 2048 bits. How about 1032 bits? Or 1040? Or 1104? How about 1200 bits? How about 1536? How about 1600? 1808? I have a theory that if everyone picked a pseudo-random key size above 1024 and below 2048, rather than standardizing on Yet Another Fixed Keysize, we'd avoid making a powerful incentive for bad guys to build a key-cracker optimized for one size. Which incentive we have currently created at 1024 bits. It's the Microsoft Windows of key sizes -- the target that gets you 90+% of the market. So pick a larger size than 1024 that your server load can live with, even if it isn't 2048. And don't tell anybody else what size you picked :-). John - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
RE: Has there been a change in US banking regulations recently?
On Fri, 2010-08-13 at 14:55 -0500, eric.lengve...@wellsfargo.com wrote: Moore's law helped immensely here. In the last 5 years systems have gotten about 8 times faster, reducing the processing cost of crypto a lot. The big drawback is that those who want to follow NIST's recommendations to migrate to 2048-bit keys will be returning to the 2005-era overhead. Either way, that's back in line with the above stated 90-95% overhead. Meaning, in Dan's words 2048 ain't happening. I'm under the impression that 2048 keys are now insecure mostly due to advances in factoring algorithms that make the attack and the encryption effort closer to, but by no means identical to, scaling with the same function of key length. This makes the asymmetric cipher have a lower ratio of attack cost to encryption cost at any given key length, but larger key lengths still yield *much* higher ratios of attack cost to encryption cost. At 2048 bits, I think that with Moore's law over the next decade or two dropping attack costs and encryption costs by the same factor, attack costs should remain comfortably out of reach while encryption costs return to current levels now practical for shorter keys. Of course, this reckons without the potential for unforseen advances in factoring or Quantum computing. There are some possibilities, my co-workers and I have discussed. For purely internal systems TLS-PSK (RFC 4279) provides symmetric encryption through pre-shared keys which provides us with whitelisting as well as removing asymmetric crypto. That's probably a good idea. We've placed a lot of stock in public- key systems because of some neat mathematical properties that seemed to conform to someone's needs for an online business model involving the introduction of strangers who want to do business with each other. But if you can handle key distribution internally by walking down the hall or mailing a CD-ROM preloaded with keys instead of by trusting the network the keys are supposed to secure, you really don't need Public-key crypto's neat mathematical properties. Bear - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
RE: Has there been a change in US banking regulations recently?
Ray Dillinger b...@sonic.net writes: On Fri, 2010-08-13 at 14:55 -0500, eric.lengve...@wellsfargo.com wrote: The big drawback is that those who want to follow NIST's recommendations to migrate to 2048-bit keys will be returning to the 2005-era overhead. Either way, that's back in line with the above stated 90-95% overhead. Meaning, in Dan's words 2048 ain't happening. I'm under the impression that 2048 keys are now insecure mostly due to advances in factoring algorithms Insecure against what? Given the million [0] easier attack vectors against web sites, which typically range from trivial all the way up to relatively easy, why would any rational attacker bother with factoring even a 1024-bit key, with a difficulty level of quite hard? It's not as if these keys have to remain secure for decades, since the 12-month CA billing cycle means that you have to refresh them every year anyway. Given both the state of PKI and the practical nonexistence of attacks on crypto of any strength because it's not worth the bother, would the attackers even notice if you used a 32-bit RSA key? How would an adversary effectively scale and monetise an attack based on being able to break an RSA key, even if it was at close to zero cost? The unfortunate effect of such fashion-statement crypto recommendations as you must use 2K bit keys, regardless of the threat environment is that what it actually says is you must not use SSL on your web site. Le mieux est l'ennemi du bien strikes again. Peter. [0] Figure exaggerated slightly for effect. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: non 2048-bit keys
If an attacker creating a special-purpose machine to break your keys is a realistic scenario, why are you even considering keys of that size? Best regards, Samuel Neves On 15-08-2010 04:25, John Gilmore wrote: ... 2048-bit keys performing at 1/9th of 1024-bit. My own internal benchmarks have been closer to 1/7th to 1/8th. Either way, that's back in line with the above stated 90-95% overhead. Meaning, in Dan's words 2048 ain't happening. Can I abuse a phrase and call this binary thinking? There is no reason that the next step after 1024 bits has to be 2048 bits. How about 1032 bits? Or 1040? Or 1104? How about 1200 bits? How about 1536? How about 1600? 1808? I have a theory that if everyone picked a pseudo-random key size above 1024 and below 2048, rather than standardizing on Yet Another Fixed Keysize, we'd avoid making a powerful incentive for bad guys to build a key-cracker optimized for one size. Which incentive we have currently created at 1024 bits. It's the Microsoft Windows of key sizes -- the target that gets you 90+% of the market. So pick a larger size than 1024 that your server load can live with, even if it isn't 2048. And don't tell anybody else what size you picked :-). John - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Cars hacked through wireless tire sensors Another paper plus USENIX SEC10 proceedings
What looks like to be an applicable paper. Not the same set of authors as
the earlier reference to USENIX.
Experimental Security Analysis of a Modern Automobile
Karl Koscher, Alexei Czeskis, Franziska Roesner, Shwetak Patel, and
Tadayoshi Kohno
Department of Computer Science and Engineering University of Washington
Seattle, Washington 98195–2350 Email:
{supersat,aczeskis,franzi,shwetak,yos...@cs.washington.edu
Stephen Checkoway, Damon McCoy, Brian Kantor, Danny Anderson, Hovav Shacham,
and Stefan Savage
Department of Computer Science and Engineering University of California San
Diego La Jolla, California 92093–0404 Email:
{s,dlmccoy,brian,d8anders,hovav,sava...@cs.ucsd.edu
Abstract— Modern automobiles are no longer mere mechanical devices; they
are pervasively monitored and controlled by dozens of digital computers
coordinated via internal vehicular networks. While this transformation has
driven major advance- ments in efficiency and safety, it has also introduced
a range of new potential risks. In this paper we experimentally evaluate
these issues on a modern automobile and demonstrate the fragility of the
underlying system structure. We demonstrate that an attacker who is able to
infiltrate virtually any Electronic Control Unit (ECU) can leverage this
ability to completely circumvent a broad array of safety-critical systems.
Over a range of experiments, both in the lab and in road tests, we
demonstrate the ability to adversarially control a wide range of automotive
functions and completely ignore driver input — including disabling the
brakes, selectively braking individual wheels on demand, stopping the
engine, and so on. We find that it is possible to bypass rudimentary network
security protections within the car, such as maliciously bridging between
our car’s two internal subnets. We also present composite attacks that
leverage individual weaknesses, including an attack that embeds malicious
code in a car’s telematics unit and that will completely erase any evidence
of its presence after a crash. Looking forward, we discuss the complex
challenges in addressing these vulnerabilities while considering the
existing automotive ecosystem.
Appears in 2010 IEEE Symposium on Security and Privacy. See
http://www.autosec.org/ for more information.
http://www.autosec.org/pubs/cars-oakland2010.pdf
There's also a FAQ on the paper: http://www.autosec.org/faq.html
Add electronic throttle and steer by wire (ala Lexus LS460) and I see an App
Store app getting popular for those James Bond back seat drivers.
The USENIX Security Symposium http://www.usenix.org/events/sec10/tech/
lists the paper referenced in Ars Technia under Real-World Security as
Security and PRivacy Vulnerabilities of In-Car Wireless Networks: A Tire
Pressure Monitoring System Case Study (P. 323)
Ishtiaq Rouf, University of South Carolina, Columbia; Rob Miller, Rutgers
University; Hossen Mustafa and Travis Taylor, University of South Carolina,
Columbia; Sangho Oh, Rutgers University; Wenyuan Xu, University of South
Carolina, Columbia; Marco Gruteser, Wade Trappe, and Ivan Seskar, Rutgers
University
The USENIX SEC10 Paper
Security and Privacy Vulnerabilities of In-Car Wireless Networks: A Tire
Pressure Monitoring System Case Study
Ishtiaq Rouf et. al. is available at:
http://www.usenix.org/events/sec10/tech/full_papers/Rouf.pdf
It is also found in the two page layout PDF of the USENIX SEC10 proceedings
http://www.usenix.org/events/sec10/tech/
at:
http://www.usenix.org/events/sec10/tech/full_papers/security10_proceedings.pdf
(20 MB)
http://www.usenix.org/events/sec10/tech/full_papers/sec10_errata.pdf
(Referred papers are available individually)
or the epub versions:
http://www.usenix.org/sec10/epub (16 MB)
http://www.usenix.org/events/sec10/tech/full_papers/USENIX_Security10_Errata.epub
Readable with the Firefox EPUBReader add-on the epub is not encrypted
meaning you can extract quotes or cites easily and access the papers as HTML
files found in the epub (zip) archive. The quality is excellent.
Also in a mobi version, the proceedings are just chocka full of other
interesting things, too.
-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
2048-bit RSA keys
At 9:34 AM -0700 8/15/10, Ray Dillinger wrote: I'm under the impression that 2048 keys are now insecure mostly due to advances in factoring algorithms that make the attack and the encryption effort closer to, but by no means identical to, scaling with the same function of key length. You are under the wrong impression, unless you are reading vastly different crypto literature than the rest of us are. RSA-1024 *might* be possible to break in public at some point in the next decade, and RSA-2048 is a few orders of magnitude harder than that. --Paul Hoffman, Director --VPN Consortium - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
