Michael Stone <[EMAIL PROTECTED]> writes: > On Wed, Mar 15, 2006 at 02:35:53PM +0100, Goswin von Brederlow wrote: >>Michael Stone <[EMAIL PROTECTED]> 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?
He trying to solve that a tcp connect to port 22 establishes a connection and thereby reveals that the server is running an sshd and attcking it makes sense. His idea is to add a 100% non responsive knocking (using udp) before the actual ssh handshake so unauthorized clients can't even determine that sshd is running. Not that I find that usefull but thats the idea. >>> 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*. Obviously. Anything less and you can jjst use telnet. > Mike Stone MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]