Re: Errors at ECC key generation in non-interactive mode

[Ryru]

Hi Daniel,

On 31.05.2017 21:47, Daniel Kahn Gillmor wrote:
> do you see the same error messages when you use the more modern --quick
> command-line syntax?

I was not aware of this syntax style. Thank you.

  fpr=$(gpg --with-colons --quick-gen-key "Test user "
ed25519 | awk -F: '/^fpr:/{ print $10 }')

This immediately runs gpg and ask for a password and creates an EdDSA
signing key without any errors.

> what version of gpg are you running when you see those warnings?

I run GnuPG 2.1.15 on Ubuntu 17.04. It is also possible to create an ECC
keypair with gpg --expert --full-gen-key without any errors. I just
would prefer to have a paramter file for later/future use.

Thank you.
Pascal

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Errors at ECC key generation in non-interactive mode

[Ryru]

Hi List

I get these errors while trying to create a new ECC key:

$ gpg --batch --gen-key Desktop/params-ecc.txt
gpg: key ABCDEFABCDEFABCD marked as ultimately trusted
gpg: error reading rest of packet: Invalid argument
gpg: error reading rest of packet: Invalid argument
gpg: can't encode a 256 bit MD into a 88 bits frame, algo=8
gpg: can't encode a 256 bit MD into a 88 bits frame, algo=8
gpg: revocation certificate stored as
'~/.gnupg/openpgp-revocs.d/ABCDEFABCDEFABCD.rev'

My parameters are:

$ cat params-ecc.txt
Key-Type: EdDSA
Key-Curve: Curve25519
Key-Length: 256
Subkey-Type: ECC
Subkey-Curve: Curve25519
Subkey-Length: 256
Name-Real: 
Name-Comment: 
Name-Email: 
Passphrase: 
Preferences: S9 S13 S8 S12 S7 S11 S10 H10 H9 H8 Z3 Z2 Z1
%commit

gnupg creates a key though, but I could not find any hints regarding the
errors. Do I use wrong parameters?

Thanks and regards
Pascal

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Security doubts on 3DES default

[Ryru]

Thank you Robert for your response and point of view.

On 03/13/2017 04:17 PM, Robert J. Hansen wrote:
>> According to the gpg2 man page, 3DES is added always as kind of least
>> common denominator:
> 
> This is required behavior per RFC4880.  Your concern should be addressed to
> the IETF OpenPGP working group, not to GnuPG.

Just because it's required behaviour doesn't mean it's (still) good. ;-)
But I will try contact them.

Apart from that, as GnuPG is in a kind of symbiosis with
OpenPGP/RFC4880, I think it's important to discuss this on this mailing
list (as well).

>> In my opinion this design decision can lead to serious security troubles.
> If
>> someone, knowingly or not, removed all his/her symmetric encryption
>> algorithms in his/her public key, our conversation would only be 3DES
>> encrypted.
> 
> There is no security risk with 3DES unless you (foolishly) choose to encrypt
> vast quantities of data (multiple gigabytes) with the same key.
> 
> RFC4880 requires 3DES be used with three independent subkeys, giving it a
> technical keyspace of 192 bits, the same as AES192.  However, 24 of those
> bits are used for parity and contribute nothing to the security of the
> system, meaning it comes in at 168 bits of effective key.  This is a
> keyspace about a trillion times larger than AES128's.
> 
> There are a couple of *theoretical* attacks on 3DES that reduce it to about
> a "mere" 112 bits (still unassailable, but less strong than we'd like).  The
> best known attack requires a billion known plaintexts and
> 100,000,000,000,000,000 gigabytes of RAM.
> 
> 3DES is even somewhat resistant to quantum computation, as a 168-bit
> keyspace is still an 84-bit keyspace even after hitting it with Grover's
> algorithm and a large quantum computer.  An 84-bit keyspace can be
> brute-forced by people willing to throw huge amounts of resources at the
> problem, but it'd be tremendously annoying.  A few years ago when
> distributed.net tackled RC5-64 (with a keyspace a millionth the size of a
> quantum-attacked 3DES) it took them a large distributed cracking effort and
> eighteen months of time.
> 
> I don't know who told you that 3DES was insecure.  They misled you.  It is
> not insecure.  It is slow, it is ungainly, it has all the aesthetics of a
> Soviet worker's housing bloc, and we have better ciphers available to us.

I agree with you, we have better options than 3DES so we should switch
to better ciphers as soon as possible.

> But 3DES has also been turning brilliant cryptanalysts into burned-out
> alcoholic wrecks for 40 years.
> 
>> I think the same goes for the hashing algorithm SHA1.
> 
> Again, required per the spec, and this can be prevented by having one person
> on the list use a DSA-2048/-3072 key, which forbids SHA-1 usage.
> 
>> Is my understanding correct or do I miss an important fact?
> 
> You're missing the boat on the security of 3DES.  You're correct that SHA-1
> is unsuitable for use as a hashing algorithm and that usage of it may be
> mandated in certain situations.

I think it's a question of time till 3DES is broken, like it was with
SHA-1. To be at least one step ahead of such a mess should be the goal.

> 
>> What are your thoughts about this behaviour?
> 
> Take it up with the IETF OpenPGP working group, not GnuPG.  Get them to
> change the RFC.

As mentioned, I'll try to reach them. The support from the GnuPG
community, on this topic, would be appreciated.

>  
>> Wouldn't it be great to raise the minimum encryption and hashing level to
> a
>> more secure cipher?
> 
> The current opinion in the IETF OpenPGP working group is the next iteration
> of the standard will probably settle on AES256 and SHA256 as replacement
> MUSTs for the current 3DES/SHA-1.  (Other hashes, such as BLAKE2, SHA512,
> and SHA-3/Keccak, are also being discussed as optionals.)

Where have you found this information? I only found this draft[0] which
still contains 3DES and SHA-1.

Thanks in advance and best regards
Pascal

[0] https://tools.ietf.org/html/draft-ietf-openpgp-rfc4880bis-01


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Security doubts on 3DES default

[Ryru]

Hello List

I'm new to this list and joined because I have some security doubts
regarding encryption preferences (setpref/showpref).

According to the gpg2 man page, 3DES is added always as kind of least
common denominator:
8<---
When setting preferences, you should list the algorithms in the order
which you'd like to see them used by someone else when encrypting a
message to your key.  If you don't include 3DES, it will be
automatically added at the end.  Note that there are  many  factors that
go into choosing an algorithm (for example, your key may not be the only
recipient), and so the remote OpenPGP application being used to send to
you may or may not follow your exact chosen order for a given message.
It will, however, only  choose  an  algorithm that  is  present  on  the
preference list of every recipient key.  See also the INTEROPERABILITY
WITH OTHER OPENPGP PROGRAMS section below.
--->8

In my opinion this design decision can lead to serious security
troubles. If someone, knowingly or not, removed all his/her symmetric
encryption algorithms in his/her public key, our conversation would only
be 3DES encrypted.
In a situation in which there are several recipients, e.g. a encrypted
mailing list, one participating public key/person can downgrade the
whole encrypted conversation to every recipient to 3DES instead of lets
say AES256.

I think the same goes for the hashing algorithm SHA1.

Is my understanding correct or do I miss an important fact? What are
your thoughts about this behaviour?

Wouldn't it be great to raise the minimum encryption and hashing level
to a more secure cipher?

Thanks in advance and best regards
Pascal

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users