RE: Trillian Secure IM
| Which is by the way exactly the case with SecureIM. How | hard is it to brute-force 128-bit DH ? My guesstimate | is it's an order of minutes or even seconds, depending | on CPU resources. Sun's Secure NFS product from the 1980s had 192-bit Diffie-Hellman, and a comment in one of the O'Reilly NFS books says that However, by 1990, advances in RISC processors produced workstation machines that could, by brute force, derive the private key from any public key in under a day. but that in 1987 there were still a lot of Motorola 68010 machines that took several minutes to generate keys so they didn't want it longer. I'm guessing that a 1990 RISC machine was around 50 MIPS, so it's maybe 1/100 the speed of a modern single-core CPU. 128-bit DH sounds like as good a decision as using 40-bit RC4 keys would be today. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: Trillian Secure IM
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Leichter, Jerry Sent: Monday, October 08, 2007 11:48 AM To: Alex Pankratov Cc: cryptography@metzdowd.com Subject: RE: Trillian Secure IM | But, opportunistic cryptography is even more fun. It is | very encouraging to see projects implement cryptography in | limited forms. A system that uses a primitive form of | encryption is many orders of magnitude more secure than a | system that implements none. | | Primitive form - maybe, weak form - absolutely not. It | is actually worse than having no security at all, because | it tends to create an _illusion_ of protection. This is an old argument. I used to make it myself. I even used to believe it. Unfortunately, it misses the essential truth: The choice is rarely between really strong cryptography and weak cryptography; it's between weak cryptography and no cryptography at all. What this argument assumes is that people really *want* cryptography; that if you give them nothing, they'll keep on asking for it; but if you give them something weak, they'll stop asking and things will end there. But in point of fact hardly anyone knows enough to actually want cryptography. Those who know enough will insist on the strong variety whether or not the weak is available; while the rest will just continue with whatever they have. Well, I view it from a slightly different perspective. Even the most ignorant person knows a difference between the privacy and the lack of thereof. Cryptography or not. Therefore, if he is being told that A offers a privacy, it may lead this person to assume the level of this privacy protection is adequate ... simply because if it weren't, it wouldn't be offered. Needless to say that this sort of an assumption in case of a weak crypto is dangerous. When there's a choice between no and weak protection, I am of course in favour of latter *if* it is clearly labeled as weak. | Which is by the way exactly the case with SecureIM. How | hard is it to brute-force 128-bit DH ? My guesstimate | is it's an order of minutes or even seconds, depending | on CPU resources. It's much better to analyze this in terms of the cost to the attacker and the defender. Yup, I am familiar with the methodology. My point was that 128bit DH is breakable in terms of the people from those forum's threads. Alex - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Trillian Secure IM
Why bother with all this? There is OTP for gaim, and it works just fine (not to mention it comes from a definitely clueful source). /ji - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Trillian Secure IM
[EMAIL PROTECTED] wrote: Why bother with all this? There is OTP for gaim, and it works just fine (not to mention it comes from a definitely clueful source). /ji I meant, of course, OTR (off-the-record). And to think that I was using it in another window as I was typing this! Thanks to Scott G. Kelly for pointing this out. /ji - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: Trillian Secure IM
-Original Message- From: Ian G [mailto:[EMAIL PROTECTED] Sent: Monday, October 08, 2007 6:05 AM To: Peter Gutmann Cc: [EMAIL PROTECTED]; cryptography@metzdowd.com Subject: Re: Trillian Secure IM Peter Gutmann wrote: Alex Pankratov [EMAIL PROTECTED] writes: SecureIM handshake between two version 3.1 (latest) clients takes about .. 48 bytes. That's altogether, 32 bytes in one direction, and 16 in another. And that's between the clients that have never talked to each other before, so there's no session resuming business happenning. Or they could be using static/ephemeral DH with fixed shared DH key values, which isn't much better. (This is just speculation, it's hard to tell without knowing what the exchanged quantities are). Speculation is fun. But, opportunistic cryptography is even more fun. It is very encouraging to see projects implement cryptography in limited forms. A system that uses a primitive form of encryption is many orders of magnitude more secure than a system that implements none. Primitive form - maybe, weak form - absolutely not. It is actually worse than having no security at all, because it tends to create an _illusion_ of protection. Which is by the way exactly the case with SecureIM. How hard is it to brute-force 128-bit DH ? My guesstimate is it's an order of minutes or even seconds, depending on CPU resources. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: Trillian Secure IM
| But, opportunistic cryptography is even more fun. It is | very encouraging to see projects implement cryptography in | limited forms. A system that uses a primitive form of | encryption is many orders of magnitude more secure than a | system that implements none. | | Primitive form - maybe, weak form - absolutely not. It | is actually worse than having no security at all, because | it tends to create an _illusion_ of protection. This is an old argument. I used to make it myself. I even used to believe it. Unfortunately, it misses the essential truth: The choice is rarely between really strong cryptography and weak cryptography; it's between weak cryptography and no cryptography at all. What this argument assumes is that people really *want* cryptography; that if you give them nothing, they'll keep on asking for it; but if you give them something weak, they'll stop asking and things will end there. But in point of fact hardly anyone knows enough to actually want cryptography. Those who know enough will insist on the strong variety whether or not the weak is available; while the rest will just continue with whatever they have. | Which is by the way exactly the case with SecureIM. How | hard is it to brute-force 128-bit DH ? My guesstimate | is it's an order of minutes or even seconds, depending | on CPU resources. It's much better to analyze this in terms of the cost to the attacker and the defender. If the defender assigns relatively low value to his messages, an attack that costs the attacker more than that low value is of no interest. Add in the fact that an attacker may have to break multiple message streams before he gets to one that's worth anything at all. Even something that takes a fraction of a second to decrypt raises the bar considerably for an attacker who just surfs all conversations, scanning for something of interest. It's easy to search for a huge number of keywords - or even much more complex patterns - in parallel at multi-megabyte/second speeds with fgrep-like (Aho-Corasick) algorithms. A little bit of decryption tossed in there changes the calculations completely. I'm not going to defend the design choices here because I have no idea what the protocol constraints were, what the attack model was (or even if anyone actually produced one), what the hardware base was assumed to be at the time this was designed, etc. Perhaps it's just dumb design; perhaps this was the best they could do. Could it be better? Of course. Is it better to not put a front door on your house because the only ones permitted for appearance's sake are wood and can be broken easily? -- Jerry - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
