Project

General

Profile

Bug #12178

GPG uses SHA1 for symmetric encryption

Added by Alice over 2 years ago. Updated over 2 years ago.

Status:
Rejected
Priority:
Normal
Assignee:
-
Category:
-
Target version:
Start date:
01/25/2017
Due date:
% Done:

100%

Feature Branch:
Type of work:
Code
Blueprint:
Starter:
Affected tool:

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


Related issues

Related to Tails - Bug #9511: gpg.conf could have better defaults for private key encryption Resolved 06/02/2015

History

#1 Updated by intrigeri over 2 years ago

  • Assignee set to intrigeri
  • Target version set to Tails_2.12

I'll take a look. Thanks!

#2 Updated by intrigeri over 2 years ago

  • Related to Bug #9511: gpg.conf could have better defaults for private key encryption added

#3 Updated by intrigeri over 2 years ago

  • 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 #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 over 2 years ago

intrigeri wrote:

dkg explained in #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 over 2 years ago

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.

Also available in: Atom PDF