Re: Question w.r.t. AES-CBC IV
Ralph Holz ralph-cryptometz...@ralphholz.de writes: CTR mode seems a better choice here. Without getting too technical, security of CTR mode holds as long as the IVs used are fresh whereas security of CBC mode requires IVs to be random. Unfortunately CTR mode, being a stream cipher, fails completely if the IV's/keys aren't fresh (as you could force them to be for SRTP under SIP by attacking the crypto handshake that preceded it, a nice example of attacking across a protocol boundary, taking advantage of a weakness in one protocol to break a second), while CBC only becomes a bit less secure. In addition CTR mode fails trivially to integrity attacks, while with CBC it's often more obvious (you get at least some total corruption before the self-healing takes effect). The problem with CTR is that, like RC4, it's very brittle, make a tiny mistake anywhere and you're toast. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Question w.r.t. AES-CBC IV
Ralph Holz ralph-cryptometz...@ralphholz.de writes: CTR mode seems a better choice here. Without getting too technical, security of CTR mode holds as long as the IVs used are fresh whereas security of CBC mode requires IVs to be random. Unfortunately CTR mode, being a stream cipher, fails completely if the IV's/keys aren't fresh (as you could force them to be for SRTP under SIP by attacking the crypto handshake that preceded it, a nice example of attacking across a protocol boundary, taking advantage of a weakness in one protocol to break a second), while CBC only becomes a bit less secure. In addition CTR mode fails trivially to integrity attacks, while with CBC it's often more obvious (you get at least some total corruption before the self-healing takes effect). The problem with CTR is that, like RC4, it's very brittle, make a tiny mistake anywhere and you're toast. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Spy/Counterspy
On Jul 9, 2010, at 1:00 PM, Pawel wrote: Hi, On Apr 27, 2010, at 5:38 AM, Peter Gutmann (alt) pgut001.reflec...@gmail.com wrote: GPS tracking units that you can fit to your car to track where your kids are taking it [T]he sorts of places that'll sell you card skimmers and RFID cloners have started selling miniature GPS jammers that plug into cigarette-lighter sockets on cars In other words these are specifically designed to stop cars from being tracked. (Some of the more sophisticated trackers will fall back to 3G GSM- based tracking via UMTS modems if they lose the GPS signal, it'll be interested to see how long it takes before the jammers are updated to deal with 3G signals as well, hopefully while leaving 2G intact for phonecalls). Just wondering, why wouldn't GPS trackers use 2G to determine the location? And, also, does it even need a cell service subscription for location determination, or is it enough to query the cell towers (through some handshake protocols) to figure out the proximities and coordinates? The 2G stuff wasn't designed to provide location information; that was hacked in (by triangulating information received at multiple towers) after the fact. I don't know that anyone has tried to do it from the receiver side - it seems difficult, and would probably require building specialized receiver modules (expensive). 3G provides location information as a standard service, so it's cheap and easy. The next attack, of course, is to use WiFi base station triangulation. That's widely and cheaply available already, and quite accurate in many areas. (It doesn't work out in the countryside if you're far enough from buildings, but then you don't have to go more than 60 miles or so from NYC to get to areas with no cell service, either.) The signals are much stronger, and you can get location data with much less information, so jamming would be more of a challenge. Still, I expect we'll see that in the spy vs. spy race. I wrote message to Risks - that seems to never have appeared - citing an article about GPS spoofing. (I've included it below.) In the spy vs. spy game, of course, it's much more suspicious if the GPS suddenly stops working than if it shows you've gone to the supermarket. Of course, WiFi (and presumably UMTS equipment, though that might be harder) can also be spoofed. I had an experience - described in another RISKS article - in which WiFi-based location suddenly teleported me from Manhattan to the Riviera - apparently because I was driving past a cruise ship in dock and its on-board WiFi had been sampled while it was in Europe. -- Jerry The BBC reports (http://news.bbc.co.uk/2/hi/science/nature/ 8533157.stm) on the growing threat of jamming to satellite navigation systems. The fundamental vulnerability of all the systems - GPS, the Russian Glonass, and the European Galileo - is the very low power of the transmissions. (Nice analogy: A satellite puts out less power than a car headlight, illuminating more than a third of the Earth's surface from 20,000 kilometers.) Jammers - which simply overwhelm the satellite signal - are increasingly available on-line. According to the article, low-powered hand-held versions cost less than £100, run for hours on a battery, and can confuse receivers tens of kilometers away. The newer threat is from spoofers, which can project a false location. This still costs thousands, but the price will inevitably come down. A test done in 2008 showed that it was easy to badly spoof ships off the English coast, causing them to read locations anywhere from Ireland to Scandinavia. Beyond simple hacking - someone is quoted saying You can consider GPS a little like computers before the first virus - if I had stood here before then and cried about the risks, you would've asked 'why would anyone bother?'. - among the possible vulnerabilities are to high- value cargo, armored cars, and rental cars tracked by GPS. As we build more and more location-aware services, we are inherently building more false-location-vulnerable services at the same time. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: What is required for trust?
On Jun 3, 2010, at 10:39 AM, Sandy Harris wrote: India recently forbade some Chinese companies from bidding on some cell phone infrastructure projects, citing national security concerns... The main devices to worry about are big infrastructure pieces -- telephone switches, big routers and the like. However, those are by no means the only potential targets. Small home routers and various embedded systems are others. So, if one is building some sort of hardware that people may be reluctant to buy because of security concerns, what does it take to reassure them?... Given the state of the art, there appears to be no way to get any assurance you can reasonably believe in. See http://cseweb.ucsd.edu/users/swanson/WACI-VI/docs/08_slides.pdf , full paper at http://www.usenix.org/events/leet08/tech/full_papers/king/king.pdf - for some work in this area: The authors took an open-source design for a SPARC chip and made some very small modifications to it. The resulting processor could not reasonably be distinguished from an unmodified one by any feasible testing, but renders any software protection you might use on the device completely ineffective against someone who knows how to trigger the hardware hacks (which can be done remotely). The only way you would know this stuff is there is by vetting the design - and detecting ~100 new lines of VHDL among 11,000, or 1000 new gates out of 1.8 million. And, of course this is a proof of concept, involving a very simple processor and no attempts to absolutely minimize the visibility of the changes. People usually fall back on well, get chips from multiple sources, they can't compromise them all. But that doesn't work here: If you don't know which chips are good and which are traitors, you don't know there isn't a traitor in the very equipment you have to rely on. Further, obvious ideas like running extensive comparisons of outputs of chips from multiple sources don't work against attacks that only open the chip on a specific command. I suppose you could make sure every device that operates on sensitive data has redundant chips from multiple vendors and compare outputs - but then at the least you're vulnerable to a denial of service attack, which in some circumstances is almost as bad. And even if you do find that two chips disagree - which is the bad one? And if figure that out - you now know one bad source, but you have no evidence that the source of the other chip hasn't also spiked it in some different way. (The classic trick here is to have two attacks, and let one be found - after which the target *thinks* he's safe.) The whole question of how to get trustworthy parts appears to be a huge issue in the US military/intelligence community these days. They're putting together consultations with academia and industry - and undoubtedly also funding all kinds of secret work as well. In the old days, it was practical for sensitive operations to build their own chips at vetted plants. Those days are gone - there are only a limited number of plants on the entire planet that can build state-of- the-art chips, the technology itself has been mastered by only a limited number of players, and the costs are immense even by military/ black funding standards. -- Jerry - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: A real case of malicious steganography in the wild?
On Jun 29, 2010, at 3:33 AM, Steven Bellovin wrote: For years, there have been unverifiable statements in the press about assorted hostile parties using steganography. There may now be a real incident -- or at least, the FBI has stated in court documents that it happened. According to the Justice Department (http://www.justice.gov/opa/pr/2010/June/10-nsd-753.html ), 11 Russian nationals have been operating as deep cover agents in the US for many years. According to Complaint #2 (link at the bottom of the page), a steganographic program was used. Other Internet-era techniques allegedly employed include ad hoc WiFi networks. (To be sure, the FBI could be wrong. In the past, I've seen them make mistakes about that, but they're *much* more experienced now.) It will be interesting to see how this develops in court. Unfortunately (from a particular point of view), we'll probably never find it: It looks as if these agents will be swapped for various Americans held by the Russians. -- Jerry - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Question w.r.t. AES-CBC IV
Ralph Holz writes: He wanted to scrape off some additional bits when using AES-CBC because the messages in his concept are very short (a few hundred bit). So he I'd rather have a known-safe design than to save 12 bytes. Seriously: what the hell. Say you have 1-byte messages, and that the cryptography will expand them to 128 bytes (...you use a MAC, right?). If this overhead factor is really bad for you, for example because you expect to send thousands of messages per second, your problem is a bad protocol design. Don't break the safety mechanism to support an inefficient protocol. Alternately, if you send messages only rarely, the overhead doesn't matter. My point is, since you have tiny messages, throughput must not be your goal. And yet, even with 128-byte messages, your messages are so small that latency and bloat are not problems. You get confidential and MAC'd communications for less than the cost of a tweet or SMS. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Question w.r.t. AES-CBC IV
Jerry Leichter wrote: CTR mode is dangerous unless you're also doing message authentication, Nitpick: That's true of CBC mode, too, and almost any other encryption mode. Encryption without authentication is dangerous; if you need to encrypt, you almost always need message authentication as well. (I will agree that CTR mode encryption without message authentication is often even more dangerous than CBC mode encryption without message authentication, but usually neither is a good idea.) Setting that minor nitpick aside, the discussion here seems like good advice. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: 1280-Bit RSA
On Fri, 9 Jul 2010 21:16:30 -0400 (EDT) Jonathan Thornburg jth...@astro.indiana.edu wrote: The following usenet posting from 1993 provides an interesting bit (no pun itended) of history on RSA key sizes. The key passage is the last paragraph, asserting that 1024-bit keys should be ok (safe from key-factoring attacks) for a few decades. We're currently just under 1.75 decades on from that message. I think the take-home lesson is that forecasting progress in factoring is hard, so it's useful to add a safety margin... This is quite interesting. The post doesn't say but I suspect at the factoring effort was based on using Quadratic Sieve rather than GNFS. The difference in speed for QS versus GNFS starts to really diverge with larger composites. Here's another table: RSA GNFS QS === 256 43.68 43.73 384 52.58 55.62 512 59.84 65.86 664 67.17 76.64 768 71.62 83.40 1024 81.22 98.48 1280 89.46111.96 1536 96.76124.28 2048 109.41 146.44 3072 129.86 184.29 4096 146.49 216.76 8192 195.14 319.63 16384258.83 469.80 32768342.05 688.62 Clearly starting at key sizes of 1024 and greater GNFS starts to really improve over QS. If the 1993 estimate for RSA 1024 was assuming QS then that was roughly equivalent to RSA 1536 today. Even improving the GNFS constant from 1.8 to 1.6 cuts off the equivalent of about 256 bits from the modulus. The only certainty in factoring techniques is that they won't get worse than what we have today. Brandon - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
