Tag Info

6

Because the RFC says so. Signing and verifying using this key format is done according to the Digital Signature Standard [FIPS-186-2] using the SHA-1 hash [FIPS-180-2]. It says the same for RSA half a page down. Apparently the signature algorithm is a defined part of the public key method's specification, rather than being negotiated ...

4

It appears that based on your description, the server has a 2048 bit key pair and the clients logging in have 4096 bit key pairs. In this case, do I have the brute force protection of 2048 or 4096 bits? For someone to impersonate one of your users, they would have to break the 4096 bit key. For someone to impersonate the server, they would have to ...

3

Other advantages of CTR are: easier to decrypt from a certain offset within the ciphertext no randomness requirements for the nonce nonce can be calculated, e.g. be a simple counter nonce can be a message identifier $E = D$: encryption is the same as decryption, which means only encryption or decryption required from the block cipher less logic ...

3

There seems to be an attack on SSH when using CBC: Plaintext Recovery Attacks Against SSH. I have just scanned the paper and they state, that this will not be possible when CTR mode is used. I don't think that en-/decryption parallelization is need or even utilized in SSH. Update: Link to CERT concerning the topic: Vulnerability Note VU#958563 SSH CBC ...

2

It is critical to combine both the key exchange and the secure channel, otherwise someone can mount a man-in-the-middle attack. The way we prevent a man-in-the-middle attack is to do a key exchange, to exchange a session key that both endpoints know but no one else (including the man-in-the-middle) can know, and then authenticate both endpoints. You seem ...

Only top voted, non community-wiki answers of a minimum length are eligible