First: I am impressed, and honoured, to have had a fast response from Werner.
I vaguely understand your explanation that the 1024 "Count" value was interpreted for backward compatibility with 1.4. However, according to the info gpg, I had followed their instructions in asking for some specific algorithms and Count values, as: time gpg2 -c --s2k-cipher-algo AES256 --s2k-digest-algo SHA256 \ --s2k-count Count_Value cleartext_file ... where info gpg notes for --s2k-count n : Specify how many times the passphrases mangling for symmetric encryption is repeated. This value may range between 1024 and 65011712 inclusive. ... which seems to imply very clearly that I wished to use AES256 together with SHA256, and that I had specified permissible Count values. Furthermore, this was symmetric encryption (my recipients were not keen on installing gpg properly!!), with (several) defined Count_Values --- for my test purposes. Incidentally, the code complained about names AES-256 and SHA-256, but not about the names used above. Thus, I do not really understand why my instruction was ignored to give "1.4 compatibility". I am still rather in the dark concerning your code as my C does not exist: I am more the Algol, Fortran, Pascal, and IDL type (I said I was a long-time, if occasional, User of GnuPG). I hoped I was using Count values of 1024, 131072, 2097152, 65011712 --- all of which are legitimate, although I understand that some may be rounded up. If you need to change the detailed format, what Count values do these actually produce? > You can't compare some AES-KDF to the SHA1 based KDF of OpenPGP. The > increase in speed you see is due to caching effects on modern CPUs and > the highly optimized SHA1 code in Libgcrypt. Something a cracker > would have also. OK, this is another surprise to me. I had imagined the KDF would be based on an iterated AES cipher, rather than an iterated hash function, and that if a hash function were used it would be the requested SHA-256. Hash functions may be more typically used to test the result of KDF processing, rather than forming the KDF itself. As you know, both AES-128 and SHA-1 are generally deprecated functions. In any case, I understand that the AES and SHA families are compact serial functions that can (I assume) be evaluated within a modern CPU chip using a single thread. I have been assuming that the "Counts" relate to iterations within the KDF (as AES-128 and AES-256 have standard "rounds" counts of 10 and 14), which seems to imply the KDF processing effort (and thus timing) should be linearly related to the number of Counts. Perhaps it is, although my uncertainty of effective "Counts" makes this unclear. For the maximum 65011712 Count, the difference between 28 Bytes and 565 kBytes was 0.02 s, which may relate to the decryption process. At 2097152 Count, subtraction of 0.02 from the 565kByte result produces the 28 Byte result; and for this "decryption subtracted" result, the 31-fold increase from 2097152 to 65011712 Counts produces a 0.320/0.013 = 24.6-fold time increase --- which may well be equality within the crudeness of this experiment. Trying to compare smaller (and unknown effective) Counts may well give results too crude for credibility. > The default of GnuPG is to let the system take about 100ms for the S2K > to make brute forcing the password of the private key harder. Using any > non-full entropy password for symmetric encryption is a Bad Idea. With > a full entropy password the S2K iterations don't matter at all. > > So either use a a full-entropy password or use public key encryption. OK, my plan was to produce a KDF delay of 100--500ms or so, so in practice we are in the same ball-park. By "full entropy" I assume you mean an assessed entropy of 80--120 bits. Although in principle I agree, in practice it is very difficult to produce such randomness: for example, a lengthy English phrase has certain regularities that reduce entropy, and this is the basis of modified brute-force techniques. Remember, we are talking symmetric encryption here; if this is used for communication, we need to communicate the passphrase by different means, eg by telephone. My experience is that it is all too easy to mis-communicate high-entropy passphrases, with subsequent hassle. I agree public-key encryption is much better for communication, but I have difficulty persuading others to install gpg properly! The use of a high-delay KDF reduces the practical number of brute-force attempts, mitigating the need for high-entropy passphrases to a small extent. Using a modern KDF such as Argon2 (memory-hard as well as time-hard) would also mitigate the use of specialised hardware brute-forcing. Of course, all the above is detail concerning "data on the move". In practice, I am also concerned about "data at rest", where a hacker may be able to access my system --- either while I am using passphrases, or where they are stored. Symmetric encryption is typically used to encrypt local files, where it is much more practical to use complex passphrases as they need to be stored but not communicated. However, I have no oversight of what has been done within gpg to protect passphrases locally. In my earlier comment, I noted that KeePass gave a usefully 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. It may well be that such techniques are so blindingly obviously necessary that there is little point in explicitly describing them. My own perception is that a similar oversight on gpg would provide much-needed reassurance to someone like myself who is in no position to evaluate such information from the open-source code --- I must leave it to others to support/criticize any reported oversight. Thus, I reiterate my earlier query: Does such security oversight exist for gpg, and where do I find it? If not, can it please be produced. It may well be that the descriptions for KeePass may well provide a template for gpg, provided it is modified to reflect truth. As an additional point, during processes where security-critical keys/passphrases as passed from (say) KeyPass or Yubikey to gpg, or gpg decrypts secured information to make it visible, what steps are taken to secure these critical items against malevolent software, or unwanted storage on disk which may be vulnerable to subsequent attack? As I explained, any "Counsel of Perfection" on avoidance of malware is ultimately somewhat unhelpful. I would hope the gpg software would provide at least some assistance in this area. Hoping you can help me here. Tony _______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
