On 15. 12. 19 19:32, Robert J. Hansen wrote:
>
>> It seems I was right to have asked here after all. It's amazing how many
>> outdated tutorials exist...
>
> That presumes they were ever accurate in the first place. Many of them
> were not.
>
>>> personal-cipher-preferences AES256 CAMELLIA256 TWOFISH AES192
>>> CAMELLIA192 AES CAMELLIA128
>>> personal-digest-preferences SHA512 SHA384 SHA256 SHA224 RIPEMD160
>>
>> Should these also be included in the default-preference-list? I think
>> the latter is only used when generating new keys (setpref), yes?
>
> Not necessarily. Personal-cipher-preferences is the list of ciphers
> you're willing to use, but the list of ciphers on your key (what's put
> there via setpref) is the list of ciphers you ask *other people* to use.
>
> Will they often be the same? Yes. But not always, and there's a
> subtlety there that's often overlooked. You might be willing to
> generate traffic using ciphers you're not willing to accept.
>
cert-digest-algo SHA512
>>>
>>> Still valid, still useful.
>>
>> This I'm uncertain about. Should probably be removed too?
>
> Probably not.
>
> The reason why cipher-algo and digest-algo are recommended against is
> because GnuPG already has a robust mechanism for choosing a strong
> cipher that you're willing to generate (via personal-cipher-preferences)
> and the recipient is willing to receive (via prefs on the key).
>
> There is no such mechanism for certificate signatures. That's entirely
> generated by you. You have zero knowledge of what algorithm other
> people will use. If you want maximum interoperability, you have to use
> SHA-1; everyone can read SHA-1 signatures.
>
> But that's SHA-1, and SHA-1 isn't exactly a highly recommended digest
> any more.
>
> Use something better and stronger. SHA512 is probably the best option
> right now. If someone can't read your certificate signatures, well --
> that's on them: they should be moving away from SHA-1.
>
>> The RFC 4880 standard (section 9) does say that 3DES and SHA-1 must be
>> implemented, but the reason I included these is because I read on some
>> websites that you do NOT want to use these at all due to their
>> weaknesses and there should be some way of warning the user that weak
>> algorithms are being used.
>
> I question the credentials of anyone calling 3DES "weak". It has one
> and only one serious cryptographic weakness: due to its 64-bit block
> size, it should not be used to encrypt more than about 4Gb of data with
> the same session key.
>
> 40 years after it was first released, the best attack on it is a
> meet-in-the-middle that requires -- hand to God, I am not making this up
> -- 64 pebibytes of RAM, 2**112 operations, and several strategic nuclear
> weapons to generate enough energy to run the computer.
>
> Let me repeat: I am not making that up.
>
> So, yeah, if your attacker has technology straight out of _Star Trek_
> and is willing to cause untold ecological catastrophe, you're hosed.
> Otherwise, 3DES is still solid.
>
> That's not to mean it's perfect. It's not. It's slow, it shouldn't be
> used to encrypt bulk data due to its 64-bit blocksize, and more. There
> are lots of reasons to prefer other, better ciphers than 3DES. And
> maybe I can understand people calling it "weak" because really, that's a
> lot easier for people to understand than talking about block sizes and
> clock-cycles-per-block and everything else.
>
> But it's *not weak*. And any website that tells you to avoid 3DES
> because it's weak is, to be honest, either too ignorant to be taken
> seriously, so patronizing they'll handwave away complex issues behind
> the comforting veneer of "it's weak", or is outright lying to you.
>
> SHA-1, on the other hand...
>
> *At the present moment* SHA-1 is still trustworthy in the places where
> it's baked into the RFC4880 spec. The attacks against it don't affect
> the (few) places where it's baked into OpenPGP. But attacks can get
> better quite suddenly, and it's a good idea to avoid SHA-1 whenever
> possible.
>
> But please don't use weak-digest on SHA-1. The only thing it'll do is
> drown you in false positives. 99.999% of the time when you get a
> warning of "SHA-1 is being used You asked me to warn you about
> it!", in fact nothing is amiss at all.
>
> A 'warning' that's wrong 99.999% of the time is worse than receiving no
> warning at all.
>
> ___
> Gnupg-users mailing list
> Gnupg-users@gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-users
>
Hey, thanks for all the help. That was really an educational read.
I ended up with this config file contents:
keyid-format 0xlong
with-fingerprint
personal-cipher-preferences AES256 CAMELLIA256 TWOFISH AES192
CAMELLIA192 AES CAMELLIA128
personal-digest-preferences SHA512 SHA384 SHA256 SHA224 RIPEMD160
default-preference-list SHA512 SHA384 SHA256 SHA224 AES256 AES192 AES
ZLIB BZIP2 ZIP Uncompressed
