Hot answers tagged key-exchange
13
I assume you're talking about SSL/TLS or a similar protocol. In these protocols there are two reasons to use Diffie-Hellman:
Your certificate only supports signing
Either it is an RSA certificate restricted to signing, or it uses an algorithm that doesn't support encryption, such as DSA or ECDSA.
Forward security - What happens if the server's private key ...
6
An attack would be trivial if the seed of the RNG was only 32 bits; just enumerate the seeds, and test which matches the intercepted messages. That's easy.
However the default Java Random class uses a 48-bit state and seed (which would still be attackable, though $2^{16}$ times less easily), and there are safe subclasses, thus use of Random does not imply ...
4
CRAM-MD5 is a protocol to demonstrate knowledge of a password. In the context of email, it is sometime used by an email client to authenticate to a POP, IMAP, or/and SMTP server. Basically, the password is used as the key of HMAC-MD5 in a challenge-response protocol.
Among positive things there are to say about CRAM-MD5:
The password is not exchanged in ...
4
Fair exchange protocols aren't new by any means, but there is a lack of layman-friendly material out there, unfortunately. I think the high prevalence of theoretical cryptography in fair exchange protocols may be partially responsible for that.
At any rate, here is the basic idea behind a fair exchange protocol. Suppose you have two parties, Alice and Bob, ...
4
Think about this, say my public key is
9821347676528476512348612390874073765227653408545634205496835 (note this is not a valid public key, just randomish typing).
What does that mean? Big or little endian? Hex or decimal? Specifically for RSA, where is $e$, where is $N$? What is this public key authorized to do (encrypt, sign, etc)? Who has signed this ...
3
Yes, you can and use a slow hashing function when constructing the verifier. I would recommend using PBKDF2, as it is designed for this purpose.
In fact, Wikipedia says:
$v$ is the host's password verifier, $v = g^x$, $x = H(s,p)$. Using of functions like PBKDF2 instead of $H$ for password hashing is highly recommended.
Thus, you could use ...
3
The standard answer in the research literature is to use information-theoretically secure message authentication codes, typically universal hashing (aka Carter-Wegman authenticators). Of course, you could use computationally-secure message authentication codes, like CMAC or HMAC, if you wanted, though that would partly defeat one of the reasons for using ...
3
Yes, these are key derivation functions basically deriving a shared secret from information identifying the two parties (like their respective MAC addresses) and nonces and other session communication relevant information. See e.g. the PBKDF2 derivation function.
3
IBE is advantageous over standard asymmetric methods in one aspect, and that doesn't appear to apply in the case you're interested in.
In both cases, IBE and asymmetric methods require an enrollment process (whether to distribute secrets, or authentication data), so there's no real difference there.
However, when Alice wants to send a message to Bob, with ...
3
Yes. Simply send the data in the clear.
Passive attacks are not possible. For a passive attack to work, the data must be intercepted by someone other than the intended recipient. But by your definition of "pre-shared information" the existence of an intended recipient would count as "pre-shared information" (since both sides would know this). So anyone who ...
2
You are inventing your own protocol. Don't do that! You're likely to get something wrong.
Instead, use SSL. You can use SSL with a server cert and a client cert. That solves exactly this problem; each party can verify the public key of the other end of the communication and verify they're talking to who they want to talk to. If everything checks out, ...
2
It seems difficult to combine the two. PUFs can provide authentication but they are based on the sender having first built up a small number of challenge/response pairs before handing the PUF over. So if Alice gives the PUF to Bob, Alice can authenticate Bob with the response. However if the protocol is two-phased, where Alice authenticates Bob and then they ...
2
No, the user of the key does. A revocation issued by the key itself, or by a designated revoker, which is some different key.
If I am going to encrypt to you, I look at the key before I do, and I look to see if your key is revoked. Similarly, if I am verifying a signature your key made, I look to see if the key is revoked.
2
Sure. Needham-Schroeder (e.g., Kerberos) solves exactly this problem. If each party shares a key with a trusted party Trent, then it provides a protocol that Alice and Bob can use to establish a session key good for use for encrypting traffic between the two of them. Kerberos v4 uses this in a purely symmetric-key setting: no asymmetric (public-key) ...
2
The open source version of CyaSSL contains code that calls into the commercial NTRU library -- the library itself is missing of course. You might be able to make CyaSSL work with the open source NTRU implementation at https://github.com/tbuktu/libntru ; it's alpha level software though.
2
Generating an (EC)DH key pair entails "producing" the group parameters (the curve or the modulus+generator), then the private key $x$, (a random integer modulo the group order $q$), and then applying the private key to the generator (i.e. computing $xG$ on the curve, $g^x \mod p$ for plain DH). Producing new group parameters would be the most expensive ...
1
Don't roll your own crypto.
Use preexisting protocols and libraries whenever possible. If there hasn't been any cryptanalysis on your protocol, that makes it less secure, not more. Recommended protocols are recommended because they underwent a lot of cryptanalysis and they resisted.
If you think SSL isn't right for you, you're probably just not using it ...
1
If the two parties have a pre-shared key, you don't need any key exchange!
In case you are looking for a key exchange mechanism based on symmetric key cryptography (and without pre-shared keys), the only thing I can think of is Merkle puzzles (historically the first public key algorithm). Unfortunately, there is a catch: if the cost of the protocol is $n$ ...
1
No. Consider using encryption to protect against a passive adversary. In this case, encryption needs to hold from the sender to the receiver. The sender can verify that the message leaves them encrypted but they have no guarantee that it is not decrypted before the receiver unless if they can authenticate the receiver. Authentication requires knowledge of ...
1
The usual solution for the Man-in-the-Middle problem of Diffie-Hellman is to combine it with a public-key authentication solution.
This could either work by including the server's public Diffie-Hellman key (which then must be a long-term key, not a short-term or even session key – this way you lose your forward-security) in the client, or including a ...
1
Well, the obvious way to do this is:
Before the protocol occurs, Alice runs the $Gen$ procedure to create a public and a private key
For her round, Alice sends her public key to Bob
For his round, Bob selects a random symmetric key $\in \{0,1\}^n$, encrypts it with Alice's public key, and sends that encryption to Alice.
Alice decrypts the message that Bob ...
1
That's a really bad idea. The general rule is that a symmetric key can either be used for key wrapping or for data encryption, but never for both.
I assume that the keys already in the devices are currently used for processing data. If such keys are now also used for key wrapping, an attacker may abuse the existing protocols and processing facilities and ...
Only top voted, non community-wiki answers of a minimum length are eligible
