Tag Info

Hot answers tagged

5

Yes, there are several ways in which Mallory could pretend to be Amy. One obvious way, which doesn't even involve Amy herself in any way, would be for Mallory to perform steps 1 and 2 of the protocol normally, as if he were Amy. Then, given Betty's nonce $n_b$, Mallory can start a second, parallel instance of the protocol, again pretending to be Amy, and ...


3

Yes, because Mallory can use Amy and Betty to get any encrypted nonce; Amy and Betty are oracles for Mallory. She just has to send the nonce she has to encrypt to either one of them and they perform the task for her (in another "authentication attempt", using step 1 & 2). Usually you protect against this kind of situation by performing an encryption ...


3

HMAC-SHA-256 is sufficient for up to 256 bit security. Confer e.g. NIST SP 800-107. This recommendation is based on the premise that collision attacks are infeasible against common uses of HMAC, and that you consequently only have to worry about primary pre-image attacks that attempt to recover the secret key (and use this for forging subsequent messages). ...


3

In a rolling code both the sender and the receiver always move forward in the sequence. If the sender has sent the $n$th code, then it will send the $(n+1)$th next. Contrarily, if the receiver has seen the $n$th code it will only accept the $(n+1)$th code or some later code. What happens if the sender is at another point in the sequence? Think of that ...


3

Well, 32 bits is somewhat short, so one could just try ciphertexts. However, there is a much better attack. Choose M0 arbitrarily, let P be the CBC padding for Headers || CRC || M0, and choose M1 so that CRC( M0 || P || M1 ) = CRC(M0). Submit M0 || P || M1 to be encrypted, truncate the ciphertext to the length of encryptions of M0, and then output the ...


2

Yes, the same keypairs can be used to derive shared secrets between multiple pairs of parties. If knowing the shared secret between Alice and Bob would help Eve find out the shared secret between Alice and Carol, Eve could just create her own random private key and calculate a "shared" secret between that key and Alice's public key to get the same ...


2

Well, hope that it's not late for this answer. Because it was yesterday that I encountered this problem and I'm new to this wonderful website. According to your description, and as far as I know, this protocol meets your demands very well. First, it works with RSA as you have mentioned in the second paragraph. The original version of this protocol is ...


2

It'll be the same situation that NY City suffered some days ago: when you have little variability on your data, i.e., they have a fixed-small size, it'll always be fast to brute force. You don't say how long your number is, so I'll assume it can range from 0 - 10,000,000,000 (so, a unique number for each human being on Earth today, plus some spare). You ...


1

I haven't seen much analysis on using ordinary hashes for content authentication. Can anyone can give me a pointer on whether this is safe? With good choice of primitives it is. Public key signatures use a hash function in a similar way to identify the message signed. However, where a MAC only needs what amounts to second preimage resistance, a hash ...


1

Is there a vastly simpler way? I think so. Let the server send a reset token in the following form: (deadline, HMAC(server key, id_user || S || deadline)) That is, the server calculates an authenticator that allows id_user to change their secret from S before deadline. The key used should be only known by the server and can be changed often, since ...


1

Such keys are called static keys. Keys that are newly generated each time are called ephemeral keys. Note that you need to trust the public keys of the key pairs to use them for authentication. Please note that there is an issue if you use static keys only for plain Diffie-Hellman: the generated secret will be static as well, as the whole scheme has now ...



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