Tag Info

New answers tagged

1

The problem you want to make hard in Diffie-Hellman type groups is taking discrete logarithms, whereas you want exponentiation to be easy. Now when you pick a subgroup $G$ of $\mathbb Z^*_n$, the cost of exponentiation will be roughly proportional to $n$ whereas the cost of taking discrete logs will be proportional to $\sqrt{k}$ where $k$ is the order of the ...


1

You can start by reading: https://github.com/openssl/openssl/blob/master/engines/ccgost/README.gost It has examples on how to generate GOST certificates. After that I would suggest running a test SSL/TLS connection with those certificates and openssl s_client and openssl s_server utilities. If it works, you may then recompile OpenSSL and make it dump all ...


1

For a pre-shared secret, you just use a secure MAC to authenticate the key exchange, e.g. for the exchanged public ephemeral keys $A$, $B$ and the resultant shared secret $S$, one side could send $HMAC(PSK, S, A, B)$ and the other $HMAC(PSK, S, B, A)$. Each side can easily verify that the other is using the same exchanged values and shared secret, and that ...


0

I don't know of any chat protocol that would use this approach. I get it from your message that once the symmetric key is established, Alice and Bob communicate directly using it and that it is not an issue that the server, if malicious, can defeat any security achieved by this. However, it appears to me that your protocol suffers from a major problem, ...


1

The client generates a random symmetric key and encrypts it with the public key. This public key needs to be trusted. Make sure you use a good padding mode, OAEP should do it. Send to server, server decrypts it with the private key. Eh, that's it. No forward security though, the session can be decrypted if the RSA scheme is broken or if the private key is ...


1

Your scheme is not a good approach -- it is not safe. Your scheme is vulnerable to rollback attacks. Ideally, the security property we'd like is that this will select the best (highest) version that both client and server support. However, that security property is not achieved. A man-in-the-middle can force both parties to end up using the worst ...


0

The key exchange should also be authenticated. $\:$ GCM mode would mostly do that; however, you should authenticate an indication of which message is for Diffie-Hellman. (For example, you could use associated_data = 1 for the Diffie-Hellman messages and associated_data = 0 || application's_associated_data for application-level messages.)


2

This is a very difficult question. But first the standard information: Don't roll your own crypto if anyhow possible. (which isn't the case here) No protocol should be considered secure until formally proven secure. (TLSv1.2 is) That being said I can still provide "ad-hoc" security argumentations why it's likely that your handshake is (in)secure.I can't ...


0

I would be worried about the absence of any key-exchange process to establish symmetric keys. The whole problem of safe communication seems to come down to safe key exchange, and this is what TLS addresses. Some people on this site might disagree with me here, but if you are rolling your own protocol anyway, I'd imagine you would have better security (and ...


0

Taking a stab at answering my own question. First, this is very similar to STS (Station to Station) protocol and the KEA+ (Key Exchange Algorithm), which I had not seen before. I've refined the algorithm above and changed a few variable names for clarity (w, y become a, b; v, h become X, Z). Changes from the earlier version include removing the $kh$ and ...


1

Note: Until told otherwise this answer will assume the following things: The "Master-Key" is secure. (unextractable, 128-bit+ entropy) Ephermal (EC-) Diffie-Hellman is available and secure (keys unextractable, 2048 bit DH / 256 bit ECDH available) The random number generator used is secure. (i.e. not just relies on the time, e.g. it's a cryptographically ...



Top 50 recent answers are included