[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Idea to secure ssh



On Wed, Mar 15, 2006 at 02:35:53PM +0100, Goswin von Brederlow wrote:
Michael Stone <mstone@debian.org> writes:
No, anyone can generate encrypted parts. IMHO, there's not much chance
that the decryption routines in your magic udp parser are going to be
less vulnerable than those in openssh itself. Having "two layers of
Having "two layers of encryption" in this context is fairly pointless.

Those two layers are totaly standard. You have to use two keypairs in
parallel to ensure that only one person can read the text and only one
person can have send it.

Either that paragraph doesn't parse or it doesn't address what I said. This gets back to "what are you trying to defend against". If you're trying to defend against brute force attacks, then the ssh public key auth should be sufficient. If it's not (if your adversary can somehow crack or brute force arbitrary RSA keys) than adding a *second* key isn't going to help. If you're trying to defend against attacks on the crypto routines themselves (e.g., a buffer overflow against the RSA code in openssh) then I don't see why this other parser is going to be more secure. What problem is this frankenstein trying to solve?
Why not use three layers, or four? What analysis demonstrates a
demonstrable return for that second layer, weighed against the cost of
this kooky mechanism? If you really need multiple encryption layers,
do it right and use an existing standard like ipsec rather than
inventing a convoluted "secret method".

The analysis is simple:

Encrypting with the server public key ensures that only the server
private key can decrypt the data.

Encrypting with the client private key ensures that only the client
can have send the package. Decryptng with the clients public key
ensures that.

Dude, openssh *already does that*.

Mike Stone



Reply to: