Take the 2-minute tour ×
Cryptography Stack Exchange is a question and answer site for software developers, mathematicians and others interested in cryptography. It's 100% free, no registration required.

From PKCS#5 v2.1, 4.1 Salt (page 6, emphasis by me), also in v2.0, RFC 2898:

In password-based encryption, the party encrypting a message can gain assurance that these benefits are realized simply by selecting a large and sufficiently random salt when deriving an encryption key from a password. A party generating a message authentication code can gain such assurance in a similar fashion.

The party decrypting a message or verifying a message authentication code, however, cannot be sure that a salt supplied by another party has actually been generated at random. It is possible, for instance, that the salt may have been copied from another password-based operation, in an attempt to exploit interactions between multiple uses of the same key. For instance, suppose two legitimate parties exchange a encrypted message, where the encryption key is an 80-bit key derived from a shared password with some salt. An opponent could take the salt from that encryption and provide it to one of the parties as though it were for a 40-bit key. If the party reveals the result of decryption with the 40-bit key, the opponent may be able to solve for the 40-bit key. In the case that 40-bit key is the first half of the 80-bit key, the opponent can then readily solve for the remaining 40 bits of the 80-bit key.

The part I don't really understand is where it saids "If the party reveals the result of decryption with the 40-bit key, ..."

Could I get some clarification of this?

share|improve this question
add comment

1 Answer 1

This appears to be describing an attack that allows an active attacker to defeat a seemingly-secure protocol.

In the normal setting where no one is attacking them, Alice and Bob share a password $W$; Alice derives a symmetric key $K$ from the password $W$ and encrypts her message with $K$, then sends it to Bob; now Bob can derive the same key (since he knows the password $W$), decrypt, and learn the message. At least, that's how things work when there is no attacker. If Alice derives a 80-bit key $K$, and if the password is sufficiently strong, then this scheme might be secure against eavesdroppers.

The part you quote is talking about an active attack that could defeat the security of that arrangement. Recall that Alice (the sender) encrypted with a 80-bit key $K$ (derived from a password $W$). In the attack, an active attacker modifies the ciphertext somehow so that the recipient Bob will decrypt it with a 40-bit key $K'$ (derived from the same password $W$). Suppose the derivation procedure has the property that $K'$ is the first 40 bits of $K$.

When Bob decrypts the ciphertext under $K'$, he will get gibberish (since he is decrypting with a different key than Alice encrypted with). Suppose that Bob replies to Bob with a complaint that decryption failed, quoting the gibberish he got back. Now the attacker can learn $K'$. Notice that a 40-bit key $K'$ does not provide adequate security, and in this scenario, the attacker knows both the ciphertext and its decryption under key $K'$; thus, the attacker can use trial decryption to find the key $K'$.

At this point the attacker knows the first 40 bits of the key $K$ that Alice encrypted with. Thus, by doing exhaustive keysearch (trial decryption) on the remaining unknown 40 bits of $K$, the attacker can recover the full key $K$ and decrypt the message. In this way the attacker learns the resulting message.

This is a related-parameter/related-key attack, where the attacker desynchronizes the endpoints and causes them to use different, conflicting parameters (e.g., different keys, different key lengths). In general, a well-designed key exchange scheme should be designed to prevent such attacks. Without additional context, I'd guess that the part you are quoting is explaining the need to guard against such attacks.

share|improve this answer
    
The next paragraphs in the source (I added a link) explain some possible countermeasures. –  Paŭlo Ebermann Jun 23 '13 at 10:58
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.