Bug #12178
GPG uses SHA1 for symmetric encryption
100%
Description
Encrypting a file with a passphrase through nautilus uses SHA1 with AES256. The 256 bit AES key will be derived from a 160 bit hash. The preferences currently used in gpg.conf have no affect on the hash used in symmetric encryption.
>gpg —list-packets file.pgp
>:symkey enc packet: version 4, cipher 9, s2k 3, hash 2
hash 2 is sha1
Adding ‘s2k-digest-algo SHA256’ to ~/.gnupg/gpg.conf will use SHA256 for deriving symmetric keys
Or —s2k-digest-algo SHA256 on the command line
>gpg —symmetric —cipher-algo AES256 —s2k-digest-algo SHA256 file
>gpg —list-packets file.gpg
>:symkey enc packet: version 4, cipher 9, s2k 3, hash 8
hash 8 is sha256
Subtasks
Related issues
|
Related to Tails - |
Resolved | 2015-06-02 |
History
#1 Updated by intrigeri 2017-01-26 08:33:29
- Assignee set to intrigeri
- Target version set to Tails_2.12
I’ll take a look. Thanks!
#2 Updated by intrigeri 2017-03-03 10:18:44
- related to
Bug #9511: gpg.conf could have better defaults for private key encryption added
#3 Updated by intrigeri 2017-03-03 10:21:43
- Status changed from New to Rejected
- Assignee deleted (
intrigeri) - Target version changed from Tails_2.12 to Tails_2.11
- % Done changed from 0 to 100
dkg explained in Bug #9511#note-2 that SHA1 is fine in this case, and that switching to SHA512 might actually decrease security => rejecting. If anyone disagrees, please discuss with upstream why you think the default setting should be changed :)
#4 Updated by cypherpunks 2017-03-06 05:14:16
intrigeri wrote:
> dkg explained in Bug #9511#note-2 that SHA1 is fine in this case, and that switching to SHA512 might actually decrease security => rejecting. If anyone disagrees, please discuss with upstream why you think the default setting should be changed :)
FWIW, that was years before the break in SHA1 was discovered showing issues with the algorithm itself, not just “160 is a bit low for collision resistance in $current_year”. And to say that SHA1 can be computed faster on some hardware than SHA512 is just silly when they both go through a KDF like S2K or PBKDF2. You can trivially offset that by adjusting the iteration count.
Anyway I’m just saying this here because I’m too lazy to argue with upstream about it and just wanted to make my opinion known. Not trying to tell Tails to increase their delta with upstream or anything. I’m sure they’ll change the algorithm in time.
#5 Updated by intrigeri 2017-03-08 14:09:34
> FWIW, that was years before the break in SHA1 was discovered showing issues with the algorithm itself, not just “160 is a bit low for collision resistance in $current_year”.
You might have missed this part of dkg’s comment I pointed you to: “This is not a situation where the message digest relies on either its collision resistance or even pre-image resistance. […] SHA1 is used as an entropy-stretching mechanism here, and as a computational obstacle — you have to do X reps of the hash from the password to get to the actual key.”
Which might explain this other misunderstanding:
> And to say that SHA1 can be computed faster on some hardware than SHA512 is just silly when they both go through a KDF like S2K or PBKDF2. You can trivially offset that by adjusting the iteration count.
The attacker can’t adjust the iteration count you used to encrypt your messages.
> Anyway I’m just saying this here because […]
Fair enough, case closed then.