diff options
author | 2013-03-03 22:33:01 +0000 | |
---|---|---|
committer | 2013-03-03 22:33:01 +0000 | |
commit | 538ac1a0c46751bd4a5bf63f720b05a10b02c701 (patch) | |
tree | 4027da225d9f599aef3880d2b4e9d9088c6f23dd | |
parent | e6c740ba91cef3bdc59a38017921a59fbca673e0 (diff) |
added my name
-rw-r--r-- | doc/bugs/encryption_key_is_surprising.mdwn | 2 |
1 files changed, 2 insertions, 0 deletions
diff --git a/doc/bugs/encryption_key_is_surprising.mdwn b/doc/bugs/encryption_key_is_surprising.mdwn index 0f7a6ba9f..80dea87e5 100644 --- a/doc/bugs/encryption_key_is_surprising.mdwn +++ b/doc/bugs/encryption_key_is_surprising.mdwn @@ -16,3 +16,5 @@ Crypto.hs seems to imply that the cipher key it's acting upon is 512 bytes long. This lets GPG generate the randomness and by passing armor, it avoids newlines. However, this base64 encoding is never undone on the way to Crypto.hs. Hence what cipherPassphrase and cipherHmac do is dropping or skipping the first 256 bytes of the base64 value. Base64, with its 6 bit per byte encoding, causes the Hmac function to operate on 192 bytes instead of 256 bytes. The key used by GPG will be larger. Some assertions that the resulting functions really operate on strings of the right length would've been helpful. Also GPG and HMAC get tested, the encryption/decryption part are not tested AFAICS. The encryption wiki page could have had more information. Enough code (sadly in Python, not reusing the Haskell code) to operate on the resulting files can be found in [this Gist](https://gist.github.com/pkern/5078559). + +-- Philipp Kern |