rncryptor / rncryptor-spec Goto Github PK

If the padding is application specific the spec should at least warn implementiere about it. Defining a padding as part of the format might be better.

Why is the EncryptionKey not part of the HMAC?
So if the HAMC is checked a wrong EncryptionKey would prevent the encryption.

HMAC = HMAC(Header || Ciphertext, HMACKey, SHA-256)
HMAC = HMAC(Header || Ciphertext || EncryptionKey, HMACKey, SHA-256)

This draft is extremely close to what RNCryptor already does (since it's basically what every secure format based on CBC is going to look like…)

In considering a v4 format, make sure that RNCyrptor is explicitly derived from one of these modes (probably AEAD_AES_256_CBC_HMAC_SHA384; maybe AEAD_AES_256_CBC_HMAC_SHA512).

Single PBKDF2 w/ single salt.
Add length to HMAC data.

Currently there are two iterations of PBKDF2, one for encryption, one for HMAC. This isn't necessary. We can create one larger MCK (master content key) and break that up into smaller keys as needed. Creating a MCK is a better way to think about the problem (and only requires one salt, saving us 8 bytes in the format).

Look at RFC-5869 (HKDF) in order to expand IV and both keys from a single salt+password.

Also http://crypto.stackexchange.com/questions/12943/computing-iv-for-cbc-from-pbkdf2-hkdf

Currently, in order to determine if the password is correct, you have to HMAC the entire message. This has several problems:

• For asynchronous operations, you have to decrypt as you go, which means that you have already spent a lot of effort decrypting garbage. You may have already written files, etc.
• Determining that the password is incorrect can be very expensive, even synchronously, and the cost is proportional to the length of the plaintext. While this makes password guessing even slower, password guessing is best frustrated by properly scaling PBKDF2, and there is no security reason to make it scale with the size of the plaintext.
• HMAC validation cannot distinguish between a bad password and a corrupt message. This is very frustrating to the user for little security benefit.

Basic design approach

Use password to generate a KEK. Wrap the CEK (and possibly HMAC-Key? IV?) in an encrypted bundle. When decrypting, use password to validate bundle rather than entire ciphertext.

Having considered RFC 3394, it is not currently favored (and appears somewhat pointless).

I saw that the V3 format is using SHA1 with 10,000 iterations for key derivation, which is rather far away from the current recommendation of 1,300,000 iterations. I read in your FAQs that the decision to hardcode the iterations is intentional to make the format interoperable, but since RNCryptor's pbkdf2 functionality is still used by apps in the app store, I'm wondering what the best approach would be to prevent these apps from relying on such a low iteration count.

Requirement: Must allow PBKDF2 iterations to be defined between 1,000 and 1,000,000 (10^6). Common values in 2013 go up to 100,000 (10^5), so we would like at least one more order of magnitude to be available without adjusting the format.

Design 1 (currently favored)

Take bits 4-6 of options and make them log10(iterations) (bit 6 is MSB). So 4 would be 1,000, 6 would be 1,000,000. If it is 0, then default to 10,000 (the current setting). Bit 7 is left as reserved (if the range needs to be expanded in the future, it could be redefined as part of this field, but for now it is designated as reserved).

This provides a range of [10:10^7] in powers of 10.

Advantages

• Backward compatible
• Range is close to desired range (avoids possible denial of service if enormous ranges are passed)
• No growth in format overhead

Disadvantages

• Can only store powers of 10. This requires some extra rounding work if you use a calibration function, and disallows adjustments smaller than a power of 10. (Moderate)
• Must compute 10^x one time. (Minor)
• Must extract a a three-bit integer from the options. (Minor)
• Cannot store 1. (Minor)

Design 2 (not favored)

Add new 3- or 4-byte field for iterations, specified using bit 1 in options.

This provides a range of [0:2^24) or [0:2^32).

Advantages:

• Backward compatible (by using option bit)
• Handles any value in range (not just orders of 10)

Disadvantages:

• Adds 3 or 4 bytes to the format (moderate)
• Implementations must worry about byte-order. This hasn't come up before, and is a possible source of bugs that may not show up in casual testing. (moderate)
• Implementations must worry about denial of service if too-large values are passed. May require clamping to a smaller range. (moderate)
• In the 3-byte form, implementations must deal with an unusual number format. (minor)

Since you need to run password derivation two times (HMAC and encryption key) the number of acceptable iterations must be half the number which would be possible. It would be better to either derive both keys from a single PBKDF2 procedure (allows key expansion) or from hash-deriving two keys from a single PBKDF2 master secret. The later has the additional advantage that the two different keys would contain a usage specific identifier (and not only the semantic free salt)