The US Federal government has a long history of imposing on itself mandates for new computer technology, mandates that are ignored and never enforced. They all set a date after which every agency may buy only computer equipment or software that contains some new not-yet-mainstream technology. The dates come and go, and agencies continue to buy what works for them.
Examples: 1979: mandated no more RS-232, only RS-449, for modems and computers that
connect to modems. Today: have you ever HEARD of RS-449?
1989: mandated every new computer that communicates with other computers must
use OSI protocols. Today: TCP/IP rules.
2000: mandated end of use of RSA (the PKCS#1 form used in SSL) by August 2001,
and the adoption of a new form of RSA (ANSI X9.31). Today, PKCS#1 rules.
The standards bodies haven't even considered switching.
> Redmond, Wash.-based Microsoft has landed a $470-plus million contract to > issue software to the U.S. Army. Bloomberg reported it was the "biggest > order ever for the company's programs. The deal covers 494,000 desktop > computers, Microsoft spokesman Keith Hodson said.
Lessee: 470+ M$ / 494K desktops is over $951 / desktop
And you thought $100 toilet seats were overpriced!
AIM uses the mozilla open source crypto libraries. You can see the same crypto DLLs in AIM as in mozilla 1.3 or 1.4. You should be able to build your own mozilla crypto DLLs from the open sources and substitute them for the AIM ones. Then you know your AIM crypto is open source.
The encrypted messages are PKCS7/CMS messages, the same format used by mozilla's S/MIME secure email (look for smime3.dll). The messages identify each public key that was used to encrypt the message.
Good old SSL 3.0 is significantly less vulnerable to this attack than TLS, the IETF proposed standard version of SSL, a.k.a. SSL 3.1.
Although the recent Lasec paper http://lasecwww.epfl.ch/memo_ssl.shtml describes the attack as working on SSL and TLS, the full attack (which reveals an entire password) depends on a property of block cipher padding that is true of TLS but not true for SSL 3.0.
TLS requires that each byte of padding in the last block have the same value, and that the server must check that the values are correct. The attack depends on the attacker's ability to determine if the value of each byte in a block is or is not the proper padding value for the length of padding being attempted by the attacker. This is only possible if the server actually checks the padding byte values. Fot this attack to succeed, it is necessary and sufficient for the server to check the first and last bytes of padding in the block.
But unlike TLS, SSL 3.0 requires only that the last byte of padding have the defined value. All bytes of padding preceeding the last byte have undefined values, and can contain any values at all. Thus it is not possible for an SSL 3.0 server to test the value of any byte of padding other than the last one. SSL 3.0 servers only test the last byte, if they test any at all. Servers that do not test these bytes are not vulnerable.
Consequently, when this attack is applied to IMAPS over SSL 3.0, no byte but the last byte in any cipher block can be revealed. The value of the last byte can only be narrowed down to 1 of N possible values (where N is the number of bytes in the block, 8 for DES, 16 for AES), not to the exact value. That's bad enough that a cryptographer wouldn't ignore it, but it's probably good enough that an SSL 3.0 IMAPS user needn't be too worried about it.
Slashdot Mirror
The US Federal government has a long history of imposing on itself mandates
for new computer technology, mandates that are ignored and never enforced.
They all set a date after which every agency may buy only computer equipment
or software that contains some new not-yet-mainstream technology.
The dates come and go, and agencies continue to buy what works for them.
Examples:
1979: mandated no more RS-232, only RS-449, for modems and computers that
connect to modems. Today: have you ever HEARD of RS-449?
1989: mandated every new computer that communicates with other computers must
use OSI protocols. Today: TCP/IP rules.
2000: mandated end of use of RSA (the PKCS#1 form used in SSL) by August 2001,
and the adoption of a new form of RSA (ANSI X9.31). Today, PKCS#1 rules.
The standards bodies haven't even considered switching.
2005: mandate IPv6 by June 2008. We'll see.
> the contract amounts to a six-year agreement covering 144,000 desktops,
> worth between $110 million and $120 million [gcn.com].
$110+ M$ / 144K Desktops is over $763/desktop
And this was the LOW bid?
> Redmond, Wash.-based Microsoft has landed a $470-plus million contract to
> issue software to the U.S. Army. Bloomberg reported it was the "biggest
> order ever for the company's programs. The deal covers 494,000 desktop
> computers, Microsoft spokesman Keith Hodson said.
Lessee: 470+ M$ / 494K desktops is over $951 / desktop
And you thought $100 toilet seats were overpriced!
AIM uses the mozilla open source crypto libraries. You can see the same
crypto DLLs in AIM as in mozilla 1.3 or 1.4. You should be able to build
your own mozilla crypto DLLs from the open sources and substitute them for
the AIM ones. Then you know your AIM crypto is open source.
The encrypted messages are PKCS7/CMS messages, the same format used by
mozilla's S/MIME secure email (look for smime3.dll). The messages identify
each public key that was used to encrypt the message.
Good old SSL 3.0 is significantly less vulnerable to this attack than TLS, the IETF proposed standard version of SSL, a.k.a. SSL 3.1.
Although the recent Lasec paper http://lasecwww.epfl.ch/memo_ssl.shtml describes the attack as working on SSL and TLS, the full attack (which reveals an entire password) depends on a property of block cipher padding that is true of TLS but not true for SSL 3.0.
TLS requires that each byte of padding in the last block have the same value, and that the server must check that the values are correct. The attack depends on the attacker's ability to determine if the value of each byte in a block is or is not the proper padding value for the length of padding being attempted by the attacker. This is only possible if the server actually checks the padding byte values. Fot this attack to succeed, it is necessary and sufficient for the server to check the first and last bytes of padding in the block.
But unlike TLS, SSL 3.0 requires only that the last byte of padding have the defined value. All bytes of padding preceeding the last byte have undefined values, and can contain any values at all. Thus it is not possible for an SSL 3.0 server to test the value of any byte of padding other than the last one. SSL 3.0 servers only test the last byte, if they test any at all. Servers that do not test these bytes are not vulnerable.
Consequently, when this attack is applied to IMAPS over SSL 3.0, no byte but the last byte in any cipher block can be revealed. The value of the last byte can only be narrowed down to 1 of N possible values (where N is the number of bytes in the block, 8 for DES, 16 for AES), not to the exact value. That's bad enough that a cryptographer wouldn't ignore it, but it's probably good enough that an SSL 3.0 IMAPS user needn't be too worried about it.