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
Spy/Counterspy
GPS tracking units that you can fit to your car to track where your kids are taking it (or *cough* other purposes) have been around for awhile now. It's interesting to see that recently the 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 (general-purposes ones using internal batteries have been around for awhile). 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). Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Against Rekeying
Nicolas Williams nicolas.willi...@sun.com writes: I made much the same point, but just so we're clear, SSHv2 re-keying has been interoperating widely since 2005. (I was at Connectathon, and while the details of Cthon testing are proprietary, I can generalize and tell you that interop in this area was very good.) Whose SSH rekeying though? I follow the support forums for a range of non- mainstream (i.e. not the usual suspects of OpenSSH, ssh.com, or Putty) SSH implementations and why does my connection die after an hour with [decryption error/invalid packet/unrecognised message type/whatever] (all signs of rekeying issues) is still pretty much an FAQ across them at the current time. (There's also the mass of ancient copies of the usual suspects, principally the ssh.com implementation dating back up to ten years, baked into networking devices and whatnot that will never be updated, or at least if significant security holes present in the older versions haven't convinced the vendors using them to update them then I don't think the fact that they drop the connection after an hour will). Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
