From e6c740ba91cef3bdc59a38017921a59fbca673e0 Mon Sep 17 00:00:00 2001 From: "http://phil.0x539.de/" Date: Sun, 3 Mar 2013 22:25:02 +0000 Subject: encryption uses a base64 key split into two halfs instead of an unwrapped one --- doc/bugs/encryption_key_is_surprising.mdwn | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+) create mode 100644 doc/bugs/encryption_key_is_surprising.mdwn diff --git a/doc/bugs/encryption_key_is_surprising.mdwn b/doc/bugs/encryption_key_is_surprising.mdwn new file mode 100644 index 000000000..0f7a6ba9f --- /dev/null +++ b/doc/bugs/encryption_key_is_surprising.mdwn @@ -0,0 +1,18 @@ +Crypto.hs seems to imply that the cipher key it's acting upon is 512 bytes long. Because of a probable programming mistake the key that's actually used is a bit surprising. The random key is generated by this snippet in Utility/Gpg.hs: + + {- Creates a block of high-quality random data suitable to use as a cipher. + - It is armored, to avoid newlines, since gpg only reads ciphers up to the + - first newline. -} + genRandom :: Int -> IO String + genRandom size = readStrict + [ Params "--gen-random --armor" + , Param $ show randomquality + , Param $ show size + ] + where + -- 1 is /dev/urandom; 2 is /dev/random + randomquality = 1 :: Int + +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). -- cgit v1.2.3 From 538ac1a0c46751bd4a5bf63f720b05a10b02c701 Mon Sep 17 00:00:00 2001 From: "http://phil.0x539.de/" Date: Sun, 3 Mar 2013 22:33:01 +0000 Subject: added my name --- doc/bugs/encryption_key_is_surprising.mdwn | 2 ++ 1 file changed, 2 insertions(+) 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 -- cgit v1.2.3 From 6b5a96f6ba51fdb772c9ec1f0b2de4defa6fe238 Mon Sep 17 00:00:00 2001 From: "https://launchpad.net/~arand" Date: Sun, 3 Mar 2013 22:34:27 +0000 Subject: Added a comment --- .../comment_1_66b581eb7111a9e98c6406ec75b899cf._comment | 12 ++++++++++++ 1 file changed, 12 insertions(+) create mode 100644 doc/bugs/git-annex_dropunused_has_no_effect/comment_1_66b581eb7111a9e98c6406ec75b899cf._comment diff --git a/doc/bugs/git-annex_dropunused_has_no_effect/comment_1_66b581eb7111a9e98c6406ec75b899cf._comment b/doc/bugs/git-annex_dropunused_has_no_effect/comment_1_66b581eb7111a9e98c6406ec75b899cf._comment new file mode 100644 index 000000000..0624eb27c --- /dev/null +++ b/doc/bugs/git-annex_dropunused_has_no_effect/comment_1_66b581eb7111a9e98c6406ec75b899cf._comment @@ -0,0 +1,12 @@ +[[!comment format=mdwn + username="https://launchpad.net/~arand" + nickname="arand" + subject="comment 1" + date="2013-03-03T22:34:27Z" + content=""" +Vhat kind of annex is this (direct/indirect, on what filesystem, etc.)? + +Also what version of git-annex? + +I know that direct mode didn't support dropunused, at least before, and on earlier versions of annex switching back to indirect after deleting things in direct didn't work either for dropunused, if I recall correctly. +"""]] -- cgit v1.2.3 From 9528fd0afb58babd614265d41cb2cf2ca72540e5 Mon Sep 17 00:00:00 2001 From: "https://me.yahoo.com/a/2grhJvAC049fJnvALDXek.6MRZMTlg--#eec89" Date: Sun, 3 Mar 2013 22:43:41 +0000 Subject: Added a comment --- .../comment_2_11c46cd2087511c3d22b7ce7c149b3e9._comment | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) create mode 100644 doc/bugs/git-annex_dropunused_has_no_effect/comment_2_11c46cd2087511c3d22b7ce7c149b3e9._comment diff --git a/doc/bugs/git-annex_dropunused_has_no_effect/comment_2_11c46cd2087511c3d22b7ce7c149b3e9._comment b/doc/bugs/git-annex_dropunused_has_no_effect/comment_2_11c46cd2087511c3d22b7ce7c149b3e9._comment new file mode 100644 index 000000000..22a8a0c4f --- /dev/null +++ b/doc/bugs/git-annex_dropunused_has_no_effect/comment_2_11c46cd2087511c3d22b7ce7c149b3e9._comment @@ -0,0 +1,16 @@ +[[!comment format=mdwn + username="https://me.yahoo.com/a/2grhJvAC049fJnvALDXek.6MRZMTlg--#eec89" + nickname="John" + subject="comment 2" + date="2013-03-03T22:43:41Z" + content=""" +It's a ZFS filesystem, using indirect mode. Here are my version numbers: + + Vulcan:~/src/fpco $ git annex version + git-annex version: 4.20130227 + local repository version: 3 + default repository version: 3 + supported repository versions: 3 4 + upgrade supported from repository versions: 0 1 2 + +"""]] -- cgit v1.2.3 From 79dea2f2ec93512c8397cae74bee5fba15d05294 Mon Sep 17 00:00:00 2001 From: "http://joeyh.name/" Date: Sun, 3 Mar 2013 23:56:17 +0000 Subject: Added a comment --- .../comment_3_b1c3d8c6ec4b20727aaa9c4b746531b0._comment | 10 ++++++++++ 1 file changed, 10 insertions(+) create mode 100644 doc/bugs/git-annex_dropunused_has_no_effect/comment_3_b1c3d8c6ec4b20727aaa9c4b746531b0._comment diff --git a/doc/bugs/git-annex_dropunused_has_no_effect/comment_3_b1c3d8c6ec4b20727aaa9c4b746531b0._comment b/doc/bugs/git-annex_dropunused_has_no_effect/comment_3_b1c3d8c6ec4b20727aaa9c4b746531b0._comment new file mode 100644 index 000000000..b1c2ce085 --- /dev/null +++ b/doc/bugs/git-annex_dropunused_has_no_effect/comment_3_b1c3d8c6ec4b20727aaa9c4b746531b0._comment @@ -0,0 +1,10 @@ +[[!comment format=mdwn + username="http://joeyh.name/" + nickname="joey" + subject="comment 3" + date="2013-03-03T23:56:17Z" + content=""" +dropunused will do nothing if the number provided to drop is not listed in `.git/annex/unused` + +The file should be generated when you run `git annex unused` +"""]] -- cgit v1.2.3 From 31042959db2472aeadc9f70120b325154f15292c Mon Sep 17 00:00:00 2001 From: "http://joeyh.name/" Date: Mon, 4 Mar 2013 00:04:53 +0000 Subject: Added a comment --- .../comment_1_5b172830ac31d51a1687bc8b1db489f9._comment | 10 ++++++++++ 1 file changed, 10 insertions(+) create mode 100644 doc/bugs/encryption_key_is_surprising/comment_1_5b172830ac31d51a1687bc8b1db489f9._comment diff --git a/doc/bugs/encryption_key_is_surprising/comment_1_5b172830ac31d51a1687bc8b1db489f9._comment b/doc/bugs/encryption_key_is_surprising/comment_1_5b172830ac31d51a1687bc8b1db489f9._comment new file mode 100644 index 000000000..04854b3a4 --- /dev/null +++ b/doc/bugs/encryption_key_is_surprising/comment_1_5b172830ac31d51a1687bc8b1db489f9._comment @@ -0,0 +1,10 @@ +[[!comment format=mdwn + username="http://joeyh.name/" + nickname="joey" + subject="comment 1" + date="2013-03-04T00:04:53Z" + content=""" +My first concern is if this means it's insecure. Luckily it seems not; HMAC SHA1 needs only 64 bytes of entropy, which are more than provided in the 256 bytes of base64 provided. As long as both gpg and the HMAC code use the full provided key (and not just the first 64 bytes of it, say), we're ok. And as far as I can tell, both do fully consume and use the key. + +So, I don't feel the need to change the code, aside from some minor improvements to variable names. +"""]] -- cgit v1.2.3