Re: [patches] add support for arc4random_buf()

[edgar]

On Feb 6, 2018 6:35 AM, Werner Koch  wrote:
>
> On Tue,  6 Feb 2018 06:25, ed...@pettijohn-web.com said:
> > Please see attached patches to add support for arc4random_buf() as an
> > alternate to /dev/{u}random. I tried to be as unobtrusive as possible
> > and maintain style. It should also allow the user to still define
> > RANDOM_CONF_ONLY_URANDOM if they would prefer to use
> > /dev/urandom. This will allow gpg to be used on filesystems mounted
> > nodev while providing quick, quality randomness.
>
> Please describe what arc4random_buf is and where it is used.

The manual is probably the best source of information.

http://man.openbsd.org/arc4random

However, the tldr.

arc4random_buf() fills the buffer with nbytes of random data using the ChaCha20 
cipher. It is thread safe. Every call stirs it more adding to it's randomness.

Thanks,

Edgar
>
> I also redirect this to the libgcrypt mailing list.
>
>
> Salam-Shalom,
>
>    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: draft-ietf-openpgp-rfc4880bis-04

[Werner Koch]

On Sat,  3 Feb 2018 06:25, gnupg-users@gnupg.org said:
> I don't know if this is an error in the documentation, but I cannot obtain 
> the sha256 result here:

Using the gpg option 

   --debug hashing

will create files with the hashed material.  This is often very helful.


Shalom-Salam,

   Werner

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


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

Re: gpg: do_plaintext(): wrote 1210414045 bytes but expected 822504068 bytes

[Werner Koch]

On Mon,  5 Feb 2018 16:41, jlight...@dsservices.com said:
> Basic questions:
> 1) Is the above message in fact an "error"?

Yes.  It may either indicate an internal error in gpg or a wrong usage
(see next).

> 2) What exactly does it mean?

When starting the encryption and if possible gpg records the lengths of
the input file.  During encryption the actually read and written bytes
are counted and compared to the size recorded at the start of the
encryption.

This is only done if the input is a regular file and its size is less
than about 4 GiB (due to the OpenPGP specs).

Are you sure that no other process is writing to the file whilst gpg is
encrypting it?  Recall that a file may already be unlinked but a process
may still write to the inode.

> 3) Why does it appear to be backwards? (i.e. Why is the first number it says 
> it "wrote" larger than what it says it "expected"?

See above.

> 4) How can I detect when this occurs as an "error" to prevent the
> encryption so re-encryption can be re-attempted?

Pipe the data to gog and you won't get that error messages.  However, it
might be slower that working directly on a file.  That depends on a lot
of factors.

> "--exit-on-status-write-error

> That seemed to explain why it didn't actually cause our script to
> error out. On adding the above flag to my encryption it created a

You don't use the --status-fd option and thus this option does not make
a difference.  Diagnostics like the one you see won't necessary
terminate the operation immediate but set a flag to finally return a
failure exit code.

> 1) The original file size we encrypt is always extremely large so it
> is not the size that caused this issue.  As noted I re-ran the
> encryption manually severa

Weel, it is less than 4 GiB.  You should not see that diagnostic for a
file of 4 GiB or larger.  If my guess on the error is right, you won't
catch the incorrect use of gpg in this case.

> 3) The command line we used to do the encryption without the new flag was:
> /usr/bin/gpg --always-trust --armor --recipient  -o 
>  --encrypt 
> Where  is the encrypted file and 
>  is the original unencrypted file.

I have two suggestions independent of the problem

 - Use the option "--batch" to make sure that gpg will never ask the
   user. 

 - If you know that the file is already compressed you should use the
   option "-z 0" to disable gpg's internal compression.  Without that
   option gpg will guess whether to compress or not.

> 5) I can't decrypt the file created because the recipient uses the bank's 
> public key so only the bank can decrypt it with their private key.

If you need you can encrypt to a second key by adding

  --recipient MYOWNKEY

> 7) gpg --version outputs:
> gpg (GnuPG) 2.0.14

That is pretty old (from 2009) and I hope that Redhat patched it to fix
a few security problems.  The current version is 2.0.31 but the 2.0
branch reach edn-of-life a month ago.  A quick look at the code didn't
reveal any bug fix which could be relevant to you problem, though.

> do_plaintext issue I'm seeing.  RedHat backports bug and security
> fixes into their version so it is not exactly the same as the upstream

I know that.  Thanks for answering possible questions in advance.


Shalom-Salam,

   Werner

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


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

Re: [patches] add support for arc4random_buf()

[Werner Koch]

On Tue,  6 Feb 2018 06:25, ed...@pettijohn-web.com said:
> Please see attached patches to add support for arc4random_buf() as an
> alternate to /dev/{u}random. I tried to be as unobtrusive as possible
> and maintain style. It should also allow the user to still define
> RANDOM_CONF_ONLY_URANDOM if they would prefer to use
> /dev/urandom. This will allow gpg to be used on filesystems mounted
> nodev while providing quick, quality randomness.

Please describe what arc4random_buf is and where it is used.

I also redirect this to the libgcrypt mailing list.


Salam-Shalom,

   Werner

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


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

Re: OpenPGP card && exporting secret keys

[NdK]

Il 06/02/2018 06:47, Matthias Apitz ha scritto:

> Is there any way to export the secret keys from the OpenPGP card to use
> them directly (with a passphrase) and without the OpenPGP card?
Not possible by design.

What you can do is generate the key on the machine, then copy (not move)
it to the card. But if you already generated it on-card you're toast.
A possible workaround could be encrypting the password store to multiple
"recipients" instead on only one (the GPGcard). Those multiple recipents
can be everything you want: GPGcards, keys on disk, other people...

BYtE,
 Diego


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

Re: OpenPGP card && exporting secret keys

[Andrew Gallagher]

On 06/02/18 10:03, Peter Lebbing wrote:
> So I always just create an
> on-disk key, back that up, and subsequently move the keys to the card.
> Obviously you need to think about data left on disk after removal of
> files; I'm just giving a quick outline. Hint: I don't have a hard disk
> plugged into the system I'm using to do this.

I recommend using an offline system to do this; then you don't need to
worry about leaving traces behind. Tails is a good solution, as it
provides an encrypted persistent partition and comes with a recent gnupg
preinstalled.

-- 
Andrew Gallagher



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

Re: OpenPGP card && exporting secret keys

[Peter Lebbing]

On 06/02/18 06:47, Matthias Apitz wrote:
> Is there any way to export the secret keys from the OpenPGP card to use
> them directly (with a passphrase) and without the OpenPGP card?

You need to do it the other way around: you need to create on-disk keys
and export them to a card. It is explicitly not possible to get a secret
key /from/ an OpenPGP card.

If you chose to have a backup of your encryption key while generating
card keys, this is what actually happens for the encryption key, but in
a streamlined process. The backup file that is created in that way can
be used to populate a new OpenPGP card once your current one breaks, but
only for the encryption subkey. It contains the actual private key material.

I think it will generate signature and authentication keys on the card;
I don't use this mode because I have more trust in GnuPG's random number
generator than any RNG on a smartcard. So I always just create an
on-disk key, back that up, and subsequently move the keys to the card.
Obviously you need to think about data left on disk after removal of
files; I'm just giving a quick outline. Hint: I don't have a hard disk
plugged into the system I'm using to do this.

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 



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

Re: gpg: do_plaintext(): wrote 1210414045 bytes but expected 822504068 bytes

[Peter Lebbing]

On 05/02/18 16:41, Lightner, Jeffrey wrote:
> 3) The command line we used to do the encryption without the new flag was:
> /usr/bin/gpg --always-trust --armor --recipient  -o 
>  --encrypt 
> Where  is the encrypted file and 
>  is the original unencrypted file.
> 
> 4) The command line with the new flag:
> /usr/bin/gpg --exit-on-status-write-error --always-trust --armor --recipient 
>  -o  --encrypt 
> 

While you are waiting for someone who knows what's going on to answer, I
think you should try to add --batch to the command line. Any
non-interactive use of the gpg binary always needs to have --batch. The
same pretty much goes for --with-colons, I don't know whether or how you
interpret output from gpg, but --with-colons gives you the
machine-readable form.

It's possible that it behaves a bit more pleasantly for this problem
with --batch, as it now understands that it's being used as such.

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 



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

Re: OpenPGP card && exporting secret keys

[Pete Stephenson]

On 2/6/2018 6:47 AM, Matthias Apitz wrote:
> Is there any way to export the secret keys from the OpenPGP card to use
> them directly (with a passphrase) and without the OpenPGP card?

Short answer: No.

Longer answer: The OpenPGP card does not permit the export of keys it
stores. That's the whole point of using the card.

If you generate new keys on the card itself, there's never any way of
exporting them. If the card is lost or damaged, so are the keys.

However, if you generate new keys on a computer, you can make a backup
of the keys before you import them onto the card. If you haven't already
done this before importing them onto the card, you're out of luck.

Cheers!
-Pete

-- 
Pete Stephenson

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

PGP-compatible USB-crypto-token with biometry support

[Fiedler Roman]

Hello List,

Is there anyone having experience with crypto-tokens to be unlocked by biometry 
using a match-on-chip scheme?

If so, which matchers are supported by hardware or is it possible to install 
them by yourself, e.g. for iris-scan if native hw-matcher does not support it 
or should be replaced by a better, newer implementation.

Thanks for any feedback,
Roman

ROMAN FIEDLER
Scientist
Information Management
Center for Digital Safety & Security

AIT Austrian Institute of Technology GmbH
Reininghausstraße 13/1 | 8020 Graz | Austria
T +43 50550-2957 | M +43 664 8561599 | F +43 50550-2950
roman.fied...@ait.ac.at | https://www.ait.ac.at

View my researcher profile: https://www.ait.ac.at/profile/detail/Fiedler-Roman/

FN: 115980 i HG Wien | UID: ATU14703506
www.ait.ac.at/Email-Disclaimer




smime.p7s
Description: S/MIME cryptographic signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users