summaryrefslogtreecommitdiff
path: root/doc/bugs/encryption_key_is_surprising.mdwn
diff options
context:
space:
mode:
authorGravatar http://phil.0x539.de/ <Philipp_Kern@web>2013-03-03 22:33:01 +0000
committerGravatar admin <admin@branchable.com>2013-03-03 22:33:01 +0000
commit538ac1a0c46751bd4a5bf63f720b05a10b02c701 (patch)
tree4027da225d9f599aef3880d2b4e9d9088c6f23dd /doc/bugs/encryption_key_is_surprising.mdwn
parente6c740ba91cef3bdc59a38017921a59fbca673e0 (diff)
added my name
Diffstat (limited to 'doc/bugs/encryption_key_is_surprising.mdwn')
-rw-r--r--doc/bugs/encryption_key_is_surprising.mdwn2
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