# Tag Info

0

To start things: Don't roll your own crypto. What you're proposing is using standard static Diffie-Hellman for key-exchange, which by itself is a bad idea, as it will always result in the same key for each communcication between Alice and Bob. The key by itself should be safe, but as soon as it's broken all messages are as well. So if either the sender's ...

0

You don't need a hash function for this. Given that you're already using AES-128, and that your master key $N_s$ is 128 bits long, a perfectly good method for deriving the session keys $K_s$ would be to encrypt the random number $R_0$ (padded to a full AES block) using AES-128 (in ECB mode, i.e. using the raw block cipher) with $N_s$ as the key. Even if ...

0

First, Don't roll your own crypto. Second, you don't need to negotiate session keys for each transmission. As long as the network-secret is safe, all the connections using this secret are always safe. However, you mentioned forward secrecy. You can't get this with pre-shared keys. If the keys gets screwed every connection (now and in the future) can be ...

0

So, they both have a 16 byte shared secret, and you want to create a shared 16 byte (=128 bit) AES key...am I missing something here? Why not just use the secret as the key! Just plug it into CBC or CTR or GCM or something, and you'll be good. If you'll be running this for a large number of messages, then the scheme you described using HMAC would be ...

0

I think you overlooked some words in section 9: Key re-exchange is performed using whatever encryption was in effect when the exchange was started. Encryption, compression, and MAC methods are not changed before a new SSH_MSG_NEWKEYS is sent after the key exchange (as in the initial key exchange). Note that it is better to keep to the ...

3

I think I found an answer in this thread: http://www.gossamer-threads.com/lists/gnupg/users/65236 In short: There is a packet which looks like a key revocation but it could be forged. If an OpenPGP application downloads the key from the server then it does a signature check.

0

Yes, you can use a (semi) static key pair for (Elliptic Curve) Diffie-Hellman. If you want to check for sure that you use ECDH correctly take a look at the NIST SP 56A which shows the various way that key agreement can be used. In this case you'd probably look for 6.2.2.2. Note that you should check the public keys for validity. Furthermore, this ...

Top 50 recent answers are included