On Aug 27 I submitted a query to this mailing list on the same Subject
as headed here, with further details on the software used.
Specifically, I timed the encryption (primarily the KDF aspect) of
alternative cleartext_files with various legal count_value values (1024,
131072, 2097152, 65011712) as:
time gpg2 -c --s2k-cipher-algo AES256 --s2k-digest-algo SHA256 \
--s2k-count count_value cleartext_file
I was surprised to find that count_value of 1024 gave a timing nearly as
long as that for 65011712.
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).
However, in my Aug 30 response, I noted that I had carefully followed
the gpg man pages in specifying my wish to use an AES256 cipher, and an
SHA256 hash function. The count_value of 1024 clearly ignored my wishes
on hash function (for gpg 1.4 compatibility), and --- I must assume ---
also used AES128 cipher for the same reason. As I noted, both AES-128
and SHA-1 are generally deprecated functions in cryptography.
So I am left wondering whether my specified AES-256 and SHA-256 were
used with my other count_value values. My Aug 27 submission highlighted
a Spectra Secure YouTube which noted that the --s2k parameters were
ignored for key export without warning, and that this "bug" had been the
case since 2017. Do we now discover that the --s2k parameters are
similarly ignored for _all_ symmetric encryption procedures, in
contradiction to the man-page instructions on use?
My earlier submissions noted that KeePass (password safe) gave an
encouraging oversight of how areas of memory were secured from other
applications while KeePass is in use, giving a degree of protection from
malware etc., or having critical data finding its way onto disk storage
--- ready for scrutiny my a later hacker. I sought a similar oversight
on gpg --- perhaps based on the KeePass template. I noted the
possibility that such techniques were so obviously necessary that
(perhaps) there was little point in describing them.
The response that I have seen merely implied that such oversight would
take a lot of effort to write, and may be less helpful than expected.
This suggests to me that these "obviously necessary" techniques were
_not_ being implemented (or even attempted), and that the only solution
was to fully ensure the security of your entire system. I see this as a
"Counsel of Perfection" that may only be practical with an air-gapped
system that has had no data input from the internet. My understanding is
that Security is something typically applied in layers, with the full
knowledge that any single layer is unlikely to be perfect.
The concept that no thought may be given within gpg to the protection of
passwords, and that deprecated cryptographic functions may be in use
(despite commands to the contrary), seems to me to be highly disturbing.
Tony
_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-users
as headed here, with further details on the software used.
Specifically, I timed the encryption (primarily the KDF aspect) of
alternative cleartext_files with various legal count_value values (1024,
131072, 2097152, 65011712) as:
time gpg2 -c --s2k-cipher-algo AES256 --s2k-digest-algo SHA256 \
--s2k-count count_value cleartext_file
I was surprised to find that count_value of 1024 gave a timing nearly as
long as that for 65011712.
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).
However, in my Aug 30 response, I noted that I had carefully followed
the gpg man pages in specifying my wish to use an AES256 cipher, and an
SHA256 hash function. The count_value of 1024 clearly ignored my wishes
on hash function (for gpg 1.4 compatibility), and --- I must assume ---
also used AES128 cipher for the same reason. As I noted, both AES-128
and SHA-1 are generally deprecated functions in cryptography.
So I am left wondering whether my specified AES-256 and SHA-256 were
used with my other count_value values. My Aug 27 submission highlighted
a Spectra Secure YouTube which noted that the --s2k parameters were
ignored for key export without warning, and that this "bug" had been the
case since 2017. Do we now discover that the --s2k parameters are
similarly ignored for _all_ symmetric encryption procedures, in
contradiction to the man-page instructions on use?
My earlier submissions noted that KeePass (password safe) gave an
encouraging oversight of how areas of memory were secured from other
applications while KeePass is in use, giving a degree of protection from
malware etc., or having critical data finding its way onto disk storage
--- ready for scrutiny my a later hacker. I sought a similar oversight
on gpg --- perhaps based on the KeePass template. I noted the
possibility that such techniques were so obviously necessary that
(perhaps) there was little point in describing them.
The response that I have seen merely implied that such oversight would
take a lot of effort to write, and may be less helpful than expected.
This suggests to me that these "obviously necessary" techniques were
_not_ being implemented (or even attempted), and that the only solution
was to fully ensure the security of your entire system. I see this as a
"Counsel of Perfection" that may only be practical with an air-gapped
system that has had no data input from the internet. My understanding is
that Security is something typically applied in layers, with the full
knowledge that any single layer is unlikely to be perfect.
The concept that no thought may be given within gpg to the protection of
passwords, and that deprecated cryptographic functions may be in use
(despite commands to the contrary), seems to me to be highly disturbing.
Tony
_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-users