Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Commit 7aa2729

Browse files
authored
Add comments from Maarten
Added so I don't forget them later, and also in case anyone else reads this.
1 parent 04378bc commit 7aa2729

1 file changed

Lines changed: 12 additions & 0 deletions

File tree

draft-RNCryptor-Spec-v4.0.md

Lines changed: 12 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -279,3 +279,15 @@ implementations.
279279
* Replaces SHA-1 and SHA-256 with SHA-512.
280280
* Unifies key- and password-based formats.
281281
* Adds magic to beginning to identify format
282+
283+
---
284+
285+
Comments from Maarten Bodewes. Not yet integegrated into the spec:
286+
287+
- Generating 512 bits of data using PBKDF2/SHA1 is not recommended in my opinion. It requires 4 calls to the internal PBKDF2 function, including all the iterations. Furthermore, the internal state will be no more than 160 bits - the output of SHA-1. It would be better to use SHA-512, even if that is less available to some implementations. Of course, most passwords will never reach 160 bits of entropy.
288+
- The protocol should be described in terms of HKDF instead of the underlying HMAC function (a further explanation of what that means in HMAC operations could be provided of course).
289+
- Instead of generating one large output of HKDF-extract, the keys and validation value should be generated by providing a different "OtherInfo" value. This frees the protocol from the awkward repeated use of HMAC.
290+
- Mixing SHA-512 and SHA-512 / 256 for HKDF is not recommended in my opinion. SHA-512/256 is not often available anyway. It could be that SHA-512 was meant, taking the leftmost bits. That is different from SHA-512/256 as that uses different vectors internally. The use of the leftmost bits of 512 should be made clear, unless the previous comment was heeded of course, in which case it is not needed.
291+
- It could be considered to to allow a key size of 16, 24 or 32 bytes for the key based encryption; it will be put through the extract phase of HKDF anyway (using more possible sizes will make implementations harder to validate).
292+
- You should not refer to the expired draft for AEAD using AES-CBC & HMAC-SHA2: https://datatracker.ietf.org/doc/draft-mcgrew-aead-aes-cbc-hmac-sha2/ Note that that draft does not explicitly specify how the IV should be used and if it is included in the calculations. That's the absolute minimum I would expect from a draft specifying an AEAD scheme really. Just leave the RNCryptor stand on it's own merit, there is no proof or anything for that draft anyway.
293+
- You may want to restrict decryption depending on specific parameters / protocol versions etc..

0 commit comments

Comments
 (0)