Re: Ohhhh jeeee: can't encode a 512 bit MD into a 608 bits frame

[NIIBE Yutaka]

On 05/22/2015 02:27 AM, Philip Jackson wrote:
> The key ID was 0x6e767393

It seems for me that this key has subkey of ECC, and that's the cause
of your trouble.

I think that we need to implement some compatibility feature in GnuPG
2.0 (and 1.4).

Last month, I did a fix, but I think that more is needed.

g10: fix cmp_public_key and cmp_secret_keys.

http://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=commit;h=43429c7869152f301157e4b24790b3801dce0f0a

I'll look into detail.
-- 

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

Re: installing version 2.1.4 in Debian 8.0 (Jessie)

[Peter Lebbing]

On 27/05/15 06:22, Rex Kneisley wrote:
> As a follow up. Since, version 1.4 is also installed, my assumption
> is that using "gpg" on the command line invokes 1.4, and using "gpg2"
> on the command line invokes 2.x. Is my assumption correct?

Yes.

> If so, is there any way to make the command "gpg" invoke version 2.x?
> It is a bit tedious to add the 2 on every command to ensure I am
> invoking version 2.x

I wouldn't recommend it, since you might change it for scripts and
programs as well as for yourself, and the programs will expect GnuPG
1.4. It might in some cases matter.

If you find adding the 2 tedious, you could make a symlink titled "g" or
"gp"... that way, you save a letter instead of having to type one extra,
and there is no chance that any script or program that executes "gpg"
expecting 1.4 will accidentally pick your symlink.

And the safest place anyway for such a symlink would be in $HOME/bin,
since this will keep it out of sight of programs that just use the
system-wide $PATH.

$ cd
$ mkdir bin
$ cd bin
$ ln -s /usr/bin/gpg2 gp

I think your .profile likely already contains the following:

# set PATH so it includes user's private bin if it exists
if [ -d "$HOME/bin" ] ; then
PATH="$HOME/bin:$PATH"
fi

And in that case, you need to log out and log back in and the directory
will be added to your $PATH. Under X, you probably need to log out of
the whole X session, not just start a new terminal.

>> On May 26, 2015, at 7:41 PM, gnupg-users-requ...@gnupg.org wrote:
>> 
>> Send Gnupg-users mailing list submissions to gnupg-users@gnupg.org
>> [...]

Could you please trim your quotes?

And unfortunately, by replying to the digest, you break threading of the
conversation. People that use a threading mail viewer see all
conversations on the mailing list grouped by individual conversation.
When you reply to the digest, this appears as a new conversation rather
than a follow-up to the existing conversation.

HTH,

Peter.

-- 
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at 

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

Re: Ohhhh jeeee: can't encode a 512 bit MD into a 608 bits frame

[Philip Jackson]

On 27/05/15 10:36, NIIBE Yutaka wrote:
> On 05/22/2015 02:27 AM, Philip Jackson wrote:
>> The key ID was 0x6e767393
> 
> It seems for me that this key has subkey of ECC, and that's the cause
> of your trouble.

You're right - this key has an ECC subkey for signing.  I've imported this key
into another pc using Deb8, gnupg 2.1.3, Icedove and enigmail 1.8.2 and it
doesn't cause any problem on that setup.

I tried to re-import it into the original desktop system to see if the problem
recurred.  (I should have done that before writing the last mail, to confirm
fault). With the original desktop : gpg 1.4.16 and gpg2 2.0.22, Thunderbird with
enigmail 1.8.2 :

- enigmail filed to import the key

- gpg2 failed with the message

gpg2 --recv-keys 0x6e767393
gpg: requesting key 0x6E767393 from hkp server pool.sks-keyservers.net
Version: SKS 1.1.5
gpg: armour header:
Comment: Hostname: sks.alpha-labs.net
gpg: armour header:
gpg: can't handle public key algorithm 19
gpg: pub  4096R/0x2A234ABC6E767393 2013-10-08  Jacky Alciné 
gpg: key 0x2A234ABC6E767393: removed multiple subkey binding
gpg: can't handle public key algorithm 22
gpg: can't handle public key algorithm 18
gpg: O j: can't encode a 512 bit MD into a 608 bits frame
Aborted (core dumped)


- gpg imported it ok

- gpg -k  runs to complete listing showing the problem key as the last one in
the listing (which it is)

-gpg2 -k  runs listing but stops just before the problem key which it does not
list and gives this same message :

gpg: O j: can't encode a 512 bit MD into a 608 bits frame
Aborted (core dumped)

- enigmail will not list this key

I have other keys in my public keyring which also have ECC subkeys and these do
not cause any difficulty either with enigmail or gpg2.0.22

So far it is only key 0x6e767393 which causes the problem.

Philip



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Ohhhh jeeee: can't encode a 512 bit MD into a 608 bits frame

[NIIBE Yutaka]

Hello,

Thank you for more information.

On 05/27/2015 08:53 PM, Philip Jackson wrote:
> I tried to re-import it into the original desktop system to see if the problem
> recurred.  (I should have done that before writing the last mail, to confirm
> fault). With the original desktop : gpg 1.4.16 and gpg2 2.0.22, Thunderbird 
> with
> enigmail 1.8.2 :
[...]
> gpg: O j: can't encode a 512 bit MD into a 608 bits frame
> Aborted (core dumped)

I think that 2.0.22 has this problem.  I checked 2.0 series commit logs.

I think that It was handled by the commit:


http://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=commit;h=6286d01ba33b963be30fbb4fba6f35f1b05acd17

commit 1f842011f611625c8a5fd852d5a2b4bd13e4b563
Author: Werner Koch 
Date:   Fri Oct 4 18:01:40 2013 +0200

gpg: Kludge not to bail out on ECC if build with Libgcrypt 1.6.

* g10/misc.c (print_pubkey_algo_note): Map the algo.
(openpgp_pk_test_algo, openpgp_pk_test_algo2): Ditto.
(pubkey_get_npkey, pubkey_get_nskey, pubkey_get_nsig)
(pubkey_get_nenc): Return 0 for ECC algorithms.
--

Libgcrypt 1.6 features algorithm 18 (generic ECC).  Because of the
missing mapping and no real support for the OpenPGP ECC format, this
led to parsing errors of ECC packets.  We better better explicitly
tell gpg that we ECC is not supported.

Signed-off-by: Werner Koch 

It was done soon after 2.0.22.  I think that 2.0.23 or later doesn't
have this issue.  The signature check is just skipped as unknown algo.

> I have other keys in my public keyring which also have ECC subkeys
> and these do not cause any difficulty either with enigmail or
> gpg2.0.22

I think that it occurs because it has SHA512 signature.  I guess that
other keys with ECC subkeys in your keyring has SHA256 signature.
-- 

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

Re: Ohhhh jeeee: can't encode a 512 bit MD into a 608 bits frame

[Philip Jackson]

On 27/05/15 15:05, NIIBE Yutaka wrote:
> It was done soon after 2.0.22.  I think that 2.0.23 or later doesn't
> have this issue.  The signature check is just skipped as unknown algo.

One of the problems with using linux distribution packages.  The latest for
Ubuntu 1404 is 2.0.22-3ubuntu1.3 which I have.  Ubuntu 1404 is the current
LongTermSupport version.

One of the standard advice replies given on this list is to stick to the
official packages but these move like the wheels of eternity.

Ubuntu's latest active development version is Wily Werewolf and that will have
2.0.26 - so it might take a decade or so before gnupg2.1.xxx gets into the loop.

Philip



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Random Seed for Generating PGP Keys

[George Lee]

Hi,

> I know that a CSPRNG is supposed to make this cryptographically secure

Also, I may be wrong here -- it seems that CSPRNG sometimes refers to
libgcrypt's "Continuously Seeded" and other times refers to
"Cryptographically Secure."

Peace, community, justice,
- George
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Random Seed for Generating PGP Keys

[George Lee]

Hi,

I'm not trying to generate multiple random numbers, but just generate a PGP
key one time in a way that is very hard to crack by basing it on a one-time
seed generated manually in a reliably random way.

With software, there's risks that the sequence of numbers generated isn't
fully random and that someone could cut use information about the software
or other numbers it generates, to better guess any single number it
generates. I know that a CSPRNG is supposed to make this cryptographically
secure, but (and correct me if I'm wrong) it seems that some one-time
offline truly random process (like rolling a thousand non-biased coins by a
no-biased person) is guaranteed to be more random than any HWRNG or
software RNG that might actually have correlations you're not aware of. It
also seems less susceptible to somebody using knowledge of the software or
number-generating process to better crack what numbers you used.

(1) Is there a way to seed the random number generators used by GnuPG with
a one-time manually entered seed?

(2) Is there a way to seed any of the random number generators people have
mentioned in this thread, with a one-time manually entered seed?

(3) Is there a way to have GnuPG use a different random number generator
like he ones people mentioned on this thread?

(4) Of the random number generators mentioned in this thread, which are
cryptographically secure?

Peace, community, justice,
- George
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Random Seed for Generating PGP Keys

[Robert J. Hansen]

> number it generates. I know that a CSPRNG is supposed to make this 
> cryptographically secure, but (and correct me if I'm wrong) it seems 
> that some one-time offline truly random process (like rolling a
> thousand non-biased coins by a no-biased person) is guaranteed to be
> more random than any HWRNG or software RNG that might actually have
> correlations you're not aware of.

This is not true.  A flipped coin has a very slight bias for the side
that was up when it was flipped.  Dice have subtle irregularities that
predispose them towards certain numbers and away from others.  Not even
quantum effects are truly random -- although the underlying effect may
be, the measuring apparatus by which we monitor the event will always
introduce hidden bias.  People have even managed to show bias in Geiger
counters (!!).

Software has problems, yes.  So too do manual processes.  And generally
speaking, competently-designed hardware or software solutions beat the
living daylights out of manual processes.  You can demonstrate the bias
of a flipped coin with nothing more than a couple of very boring days
spent flipping coins and some pen-and-paper work; demonstrating bias in,
say, an ANSIX9.17 RNG takes quite a lot more.

> (1) Is there a way to seed the random number generators used by
> GnuPG with a one-time manually entered seed?

Not really, no.

> (2) Is there a way to seed any of the random number generators
> people have mentioned in this thread, with a one-time manually
> entered seed?

Sure.  Most CSPRNGs permit you to specify the initial seed.

> (3) Is there a way to have GnuPG use a different random number
> generator like he ones people mentioned on this thread?

Not unless you hack the source.

> (4) Of the random number generators mentioned in this thread, which
> are cryptographically secure?

Can't be answered.  Whenever talking about cryptographically secure
PRNGs, you have to specify the operating assumptions.  Even something
with a proof of security attached (like Blum Blum Shub) you have to
specify the assumptions involved.  For instance, with Blum Blum Shub the
assumption is "the Integer Factorization Problem is intractable."



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

Re: Random Seed for Generating PGP Keys

[Robert J. Hansen]

> Also, I may be wrong here -- it seems that CSPRNG sometimes refers
> to libgcrypt's "Continuously Seeded" and other times refers to 
> "Cryptographically Secure."

It's an unfortunate ambiguity, yes.

"Cryptographically secure" is a misnomer at best: it tends to lead
people into thinking it means the RNG cannot be broken, when in reality
it just means we don't know how to do it yet.


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

Re: Ohhhh jeeee: can't encode a 512 bit MD into a 608 bits frame

[Werner Koch]

On Wed, 27 May 2015 15:24, philip.jack...@nordnet.fr said:

> One of the problems with using linux distribution packages.  The latest for
> Ubuntu 1404 is 2.0.22-3ubuntu1.3 which I have.  Ubuntu 1404 is the current
> LongTermSupport version.

I would expect that a LTS version fixes critical bugs.  What you see
might soon be a problem for many more people, thus this should be fixed
by Ubuntu.


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


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

Re: Random Seed for Generating PGP Keys

[flapflap]

George Lee:
> I'm not trying to generate multiple random numbers, but just generate a PGP
> key one time in a way that is very hard to crack by basing it on a one-time
> seed generated manually in a reliably random way.

I might be wrong here, but as I understand it you need way more often
random numbers than you seem to expect.  The random number is not only
needed for your - for example - RSA OpenPGP key certificate.  You also
need random numbers for the AES session keys that are actually used to
encrypt a file or an email.  If you had a perfectly random RSA key and
used it to encrypt AES session keys for emails, but every session key
turned out to be 0x00 for all the messages (because your RNG is
buggy/backdoored), and your advisary nows this, they simply can use the
known session key 0x00 and don't care for your RSA key.



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

https://www.gnupg.org/download/index.en.html#dirmngr contains a typo : "Dirmngr >is< an optional tool>s<"

[Toralf Förster]

;)
-- 
Toralf
pgp key: 7B1A 07F4 EC82 0F90 D4C2  8936 872A E508 0076 E94E

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

Re: Random Seed for Generating PGP Keys

[Daniel Kahn Gillmor]

On Tue 2015-05-26 23:08:56 -0400, NIIBE Yutaka wrote:
> Lessen was: Wikipedia is(was) not friendly to DIY hardware/software
> people to link there useful information.

Wikipedia sees itself as not a place to publish original research, and
they frown on self-linking to avoid .

However, i think NeuG is clearly a valuable reference for people trying
to understand HWRNGs, and my linking to it is not a self-link.

So i've added a citation there:

  
https://en.wikipedia.org/w/index.php?title=Hardware_random_number_generator&action=historysubmit&type=revision&diff=664323918&oldid=663284657

Thanks for your work on this, gniibe!

   --dkg


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

Re: Random Seed for Generating PGP Keys

[NIIBE Yutaka]

Hello,

On 05/27/2015 10:14 PM, George Lee wrote:
> I'm not trying to generate multiple random numbers, but just generate a PGP
> key one time in a way that is very hard to crack by basing it on a one-time
> seed generated manually in a reliably random way.

I'd understand your point.  I interpret it as: you would like to
control your computing, especially around cryptography, specifically
your PGP key.

I also would understand your (a kind of) frustration not being able to
get direct answer.  People say different opinions.

I think that more knobs for finer control/tuning doesn't work well
here (the risk of bad configuration would be huge), and that would be
a reason why GnuPG/libgcrypt has an interface to replace its random
generation process by an external input.


> I know that a CSPRNG is supposed to make this cryptographically
> secure, but (and correct me if I'm wrong) it seems that some one-time
> offline truly random process (like rolling a thousand non-biased coins by a
> no-biased person) is guaranteed to be more random than any HWRNG or
> software RNG that might actually have correlations you're not aware of.

I think that modern HWRNG implementations should be more than "rolling
a thousand non-biased coins by a no-biased person".  The generation
speed of HWRNG is far better than an experiment by a person, and it is
(usually) tested by modern empirical statistical testing.  Modern
empirical statistical testing checks/requires Giga bytes of random
number sequence, at least, or Tera bytes.  I don't think it is
practical for an experiment by a person to ask generating even Mega
bytes of sequence to test.

I think that if your point is bias of correlations, no person can beat
modern HWRNG.

> also seems less susceptible to somebody using knowledge of the software or
> number-generating process to better crack what numbers you used.

Right.

The question here is the likeliness of back door(s).  Even if the
sequence is tested by modern empirical statistical testing by Tera
bytes and it says no bias and no correlations, it is possible someone
else has (more) knowledge than a user and can guess the sequence
(forward or backward).

> (1) Is there a way to seed the random number generators used by GnuPG with
> a one-time manually entered seed?

Although I don't recommend to do it, you can modify the file:
.gnupg/random_seed (the binary file).

Alternatively, you can feed to /dev/random to stir the system random
pool.  Then, you can indirectly feed your entropy for the generation
of GPG key.

In my Debian GNU/Linux, I can do:

$ cat > /dev/random
Hello,
...
^D

In this way, I can enter anything (say, the result of coin experiment
in any encoding, in any language, in any format) to stir the system
random pool.  No, this doesn't increase the value of
/proc/sys/kernel/random/entropy_avail, just we can stir.

If you would like better control of it, please see the manual of
random(4) to write a program using ioctl with RNDADDENTROPY.  Then,
you can increase /proc/sys/kernel/random/entropy_avail.

Besides, there is a file /var/lib/random-seed (in my Debian).  You can
edit this file (by root) if you really would like to do so.

The reason why I don't recommend modifying /var/lib/random-seed or
.gnupg/random_seed directly is that there will be more chance to make
errors for the modification (than getting better result).


> (2) Is there a way to seed any of the random number generators people have
> mentioned in this thread, with a one-time manually entered seed?

I don't know any HWRNG products with manually entered seed, but in the
standard document, it is addressed that keyed hash/encryption can be
used (instead of normal hash/encryption) as conditioning component.
(Conditioning component is the component to remove bias).

So, in theory, it is possible to add such a feature.

> (3) Is there a way to have GnuPG use a different random number generator
> like he ones people mentioned on this thread?

No, I don't think so.

Alternatively, you can feed to /dev/random from any random number generator.

If you don't want to use /dev/random and GnuPG implementation to
generate GPG key, I think that it is still possible to write a small
program to generate OpenPGP key.

> (4) Of the random number generators mentioned in this thread, which are
> cryptographically secure?

Do you mean something like:

A PRBG that passes the next-bit test (possibly under some
plausible but un-proved mathematical assumption such as the
intractability of factoring integers) is called a
cryptographically secure pseudorandom bit generator (CSPRBG).

in Chapter 5, Pseudorandom Bits and Sequences of HAC [0]?
Please note that it is for Psudorandom generator, but we can
consider similar criteria.

Any modern HWRNG, system's /dev/random, or the structure of GnuPG's
random generation process all use similar component to prevent
possible attacks to guess its random number sequence.


[0] Menezes, P. van Oorschot, and 

Re: Trying to install version 2.1.4

[Daniel Kahn Gillmor]

On Sun 2015-05-24 06:58:21 -0400, Peter Lebbing wrote:
> It might also be that the package maintainers (hi dkg!) might soon put 2.1.4
> into experimental themselves. So it really depends on how far you want to take
> this "I need the latest and greatest".

Sorry, i'm aware of this but terribly behind on a lot of other
projects.  I do hope to get to it "real soon now", but i don't know how
long that will take.

 --dkg

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

Re: Trying to install version 2.1.4

[Daniel Kahn Gillmor]

On Wed 2015-05-27 22:40:44 -0400, Daniel Kahn Gillmor wrote:
> On Sun 2015-05-24 06:58:21 -0400, Peter Lebbing wrote:
>> It might also be that the package maintainers (hi dkg!) might soon put 2.1.4
>> into experimental themselves. So it really depends on how far you want to 
>> take
>> this "I need the latest and greatest".
>
> Sorry, i'm aware of this but terribly behind on a lot of other
> projects.  I do hope to get to it "real soon now", but i don't know how
> long that will take.

OK, i've uploaded 2.1.4 to debian/experimental.  I wanted to upload it
to debian/unstable, but we have more planning to do before i make that
move, and it seemed faster to just get 2.1.4 in place.

please let me know if you have any problems with the 2.1.4 package from
experimental once it hits the repositories (hopefully within a day).

happy hacking,

  --dkg


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

Re: Trying to install version 2.1.4

[Rex Kneisley]

Successfully installed Gpg2 experimental. I was pleasantly surprised to find 
that I was at 2.1.4 when I ran a version check from the command line.
Also installed GPA. Imported my private key successfully. Can  still see all 
the public keys I Imported using 2.0.26.
Seems to be running fine so far. I will continue to experiment.

Thank you for all of your hard work.

Rex

Sent from my iPad

> On May 27, 2015, at 10:45 PM, Daniel Kahn Gillmor  
> wrote:
> 
>> On Wed 2015-05-27 22:40:44 -0400, Daniel Kahn Gillmor wrote:
>>> On Sun 2015-05-24 06:58:21 -0400, Peter Lebbing wrote:
>>> It might also be that the package maintainers (hi dkg!) might soon put 2.1.4
>>> into experimental themselves. So it really depends on how far you want to 
>>> take
>>> this "I need the latest and greatest".
>> 
>> Sorry, i'm aware of this but terribly behind on a lot of other
>> projects.  I do hope to get to it "real soon now", but i don't know how
>> long that will take.
> 
> OK, i've uploaded 2.1.4 to debian/experimental.  I wanted to upload it
> to debian/unstable, but we have more planning to do before i make that
> move, and it seemed faster to just get 2.1.4 in place.
> 
> please let me know if you have any problems with the 2.1.4 package from
> experimental once it hits the repositories (hopefully within a day).
> 
> happy hacking,
> 
>  --dkg

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