RE: Malign SSL server attacks
I am not familiar enough with the protocol to answer this question: is it possible for an evil SSL server to send packets such that it ends up with an arbitrary signature from a client? I'm trying to emphasize the importange of keyUsage bits. :) This is not possible without unreasonable computational power or breaking algorithms; the client makes a contribution to the message which is signed. - Tim
RE: NSA key in MSFT Crypto API
It's not clear to me why being able to sign CSP modules is a risky thing anyway; all it means is that Windows will load and execute your crypto. The mechanism is designed to keep overseas end users from being able to build and install strong crypto libraries. If the NSA has a key, all they can do is vouch for their libraries as export-qualified and thus enable their use. It's not a secret backdoor or anything, and modules need to be on the machine before their signatures are checked. If I can get you to execute code on our Windows machine, I can penetrate your security, period. These authorizing signatures have nothing to do with it. Even if the key belongs to the NSA, I suspect that the NSA just wanted to be able to load classified Crypto Service Providers into Windows and didn't want to have to send said classified software to Microsoft for approval, so they got the key installed so they could approve software in house. - Tim Tim Dierks VP of Engineering, Certicom [EMAIL PROTECTED] 510.780.5409 [Hayward] -- 905.501.3791 [Mississauga]
RE: going around the crypto
I haven't looked at the l0pht page yet, but you should be aware that the browser checks the certificate so the user doesn't have to, under most circumstances. The browser will display an alert if the hostname in the URL doesn't matche the commonName in the certificate or if the certificate is not issued by a trusted CA. Thus, unless the man-in-the-middle can produce such a certificate, which will require fooling a CA into giving him one, the client will not quietly negotiate with him, believing they're talking to the end server. If he can get such a certificate, that's an attack against the PKI, not the protocol. Two significant dangers with SSL as deployed today: 1) The certificate is checked against the URL, so the security mechanism is built upon the URL reflecting the user's intent. If the user doesn't display the URL, doesn't check it, or is fooled by a plausible yet incorrect URL, they will not be protected by the protocol or the PKI. (Note that this would require the user to be directed to the bad URL, although that could probably be done by modifying insecure web pages with links to secure ones.) 2) Most browsers extant do not check CRLs and most certificates don't have CRL distribution point extensions, so certificates cannot, in practice, be revoked. Tim Dierks VP of Engineering, Certicom [EMAIL PROTECTED] 510.780.5409 [Hayward] -- 905.501.3791 [Mississauga] -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Steven M. Bellovin Sent: Friday, August 13, 1999 7:17 AM To: [EMAIL PROTECTED] Subject: going around the crypto The L0pht has issued a new advisory for an routing-type attack that can, they say, allow for man-in-the-middle attacks against SSL-protected sessions (http://www.l0pht.com/advisories/rdp.txt). The implication -- that there's a flaw in SSL -- is probably wrong. But they're dead-on right that there's a real risk of man-in-the-middle attacks, because the attacker can go around the crypto. By sending the proper ICMP packets to a vulnerable host (most Windows 95/98 boxes, and some Solaris/SunOS systems), outbound traffic can be routed to an attacker's machine. This machine can pretend to be the destination of the SSL-protected call; it in turn calls the real destination. The obvious protection is for users to check the certificate. Most users, of course, don't even know what a certificate is, let alone what the grounds are for accepting one. It would also help if servers used client-side certificates for authentication, since the man-in-the-middle can't spoof the user's certificate. But almost no servers do that. This is why I wrote, a year ago, that we effectively have no PKI for the Web. It also underscores the importance of looking at the entire system design, rather than just the crypto. Crypto alone can't save the world; it's necessary, but far from sufficient.
RE: palm crypto
We've taken down the page until I can make sure that we're enforcing the appropriate export controls. Hopefully, it will return real soon now. Tim Dierks VP of Engineering, Certicom [EMAIL PROTECTED] 510.780.5409 [Hayward] -- 905.501.3791 [Mississauga] -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Jay D. Dyson Sent: Tuesday, August 03, 1999 10:25 AM To: Cryptography List Subject: Re: palm crypto -BEGIN PGP SIGNED MESSAGE- On Mon, 2 Aug 1999, Declan McCullagh wrote: http://www.certicom.com/software/SecureMemo11.ZIP http://www.certicom.com/software/SecureMemo11.SIT.BIN http://www.certicom.com/software/palmmemo.htm I've been trying to access these files, but I'm consistently hit up for a login/pass. The standard cypherpunks routine doesn't work, and I'd like to check this data out. Help? - -Jay ( __ )) .--- "There's always time for a good cup of coffee" ---. ===--. C|~~| (--- Jay D. Dyson - [EMAIL PROTECTED] ---) | = |-' `--' `- Superman had Kryptonite, I have NT. Life is real. -' `-' -BEGIN PGP SIGNATURE- Version: 2.6.2 iQCVAwUBN6cl2s2OVDpaKXD9AQGdGgP/bF6pk5P40gykgeOU1/i/jKXT4f1WzSfY shV5RIuTJfokYoZgcGTOcfsLzzmDMnnzBMYqNBJ2lf8fflmPPz2BpbNe9iHhHnRT WKmuds/mfRgzacnh3KRGsCo5qgx9ylfrO980dSmzY4Ihzv7vyOyaF7j+8jJKPpAD /2h/N1l9MYM= =SnBr -END PGP SIGNATURE-
RE: palm crypto
The intended feature was to demonstrate the performance of elliptic curve private key operations on an embedded platform. Functionality was a secondary concern. The implementation doesn't have a PKI, so it doesn't allow you to transfer messages, get certificates, etc., so the use you describe isn't actually functional. The only (agreed minimal) benefit of public key is that you can encrypt a message without entering your password; you only need it to decrypt. Of course, adding message transfer PKI would be an interesting project (although my recommended mechanism would be to support ECC in OpenPGP formats for the messages, or ECC S/MIME). If someone would be interested in working on Secure MemoPad, you can contact me. - Tim Tim Dierks VP of Engineering, Certicom [EMAIL PROTECTED] 510.780.5409 [Hayward] -- 905.501.3791 [Mississauga] -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Ian Goldberg Sent: Tuesday, August 03, 1999 1:36 PM To: [EMAIL PROTECTED] Subject: Re: palm crypto In article 001201bedc8b$3d5fb580$[EMAIL PROTECTED], Enzo Michelangeli [EMAIL PROTECTED] wrote: What's the point of using publick key technologies like ECC to protect private documents? As key management is a non-issue, something based on, say, 3DES or IDEA (like "Secret!", http://linkesoft.com/english/secret/) would suffice... I had the same thought. I finally decided that the ability to write a memo, encrypt it to some *other* pubkey, and beam it to the recipient is sufficiently useful to warrant the existence of this program. Keeping your *own* files secret is a special case. - Ian
