Re: [OT] ssh security
Hi, The pre-shared information need not to be secret ... but there is need for pre-shared trusted information. Er, if the pre-shared information is not secret, how can I be sure that the person presenting it is in fact my intended correspondent and not a MIM? That is why I wrote trusted, I don't assume how this is trusted, but I need to trust it. If I am 100% sure the fingerprint comes from the right guy, I can easily test that the fingerprint corresponds to the intended public key, so that the publick key effectively belongs to the right guy, and crypting with that public key, only the right guy with his provate key will be able to read my message. Now Diffie-Hellman may help providing the trust for the fingerprint. Bests, Olivier ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: [OT] ssh security
On Mar 10, 2010, at 11:59, Olivier Nicole olivier.nic...@cs.ait.ac.th wrote: Now Diffie-Hellman may help providing the trust for the fingerprint. No it won't. Trust goes either via a trusted third party as in PKI or the pgp chain of trust or via direct verification. In the latter case if you cannot establish trust, call up the owner to verify his key. BR erik ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: [OT] ssh security
Angelin Lalev lalev.ange...@gmail.com wrote: So, SSH uses algorithms like ssh-dss or ssh-rsa to do key exchange. These algorithms can defeat any attempts on eavesdropping, but cannot defeat man-in-the-middle attacks. To defeat them, some pre-shared information is needed - key fingerprint. What happened to Diffie-Hellman? Last I heard, its whole point was to enable secure communication, protected from both eavesdropping and MIM attacks, between systems having no prior trust relationship (e.g. any sort of pre-shared secret). What stops the server and client from establishing a Diffie-Hellman session and using it to perform the key exchange? ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: [OT] ssh security
What happened to Diffie-Hellman? Last I heard, its whole point was to enable secure communication, protected from both eavesdropping and MIM attacks, between systems having no prior trust relationship (e.g. any sort of pre-shared secret). What stops the server and client from establishing a Diffie-Hellman session and using it to perform the key exchange? I am not expert in cryptography, but logic tends to tell me that is I have no prior knowledge about the person I am about to talk to, anybody (MIM) could pretend to be that person. The pre-shared information need not to be secret (key fingerprints are not secret), but there is need for pre-shared trusted information. Bests, Olivier ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: [OT] ssh security
On Tue, Mar 9, 2010 at 12:48 AM, Olivier Nicole olivier.nic...@cs.ait.ac.th wrote: What happened to Diffie-Hellman? Last I heard, its whole point was to enable secure communication, protected from both eavesdropping and MIM attacks, between systems having no prior trust relationship (e.g. any sort of pre-shared secret). What stops the server and client from establishing a Diffie-Hellman session and using it to perform the key exchange? I am not expert in cryptography, but logic tends to tell me that is I have no prior knowledge about the person I am about to talk to, anybody (MIM) could pretend to be that person. The pre-shared information need not to be secret (key fingerprints are not secret), but there is need for pre-shared trusted information. But to some extent, we setup and configure these machines ourselves. So when we're adding users could we not have an additional field with something like a phrase/answer or something else like that? Obviously it could be completely optional but it would be kind of neat and probably not too difficult to implement. Mark ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: [OT] ssh security
Olivier Nicole olivier.nic...@cs.ait.ac.th wrote: What happened to Diffie-Hellman? Last I heard, its whole point was to enable secure communication, protected from both eavesdropping and MIM attacks, between systems having no prior trust relationship (e.g. any sort of pre-shared secret) ... I am not expert in cryptography ... Nor am I but logic tends to tell me that is I have no prior knowledge about the person I am about to talk to, anybody (MIM) could pretend to be that person. The pre-shared information need not to be secret ... but there is need for pre-shared trusted information. Er, if the pre-shared information is not secret, how can I be sure that the person presenting it is in fact my intended correspondent and not a MIM? My impression is that Diffie-Hellman (somehow) solves this sort of problem. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: [OT] ssh security
On 10/03/10 07:16, per...@pluto.rain.com wrote: but logic tends to tell me that is I have no prior knowledge about the person I am about to talk to, anybody (MIM) could pretend to be that person. True. Cryptography by it self does not solve the identity problem. The pre-shared information need not to be secret ... but there is need for pre-shared trusted information. Er, if the pre-shared information is not secret, how can I be sure that the person presenting it is in fact my intended correspondent and not a MIM? My impression is that Diffie-Hellman (somehow) solves this sort of problem. The preshared information, in this case the key fingerprint, is a fingerprint of the public key, without this, you cannot produce the fingerprint. Yes, the fingerprint is calculated from the public key, which is .. er .. public, but that's not a problem since anything encrypted with the public key can only be decrypted by the owner of the private key. In the session setup public keys are exchanged, on the basis of this key you calculate the fingerprint and compare with the one you have stored. If they do not match, connection is closed. So, the MIM attack must be launched the very first time a user connects. This is where the user trusts the identity of the owner of the private key. The known_hosts file is only kept so you don't have to verify and trust the key every time. If you worry about that kind of attack, then you should provide a method for verifying the fingerprint through a different channel, say users call support and have them read out the fingerprint, publish it on some separate server, or pre-install it on their computer when the account is created. Diffie-Hellman does not solve this problem. DH is a protocol for agreeing on a shared secret in public, but it does not solve the identity problem. BR, Erik -- Erik Nørgaard Ph: +34.666334818/+34.915211157 http://www.locolomo.org ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: [OT] ssh security
Angelin Lalev lalev.ange...@gmail.com writes: ;2~ On Sun, Mar 7, 2010 at 11:25 PM, Angelin Lalev lalev.ange...@gmail.com wrote: Greetings, I'm doing some research into ssh and its underlying cryptographic methods and I have questions. I don't know whom else to ask and humbly ask for forgiveness if I'm way OT. So, SSH uses algorithms like ssh-dss or ssh-rsa to do key exchange. These algorithms can defeat any attempts on eavesdropping, but cannot defeat man-in-the-middle attacks. To defeat them, some pre-shared information is needed - key fingerprint. If hypothetically someone uses instead of the plain text authentication some challenge-response scheme, based on user's password or even a hash of user's password would ssh be able to avoid the need the user to have key fingerprints of the server prior the first connection? To clarify, we as users anyway do have shared secret with the server and that's the authentication password why we could not use that instead of or in addition to a key fingerprint? Because we don't want to give an attacker access to a shared secret if we can verify host identity with a public key first. -- Lowell Gilbert, embedded/networking software engineer, Boston area http://be-well.ilk.org/~lowell/ ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: [OT] ssh security
On Sun, Mar 7, 2010 at 3:25 PM, Angelin Lalev lalev.ange...@gmail.com wrote: Greetings, I'm doing some research into ssh and its underlying cryptographic methods and I have questions. I don't know whom else to ask and humbly ask for forgiveness if I'm way OT. So, SSH uses algorithms like ssh-dss or ssh-rsa to do key exchange. These algorithms can defeat any attempts on eavesdropping, but cannot defeat man-in-the-middle attacks. To defeat them, some pre-shared information is needed - key fingerprint. If hypothetically someone uses instead of the plain text authentication some challenge-response scheme, based on user's password or even a hash of user's password would ssh be able to avoid the need the user to have key fingerprints of the server prior the first connection? Hypothetically, SSH could use a zero-knowledge authentication method such as SRP[1]. Until new code is written for ssh to take advantage of something like this, we're stuck with what's available. -- Noel Jones [1] http://srp.stanford.edu/ ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
[OT] ssh security
Greetings, I'm doing some research into ssh and its underlying cryptographic methods and I have questions. I don't know whom else to ask and humbly ask for forgiveness if I'm way OT. So, SSH uses algorithms like ssh-dss or ssh-rsa to do key exchange. These algorithms can defeat any attempts on eavesdropping, but cannot defeat man-in-the-middle attacks. To defeat them, some pre-shared information is needed - key fingerprint. If hypothetically someone uses instead of the plain text authentication some challenge-response scheme, based on user's password or even a hash of user's password would ssh be able to avoid the need the user to have key fingerprints of the server prior the first connection? ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: [OT] ssh security
On Sun, Mar 7, 2010 at 11:25 PM, Angelin Lalev lalev.ange...@gmail.com wrote: Greetings, I'm doing some research into ssh and its underlying cryptographic methods and I have questions. I don't know whom else to ask and humbly ask for forgiveness if I'm way OT. So, SSH uses algorithms like ssh-dss or ssh-rsa to do key exchange. These algorithms can defeat any attempts on eavesdropping, but cannot defeat man-in-the-middle attacks. To defeat them, some pre-shared information is needed - key fingerprint. If hypothetically someone uses instead of the plain text authentication some challenge-response scheme, based on user's password or even a hash of user's password would ssh be able to avoid the need the user to have key fingerprints of the server prior the first connection? To clarify, we as users anyway do have shared secret with the server and that's the authentication password why we could not use that instead of or in addition to a key fingerprint? ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
