Maybe someone will find a polynomial algorithm for an NP-complete problem. A lot of effort has already gone into the search for such solutions, however, with nothing to show. What we really need is some technique (as yet undiscovered) for proving that no algorithm exists in a specific complexity class which solves a particular problem, much like the techniques for proving undecidability had not been discovered when Hilbert proposed his problems for the 20th century.
It's fascinating how RSA Data Laboratories was able to force the whole world to use RSA as their public key cryptography standard instead of the technically superior Diffie-Hellman/El Gamal algorithm. They did this by simply refusing to license Diffie-Hellman to anybody (yes, they owned a patent on that, back before it expired in 1997). Today the Diffie-Hellman algorithm has been out of patent protection for 3 years, but almost nobody uses it, because of the need to remain compatible with the large installed base of software that was forced to use RSA.
Very interesting. Can anyone confirm this? I can only seem to find that Public Key Partners, not RSADSI held the patent on Diffe-Hellman. Is there any connection between these two companies?
Re:Value added for SRP?
on
SSH v. SRP
·
· Score: 2
SSH keeps a "known hosts" file on the client, to thwart middlemen attacks. SSH warns the user if the server fails to authenticate itself properly.
This can be thwarted with a man-in-the-middle attack when the known hosts file is created.
SSH encrypts each session with a randomly generated key, which it communicates through a secure connection. Therefore, if a single session key is somehow compromised, all other sessions are still secure.
Here's one where there is some value-add to SRP. In this case, both create session keys which, if cracked, cannot be used to crack other sessions. However, if the private keys to an SSH connection are leaked, then _all_ sessions can be immediately cracked. With SRP, even if the secret (a password) is known to an attacker, he can't crack sessions. He would be able to successfully authenticate himself, however. One thing I've never been sure of is what's actually stored in an SSH private key file. Is it the key itself, or an encrypted form of the key, which is decrypted with your passphrase? If so, then SSH keys do have some protection in the event of a system compromise. SRP does not store passwords on the system in cleartext, just verifiers. If the verifier file is compromised, then an (expensive) dictionary attack on it is possible. This is the only known way to employ a dictionary attack against SRP.
One difference between SRP and SSH (which I would call an advantage, some may call a disadvantage) is that SRP requires only an SRP enabled server and client to operate. If you know your password, you will authenticate successfully. With SSH, this will work if you have password authentication enabled, so that the two hosts authenticate each other, negotiate a symmetric key, and encrypt the password. As mentioned above, if those servers' keys are ever compromised, your password will be revealed to the attacker. To make SSH more secure you need to create your own keys on every machine you use, and copy the public key to the machines you wish to access. If the hosts you wish to access don't allow password authentication, then you can only access them from the particular computers you've explicitly allowed access from. This can be very inconvenient, especially when you work with many computers. In this case, I have to say I prefer SRP. One password works from anywhere with perfect forward secrecy.
Re:SSH has been banged on for years
on
SSH v. SRP
·
· Score: 5
True, the SSH implementation has been around for a long time, and there aren't any SRP implementations that I consider high quality (more later), but this doesn't mean that one can't be written. The simple fact is that the protocol is quite simple and appears to be equivalent (if I remember, it was proven to be equivalent) to the Diffie-Hellman problem, so the mathematics are solid--have been banged on for years, one might say. However, we just need a good, pervasive implementation, which would be a good project for the community. SRP isn't encumbered by patents and provides a lot of flexibility for encryption options.
For those who don't know, SRP just verifies the identity of a user to a server and, optionally, the server to the user. However, the process of this verification also _securely_ produces a shared symmetric key at both ends of the connection which can then be used to encrypt the rest of the session using a cipher of choice. Encryption is optional, if only secure authentication is required.
It's time we stop letting the fact that there aren't well ironed implementations of the protocol prevent us from using it. The main problem with the existing implemenatations from Stanford is that they require too many changes to the system (su, login, passwd, and some others) all have to be replaced with SRP aware versions, and yet another password file has to be created (/etc/tpasswd). PAM can probably relieve some of these problems (there used to be an SRP PAM module--is it still around?), but most of the difficulty with SRP lies in integrating it with your system. If we worked on simplifying this a bit, it could potentially be a very good solution.
Slashdot Mirror
Maybe someone will find a polynomial algorithm for an NP-complete problem. A lot of effort has already gone into the search for such solutions, however, with nothing to show. What we really need is some technique (as yet undiscovered) for proving that no algorithm exists in a specific complexity class which solves a particular problem, much like the techniques for proving undecidability had not been discovered when Hilbert proposed his problems for the 20th century.
Can you say single machine which contains no single points of failure, as it was meticulously designed to never fail?
Very interesting. Can anyone confirm this? I can only seem to find that Public Key Partners, not RSADSI held the patent on Diffe-Hellman. Is there any connection between these two companies?
This can be thwarted with a man-in-the-middle attack when the known hosts file is created.
Here's one where there is some value-add to SRP. In this case, both create session keys which, if cracked, cannot be used to crack other sessions. However, if the private keys to an SSH connection are leaked, then _all_ sessions can be immediately cracked. With SRP, even if the secret (a password) is known to an attacker, he can't crack sessions. He would be able to successfully authenticate himself, however. One thing I've never been sure of is what's actually stored in an SSH private key file. Is it the key itself, or an encrypted form of the key, which is decrypted with your passphrase? If so, then SSH keys do have some protection in the event of a system compromise. SRP does not store passwords on the system in cleartext, just verifiers. If the verifier file is compromised, then an (expensive) dictionary attack on it is possible. This is the only known way to employ a dictionary attack against SRP.
One difference between SRP and SSH (which I would call an advantage, some may call a disadvantage) is that SRP requires only an SRP enabled server and client to operate. If you know your password, you will authenticate successfully. With SSH, this will work if you have password authentication enabled, so that the two hosts authenticate each other, negotiate a symmetric key, and encrypt the password. As mentioned above, if those servers' keys are ever compromised, your password will be revealed to the attacker. To make SSH more secure you need to create your own keys on every machine you use, and copy the public key to the machines you wish to access. If the hosts you wish to access don't allow password authentication, then you can only access them from the particular computers you've explicitly allowed access from. This can be very inconvenient, especially when you work with many computers. In this case, I have to say I prefer SRP. One password works from anywhere with perfect forward secrecy.
For those who don't know, SRP just verifies the identity of a user to a server and, optionally, the server to the user. However, the process of this verification also _securely_ produces a shared symmetric key at both ends of the connection which can then be used to encrypt the rest of the session using a cipher of choice. Encryption is optional, if only secure authentication is required.
It's time we stop letting the fact that there aren't well ironed implementations of the protocol prevent us from using it. The main problem with the existing implemenatations from Stanford is that they require too many changes to the system (su, login, passwd, and some others) all have to be replaced with SRP aware versions, and yet another password file has to be created (/etc/tpasswd). PAM can probably relieve some of these problems (there used to be an SRP PAM module--is it still around?), but most of the difficulty with SRP lies in integrating it with your system. If we worked on simplifying this a bit, it could potentially be a very good solution.