TL > I was pleased to receive a rapid response from Werner Koch, who
explained that the nominated count_value of 1024 actually used a default
count_value compatible with gpg 1.4, and then went on to explain that
OpenPGP used an SHA1-based Key Distribution Function (KDF).
Jacob B > KDF here is "Key Derivation Function", not "Key Distribution
Function".
You are correct: not sure how this happened. My original submission
reflected a "Notes" paper I had been writing (for my own clarification)
which included an acronyn list with the correct expansion. I guess this
confirms my status as a non-expert, which is why I "Seek Assurance"!
Jacob B > If I understand correctly, it probably did: your data was
encrypted using AES256 using a key derived from your passphrase using
the OpenPGP KDF and an integrity check value using SHA256 was included
with the encrypted data.
That was certainly my intention, using:
time gpg2 -c --s2k-cipher-algo AES256 --s2k-digest-algo SHA256 \
--s2k-count count_value cleartext_file
where the man gpg states:
--s2k-cipher-algo name
Use name as the cipher algorithm for symmetric encryption
with a passphrase
--s2k-digest-algo name
Use name as the digest algorithm used to mangle the
passphrases for symmetric encryption.
The default is SHA-1.
--s2k-count n
Specify how many times the passphrases mangling for
symmetric encryption is repeated. This
value may range between 1024 and 65011712 inclusive.
Werner noted [for Count 1024] For backward compatibility reasons with
1.4 the default count value is used in this case [and] You can't compare
some AES-KDF to the SHAl based KDF of OpenPGP. The --s2k options mention
"mangling passphrases" which sounds exactly like a KDF, but a default
SHA-1 was used in one case, at least.
TL > My Aug 27 submission highlighted a Spectra Secure YouTube (dated 29
Nov 2021) which noted that the --s2k parameters were ignored for key
export without warning, and that this "bug" had been the case since 2017.
Jacob B > ... that would be a very serious bug ...
The Spectra Secure YouTube was:
https://www.youtube.com/watch?v=j-qBChKG15Y "Password Managers: The Case
Against GNU pass (feat gpg)". Around minute 4:31 it explains very
clearly that the --s2k settings do not work (when exporting a key),
showing screen evidence. In a later comment, Spectra Secure quotes
"additional context on reddit" from skeeto at:
https://www.reddit.com/r/commandline/comments/r4ndi9/comment/hmjbkmc/ ,
which states: "The exported S2K protection is different than than the
protection used on the keyring, so you can't infer anything about GnuPG
keys at rest unless you're storing them in exported format rather than
on your keyring. This changed in GnuPG 2.1, and that's why the S2K
options are silently ignored as of GnuPG 2.1. I'm the person who filed
the bug report discussed in the video, and the responses to that report
are how I learned what's going on.". This implies the "silent ignoring"
is correct for exported keys, but may not be relevant to other
functions. We now seem to find it can be relevant to other activities as
well.
In fact, all I can really infer is that practice does not match the man
gpg, so it is difficult to decide what is (or should be) going on.
I am not really in a position to examine the sources with any
confidence, but would welcome suggestions for software which would
permit me to check what was set up. Does John the Ripper (gpg-opencl),
plus hashcat, detail the algorithms used, having broken a password?
Tony
_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-users
