Re: Smartcards and tokens

[R. Martinho Fernandes]

There's an important distinction to be made between using this approach
and using a SmartCard. The encrypted USB drive approach leaks the keys
into the machine you're using it from; they're accessible by simply
reading the filesystem (thus the claim that "When you unplug the USB,
your keys are gone." is wrong).  The keys in a SmartCard are write-only;
the SmartCard performs all the encryption on-chip.


You need to have an attack on the SmartCard to get the keys, while with
the USB drive approach, you just need to attack the host machine.




On Thu, Dec 15, 2016, at 08:34 AM, Lou Wynn wrote:

> I've come cross a simple and secure approach at this post:



> http://zacharyvoase.com/2009/08/20/openpgp/



> In the MAKING BACKUPS section, this method simply places your
> gnupg directory in an encrypted usb drive and make a symlink to it
> like this:


> ln -s /Volumes/EncDrive/gnupg ~/.gnupg
>
> That's all. As long as you use a good passphrase, this is very secure
> method to me. When you unplug the USB, your keys are gone. If your USB
> drive is lost, its content is encrypted by your passphrase, so no
> worry about it.
> 

> 

> 

> 

> On 12/14/2016 05:35 PM, NIIBE Yutaka wrote:
>> sivmu  wrote:
>>
>>> One question remaining is what is the difference between the openpgp
>>> smartcard and the USB based tokens.
>>>
>> I think that the OpenPGP card (the physical smartcard) is included in
>> Nitrokey Pro USB Token.  So, it's exactly same from the view point of
>> smartcard.  When you want to use a smartcard, you need a card reader
>> to access the card.  And the card reader you use would bring another
>> attack vectors. In this point, Nitrokey Pro USB Token is the best
>> approach, I suppose.  IIUC, Yubikey products are JavaCard
>> implementations and somehow emulate OpenPGP card protocol by "app",
>> and they work as CCID card reader + OpenPGP card.  In Nitrokey Start
>> USB Token, there is no OpenPGP card physically, but it is implemented
>> by Gnuk, the software.

>>
>>> Also how much would you trust those vendors and can the use of such
>>> tokens actually decrease security?
>>>
>> This is the point.  The hardware OpenPGP card in Nitrokey Pro USB
>> Token could be replaced by man in the middle (or its vendor).  The
>> hardware MCU chip in Nitrokey Start USB Token could be replaced, too.
>> The software (Gnuk) in Nitrokey Start USB Token could be replaced
>> (with JTAG/SWD debugger), too.  Or, we should consider possibility of
>> backdoor of OpenPGP card.  Well, I don't know about Yubikey.  When it
>> is replaced to be malicious one to enable an access by others (to
>> your private keys), or it already has a backdoor in the first place,
>> it kills the purpose of USB security token.  Here, the question is:
>> how can we build up such a "trust"?  It seems for me that there are
>> two different approaches; (1) physical difficulty (for example,
>> plastic molding for "protection"), (2) reproducibility and
>> transparency/openness.  Note that some method of former makes latter
>> difficult.   For myself, I take (2), and I did my best to make my
>> product as reproducible.  (Since I don't manufacture semiconductor
>> things, reproducibility is not 100%, and this part of manufacturing
>> and technology is not open at all.)  And I intentionally deliver my
>> product in a style of "transparent" or "open".  Distribution channel
>> is also difficult.  I do in person, and I ask FSF for my TRNG.  Are
>> there any good method?  Obvious drawback of the apporoach (2) is that
>> people with enough concern/attention have tendency to do it under
>> their control. Reasonable.  Since it's reproducible (somehow), it's
>> possible, by definition.  And then, I can't sell many.
>>
> 

> _

> Gnupg-users mailing list

> Gnupg-users@gnupg.org

> http://lists.gnupg.org/mailman/listinfo/gnupg-users


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

[Announce] Libgcrypt 1.7.5 released

[Werner Koch]

Hi!

The GnuPG Project is pleased to announce the availability of Libgcrypt
version 1.7.5.  This is a maintenace release.

Libgcrypt is a general purpose library of cryptographic building blocks.
It is originally based on code used by GnuPG.  It does not provide any
implementation of OpenPGP or other protocols.  Thorough understanding of
applied cryptography is required to use Libgcrypt.


Noteworthy changes in version 1.7.5 (2016-12-15)


 * Bug fixes:

   - Fix regression in mlock detection introduced with 1.7.4 [bug#2870].


Noteworthy changes in version 1.7.4 (2016-12-09)


 * Performance:

   - More ARMv8/AArch32 improvements for AES, GCM, SHA-256, and SHA-1.

   - Add ARMv8/AArch32 assembly implementation for Twofish and
 Camellia.

   - Add bulk processing implementation for ARMv8/AArch32.

   - Add Stribog OIDs.

   - Improve the DRBG performance and sync the code with the Linux
 version.

 * Internal changes:

   - When secure memory is requested by the MPI functions or by
 gcry_xmalloc_secure, they do not anymore lead to a fatal error if
 the secure memory pool is used up.  Instead new pools are
 allocated as needed.  These new pools are not protected against
 being swapped out (mlock can't be used).  However, these days
 this is considered a minor issue and can easily be mitigated by
 using encrypted swap space.

 * Bug fixes:

   - Fix GOST 28147 CryptoPro-B S-box.

   - Fix error code handling of mlock calls.


Download


Source code is hosted at the GnuPG FTP server and its mirrors as listed
at https://gnupg.org/download/mirrors.html .  On the primary server
the source tarball and its digital signature are:

 ftp://ftp.gnupg.org/gcrypt/libgcrypt/libgcrypt-1.7.5.tar.bz2 (2816k)
 ftp://ftp.gnupg.org/gcrypt/libgcrypt/libgcrypt-1.7.5.tar.bz2.sig

That file is bzip2 compressed.  A gzip compressed version is here:

 ftp://ftp.gnupg.org/gcrypt/libgcrypt/libgcrypt-1.7.5.tar.gz (3365k)
 ftp://ftp.gnupg.org/gcrypt/libgcrypt/libgcrypt-1.7.5.tar.gz.sig

The same files are also available via HTTP:

 https://gnupg.org/ftp/gcrypt/libgcrypt/libgcrypt-1.7.5.tar.bz2 
 https://gnupg.org/ftp/gcrypt/libgcrypt/libgcrypt-1.7.5.tar.bz2.sig
 https://gnupg.org/ftp/gcrypt/libgcrypt/libgcrypt-1.7.5.tar.gz 
 https://gnupg.org/ftp/gcrypt/libgcrypt/libgcrypt-1.7.5.tar.gz.sig

In order to check that the version of Libgcrypt you downloaded is an
original and unmodified file please follow the instructions found at
.  In short, you may
use one of the following methods:

 - Check the supplied OpenPGP signature.  For example to check the
   signature of the file libgcrypt-1.7.5.tar.bz2 you would use this
   command:

 gpg --verify libgcrypt-1.7.5.tar.bz2.sig libgcrypt-1.7.5.tar.bz2

   This checks whether the signature file matches the source file.
   You should see a message indicating that the signature is good and
   made by one or more of the release signing keys.  Make sure that
   this is a valid key, either by matching the shown fingerprint
   against a trustworthy list of valid release signing keys or by
   checking that the key has been signed by trustworthy other keys.
   See the end of this mail for information on the signing keys.

 - If you are not able to use an existing version of GnuPG, you have
   to verify the SHA-1 checksum.  On Unix systems the command to do
   this is either "sha1sum" or "shasum".  Assuming you downloaded the
   file libgcrypt-1.7.5.tar.bz2, you run the command like this:

 sha1sum libgcrypt-1.7.5.tar.bz2

   and check that the output matches the first line from the
   this list:

fa485d854748fc06ea041b3057b2de2f12fbc17f  libgcrypt-1.7.5.tar.bz2
9dc6171c0d6b46a7bc38e4af65091044633dc59a  libgcrypt-1.7.5.tar.gz

   You should also verify that the checksums above are authentic by
   matching them with copies of this announcement.  Those copies can be
   found at other mailing lists, web sites, and search engines.
   

Copying
===

Libgcrypt is distributed under the terms of the GNU Lesser General
Public License (LGPLv2.1+).  The helper programs as well as the
documentation are distributed under the terms of the GNU General Public
License (GPLv2+).  The file LICENSES has notices about contributions
that require that these additional notices are distributed.


Support
===

For help on developing with Libgcrypt you should read the included
manual and optional ask on the gcrypt-devel mailing list [1].  A
listing with commercial support offers for Libgcrypt and related
software is available at the GnuPG web site [2].

If you are a developer and you may need a certain feature for your
project, please do not hesitate to bring it to the gcrypt-devel
mailing list for discussion.

Maintenance and development of Libgcrypt is mostly financed by
donations; see .  We currently employ

Changing comment in userID

[unknown]

Hi,

i've made a keypair with a comment in the userID. Is it possible to
delete this part of the key or do I have completely delete the key and
make a new one?
I also uploaded it to the sks keyserver. What effect will it have on the
keyserver?

Thanks.


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

Re: Changing comment in userID

[Evgenii Sovetkin]

> i've made a keypair with a comment in the userID. Is it possible to
> delete this part of the key or do I have completely delete the key and
> make a new one?
> I also uploaded it to the sks keyserver. What effect will it have on the
> keyserver?

You can simply edit key. and upload it again without deleting it...



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

Re: Changing comment in userID

[NIIBE Yutaka]

On 12/15/2016 08:03 PM, unknown wrote:
> i've made a keypair with a comment in the userID. Is it possible to
> delete this part of the key or do I have completely delete the key and
> make a new one?
> I also uploaded it to the sks keyserver. What effect will it have on the
> keyserver?

Please note that modifying user ID (even if it's a comment in user ID)
makes different user ID.  And when people certify your key, signature
is about user ID.

You don't need to create new key.  You can add new user ID to existing
key by: gpg --edit-key YOUR-KEY and "adduid" sub command.  You can
also revoke an old user ID by "revuid" sub command, if you want.
Then, you can upload updated key to keyserver.  There is also "deluid"
sub command but it only affects key on your PC, since keyservers never
support deletion of record.

You need to get your user ID certified again.

Thus, it would be simpler starting with new key with new user ID.
-- 

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

Upgrade to gpg2

[unknown]

Hi,

i'm running Mint with gpg 1.4

I'd like to upgrade to the newer version of gnupg. Do I have to delete
the old one? What about my configuration file, is this only for the
older version?

I don't know how to build from the source.


Greetings.


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

Fwd: tar, compress, split and then encrypt a list of files

[Felipe Vieira]

Dear mailing list,

right now I have a working workstream that gets paths from a text file and:

tar -> compress -> encrypt -> split (over each line/entry)

Probably there is a security issue here as some of the paths are dozens of
gigabytes in size.

I would like to swap the 'encrypt -> split' part but I'm unable to do so
using the GNU split functionality. Writing to disk then opening the split
files is a big performance hit.

Can I accomplish this in a single step?
(installing/using other tools is not a problem)

Best regards,

Felipe

(not signed/sent from public computer)
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Upgrade to gpg2

[Robert J. Hansen]

> Do I have to delete the old one?

No.

> What about my configuration file, is this only for the
> older version?

Most older configuration files will work just fine with GnuPG 2.0 and 2.1.

>From the Mint command line:

sudo apt-get install gnupg2

It'll install GnuPG 2.0 (2.1 in Sarah) and you'll be ready to go.

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

Re: Smartcards and tokens

[Lou Wynn]

If the host machine is compromised, what's the purpose of doing
encryption on the SmartCard? Attackers don't need to know the key to get
your plaint ext, because it is on the host machine.

I guess that what you meant was signing, using a SmartCard to sign has
the benefits you mentioned, but not encryption.


On 12/15/2016 01:24 AM, R. Martinho Fernandes wrote:
> There's an important distinction to be made between using this
> approach and using a SmartCard. The encrypted USB drive approach leaks
> the keys into the machine you're using it from; they're accessible by
> simply reading the filesystem (thus the claim that "When you unplug
> the USB, your keys are gone." is wrong).  The keys in a SmartCard are
> write-only; the SmartCard performs all the encryption on-chip.
>
> You need to have an attack on the SmartCard to get the keys, while
> with the USB drive approach, you just need to attack the host machine.
>
>
> On Thu, Dec 15, 2016, at 08:34 AM, Lou Wynn wrote:
>>
>> I've come cross a simple and secure approach at this post:
>>
>> http://zacharyvoase.com/2009/08/20/openpgp/
>>
>> In the MAKING BACKUPS section, this method simply places your gnupg
>> directory in an encrypted usb drive and make a symlink to it like this:
>>
>> ln -s /Volumes/EncDrive/gnupg ~/.gnupg
>>
>> That's all. As long as you use a good passphrase, this is very secure
>> method to me. When you unplug the USB, your keys are gone. If your
>> USB drive is lost, its content is encrypted by your passphrase, so no
>> worry about it.
>>
>>
>>
>>
>> On 12/14/2016 05:35 PM, NIIBE Yutaka wrote:
>>> sivmu   wrote:
>>>
 One question remaining is what is the difference between the openpgp
 smartcard and the USB based tokens.

>>> I think that the OpenPGP card (the physical smartcard) is included in
>>> Nitrokey Pro USB Token.  So, it's exactly same from the view point of
>>> smartcard.
>>>
>>> When you want to use a smartcard, you need a card reader to access the
>>> card.  And the card reader you use would bring another attack vectors.
>>> In this point, Nitrokey Pro USB Token is the best approach, I suppose.
>>>
>>> IIUC, Yubikey products are JavaCard implementations and somehow emulate
>>> OpenPGP card protocol by "app", and they work as CCID card reader +
>>> OpenPGP card.
>>>
>>> In Nitrokey Start USB Token, there is no OpenPGP card physically, but it
>>> is implemented by Gnuk, the software.
>>>
>>>
 Also how much would you trust those vendors and can the use of such
 tokens actually decrease security?

>>> This is the point.
>>>
>>> The hardware OpenPGP card in Nitrokey Pro USB Token could be replaced by
>>> man in the middle (or its vendor).  The hardware MCU chip in Nitrokey
>>> Start USB Token could be replaced, too.  The software (Gnuk) in Nitrokey
>>> Start USB Token could be replaced (with JTAG/SWD debugger), too.  Or, we
>>> should consider possibility of backdoor of OpenPGP card.  Well, I don't
>>> know about Yubikey.
>>>
>>> When it is replaced to be malicious one to enable an access by others
>>> (to your private keys), or it already has a backdoor in the first place,
>>> it kills the purpose of USB security token.
>>>
>>> Here, the question is: how can we build up such a "trust"?
>>>
>>> It seems for me that there are two different approaches; (1) physical
>>> difficulty (for example, plastic molding for "protection"), (2)
>>> reproducibility and transparency/openness.  Note that some method of
>>> former makes latter difficult.
>>>
>>>
>>> For myself, I take (2), and I did my best to make my product as
>>> reproducible.  (Since I don't manufacture semiconductor things,
>>> reproducibility is not 100%, and this part of manufacturing and
>>> technology is not open at all.)  And I intentionally deliver my product
>>> in a style of "transparent" or "open".
>>>
>>> Distribution channel is also difficult.  I do in person, and I ask FSF
>>> for my TRNG.  Are there any good method?
>>>
>>> Obvious drawback of the apporoach (2) is that people with enough
>>> concern/attention have tendency to do it under their control.
>>> Reasonable.  Since it's reproducible (somehow), it's possible, by
>>> definition.  And then, I can't sell many.
>>>
>>
>> _
>> Gnupg-users mailing list
>> Gnupg-users@gnupg.org 
>> http://lists.gnupg.org/mailman/listinfo/gnupg-users
>
>
>
> ___
> Gnupg-users mailing list
> Gnupg-users@gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-users

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

Re: Smartcards and tokens

[sivmu]

Am 15.12.2016 um 02:35 schrieb NIIBE Yutaka:
> sivmu  wrote:
>> One question remaining is what is the difference between the openpgp
>> smartcard and the USB based tokens.
> 
> I think that the OpenPGP card (the physical smartcard) is included in
> Nitrokey Pro USB Token.  So, it's exactly same from the view point of
> smartcard.
> 
> When you want to use a smartcard, you need a card reader to access the
> card.  And the card reader you use would bring another attack vectors.
> In this point, Nitrokey Pro USB Token is the best approach, I suppose.
> 
> IIUC, Yubikey products are JavaCard implementations and somehow emulate
> OpenPGP card protocol by "app", and they work as CCID card reader +
> OpenPGP card.
> 
> In Nitrokey Start USB Token, there is no OpenPGP card physically, but it
> is implemented by Gnuk, the software.
> 
>> Also how much would you trust those vendors and can the use of such
>> tokens actually decrease security?
> 
> This is the point.
> 
> The hardware OpenPGP card in Nitrokey Pro USB Token could be replaced by
> man in the middle (or its vendor).  The hardware MCU chip in Nitrokey
> Start USB Token could be replaced, too.  The software (Gnuk) in Nitrokey
> Start USB Token could be replaced (with JTAG/SWD debugger), too.  Or, we
> should consider possibility of backdoor of OpenPGP card.  Well, I don't
> know about Yubikey.
> 
> When it is replaced to be malicious one to enable an access by others
> (to your private keys), or it already has a backdoor in the first place,
> it kills the purpose of USB security token.
> 
> Here, the question is: how can we build up such a "trust"?
> 
> It seems for me that there are two different approaches; (1) physical
> difficulty (for example, plastic molding for "protection"), (2)
> reproducibility and transparency/openness.  Note that some method of
> former makes latter difficult.
> 
> 
> For myself, I take (2), and I did my best to make my product as
> reproducible.  (Since I don't manufacture semiconductor things,
> reproducibility is not 100%, and this part of manufacturing and
> technology is not open at all.)  And I intentionally deliver my product
> in a style of "transparent" or "open".
> 
> Distribution channel is also difficult.  I do in person, and I ask FSF
> for my TRNG.  Are there any good method?
> 
> Obvious drawback of the apporoach (2) is that people with enough
> concern/attention have tendency to do it under their control.
> Reasonable.  Since it's reproducible (somehow), it's possible, by
> definition.  And then, I can't sell many.
> 

From what I understand, a malicious token can e.g. perform encryption
operations with weak randomness to create some kind of backdoor that is
hard to detect. Maybe there is also a way to secretly send the secret
keys loaded onto the smartcard/token to the adversary using the PC and
network it is used on.

If there is no way to detect such malicious devices and given that
certain organisations tend to mess with security tokens and crypto
devices, it seems using those specific devices actually decreases
security, assuming it is easy to manipulate specialised vendors of
security hardware compared to manipulating electronic hardware in general.

Or is this too much of a conspiracy theorie? (not that those do not have
a tendency to be outrun by reality anyway)

With nitrokey,  both the hardware design and the software is open source
and both have been audited. Bu I don't think that will keep some people
from intercepting deliveries of such devices or mess with the production.

I'm really not sure if specialised devices for crypto is a good idea,
give that it presents such a promising target.



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

Re: Smartcards and tokens

[Lou Wynn]

Hi Martinho,

After I thought about it more, I have kind of drawn the conclusion that
even for signing, only using a SmartCard cannot achieve authenticity.

With a write-only SmartCard which computes signature on the card, it's
true that it can protect the signing key. However, if it's used in a
hacked machine or malicious environment, the hash sent to the card can
be modified to be the hash of something else, not the hash of the
document that you think you're reading on screen. Even if your signing
key is kept secret on the card, but it blindly signs a fake hash. What's
good about this?

So using a write-only SmartCard alonewithout a secure host environment
cannot give you the security level you think you get. Unless I missed
something from your original description.

This actually boils down a minimal trusted computing base (TCB).
SmartCard itself does not form a complete TCB, which must include
certain trusted host environment.



On 12/15/2016 11:24 AM, Lou Wynn wrote:
>
> If the host machine is compromised, what's the purpose of doing
> encryption on the SmartCard? Attackers don't need to know the key to
> get your plaint ext, because it is on the host machine.
>
> I guess that what you meant was signing, using a SmartCard to sign has
> the benefits you mentioned, but not encryption.
>
>
> On 12/15/2016 01:24 AM, R. Martinho Fernandes wrote:
>> There's an important distinction to be made between using this
>> approach and using a SmartCard. The encrypted USB drive approach
>> leaks the keys into the machine you're using it from; they're
>> accessible by simply reading the filesystem (thus the claim that
>> "When you unplug the USB, your keys are gone." is wrong).  The keys
>> in a SmartCard are write-only; the SmartCard performs all the
>> encryption on-chip.
>>
>> You need to have an attack on the SmartCard to get the keys, while
>> with the USB drive approach, you just need to attack the host machine.
>>
>>
>> On Thu, Dec 15, 2016, at 08:34 AM, Lou Wynn wrote:
>>>
>>> I've come cross a simple and secure approach at this post:
>>>
>>> http://zacharyvoase.com/2009/08/20/openpgp/
>>>
>>> In the MAKING BACKUPS section, this method simply places your gnupg
>>> directory in an encrypted usb drive and make a symlink to it like this:
>>>
>>> ln -s /Volumes/EncDrive/gnupg ~/.gnupg
>>>
>>> That's all. As long as you use a good passphrase, this is very
>>> secure method to me. When you unplug the USB, your keys are gone. If
>>> your USB drive is lost, its content is encrypted by your passphrase,
>>> so no worry about it.
>>>
>>>
>>>
>>>
>>> On 12/14/2016 05:35 PM, NIIBE Yutaka wrote:
 sivmu   wrote:

> One question remaining is what is the difference between the openpgp
> smartcard and the USB based tokens.
>
 I think that the OpenPGP card (the physical smartcard) is included in
 Nitrokey Pro USB Token.  So, it's exactly same from the view point of
 smartcard.

 When you want to use a smartcard, you need a card reader to access the
 card.  And the card reader you use would bring another attack vectors.
 In this point, Nitrokey Pro USB Token is the best approach, I suppose.

 IIUC, Yubikey products are JavaCard implementations and somehow emulate
 OpenPGP card protocol by "app", and they work as CCID card reader +
 OpenPGP card.

 In Nitrokey Start USB Token, there is no OpenPGP card physically, but it
 is implemented by Gnuk, the software.


> Also how much would you trust those vendors and can the use of such
> tokens actually decrease security?
>
 This is the point.

 The hardware OpenPGP card in Nitrokey Pro USB Token could be replaced by
 man in the middle (or its vendor).  The hardware MCU chip in Nitrokey
 Start USB Token could be replaced, too.  The software (Gnuk) in Nitrokey
 Start USB Token could be replaced (with JTAG/SWD debugger), too.  Or, we
 should consider possibility of backdoor of OpenPGP card.  Well, I don't
 know about Yubikey.

 When it is replaced to be malicious one to enable an access by others
 (to your private keys), or it already has a backdoor in the first place,
 it kills the purpose of USB security token.

 Here, the question is: how can we build up such a "trust"?

 It seems for me that there are two different approaches; (1) physical
 difficulty (for example, plastic molding for "protection"), (2)
 reproducibility and transparency/openness.  Note that some method of
 former makes latter difficult.


 For myself, I take (2), and I did my best to make my product as
 reproducible.  (Since I don't manufacture semiconductor things,
 reproducibility is not 100%, and this part of manufacturing and
 technology is not open at all.)  And I intentionally deliver my product
 in a style of "transparent" or "open".

 Distribution channel is also difficult.  I do in p

Re: Smartcards and tokens

[Damien Goutte-Gattat]

On 12/15/2016 08:35 PM, sivmu wrote:

From what I understand, a malicious token can e.g. perform encryption
operations with weak randomness to create some kind of backdoor that is
hard to detect.


The token is normally not used to perform any *encryption*. You encrypt 
with the public key of your correspondant, which is stored on your 
computer, not on your token (there's no need to protect it since it is a 
*public* key). You use your token to *decrypt* messages that were sent 
to you--and at that time, even if the token is malicious there's nothing 
it can do to mess with the encryption.


What a malicious (or faulty) token *could* do is generate a weak key, 
that your opponent could break once and for all and then use to decrypt 
all messages sent to you. Smartcards generating weak keys have already 
been observed in the wild [1]. If you worry about that, simply generate 
your keys on a computer you trust, then load them onto the token, 
without ever using the token's own random number generator.




Maybe there is also a way to secretly send the secret
keys loaded onto the smartcard/token to the adversary using the PC and
network it is used on.


I'll admit readily that I am not an expert on this, but I don't see how 
that could be feasible without the help of the host PC--meaning your 
opponent would have to both (1) compromise your PC and (2) send you a 
malicious token. But if he could compromise your PC, he would have no 
need for a malicious token.


I guess your attacker could use a USB token as the mean to compromise 
your PC (names like "Bad USB" come to mind), but if you worry about such 
attacks, you should be wary of *any* USB device you buy (keyboards, 
mice, mass storage sticks... or even desktop missile launchers), not 
only cryptographic devices.



Damien

[1] https://eprint.iacr.org/2013/599



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

Re: ways to ensure that GPG public key belongs to right person in business to business communication

[Lou Wynn]

Let me analyze your steps to see what you'd like to achieve in each of them.

0. Alice and Bob knows each other's email addresses: alice@A and bob@B.

1. Bob sends Alice his public key at Alice email address alice@A.

2. Alice relies to Bob with her public key.

3. Alice calls B's support and asks to get Bob on the phone.

4. Bob tells Alice the fingerprint of his public key, and Alice checks
it against what she received at (1).

5. Alice tells Bob her public key fingerprint, and Bob verifies it.

You try to use step 4 and 5 to verify step 1 and 2, but it doesn't work.
Suppose that Ted sends Alice his public key impersonating Bob by a faked
from address but replies to Ted. Ted can be B's support guy who answers
phones. Then your method makes Alice think that Ted is Bob. Step 4 and 5
don't add much value because Bob's public key fingerprint is public, and
the guy in Step 3 doesn't have to be Bob. Basically, step 3 is useless,
and step 4 and 5 are like PGP's web of trust: if someone says Bob's has
that public key, then let's just believe it.

The real value starts with 0, which makes Alice believe that she knows
the owner of email of bob@B when sending to that address. The same holds
true for Bob. In step 2, you should make Alice send her public key to
the bob@B address because that's all the knowledge she has about Bob in
terms of reachability, not reply.

I'm working on a PGP key management system for organizational email
communication. In this system, what I verify is not the identity of a
person; instead, it's the owner of an email address. When I send to an
email address with some secret and get the reply, then I know that I've
been in contact with the owner of the email. I don't care about the real
name of the person who owns the email, or I don't care if it's a shared
email used by several people. All I care about is that I've been in
contact with the email address. The security of organizational email
system starts from here. If you're interested in this concept and trying
out this system, I'll be happy to introduce you more, but it's off topic
to this thread.

Thanks,

Lou


On 10/27/2016 01:52 PM, Martin T wrote:
> Hi,
>
> thanks for reply! Unfortunately, Alice and Bob cannot meet in person
> because of geographical distance. If they could, then this would
> definitely be the best way to exchange public keys. I further
> simplified my initial idea:
>
> Alice from company A asks Bob from company B to send her Bobs public
> key using an e-mail. Both Alice and Bob know each other e-mail
> addresses because they have been in contact before during a project
> which involves both company A and company B. Now when Alice receives
> Bobs public key, she will send hers in return to same e-mail address
> which she received the Bobs public key. Then she looks up the phone
> number of the customer support department of company B from company B
> official website and calls there and asks for Bob. Once she gets Bob
> on the phone, she asks Bob to tell the fingerprint of his public key
> and then Alice tells her public key fingerprint to Bob and asks Bob to
> confirm that it matches.
>
> I guess this provides reasonable security?
>
>
> thanks,
> Martin
>
>
> On Wed, Oct 26, 2016 at 11:51 PM, Daniel Kahn Gillmor
>  wrote:
>> Hi Martin--
>>
>> On Wed 2016-10-26 16:21:48 -0400, Martin T wrote:
>>
>>> let's say that Alice from company A and Bob from company B need to
>>> exchange some private data with each other. Alice and Bob need to
>>> encrypt data just that one time, they do not belong to web-of-trust,
>>> but both company A and company B websites are trusted by certification
>>> authority, secure and available only over TLS. This gives a first
>>> option where both Alice and Bob ask their IT departments to publish
>>> their public keys on the company website so Alice can get Bobs public
>>> key over TLS from company B website and the other way around. Or when
>>> for example website of company B is not trusted by CA, then Alice can
>>> pick up the phone, call the customer-support of the company B and ask
>>> for Bob and then ask Bob to send her an e-mail with a public key and
>>> verify the fingerprint of the public key over a phone? Are there
>>> better(easier to use or more secure) ways to ensure that GPG public
>>> key belongs to right person in business to business communication?
>> It depends on how much involvement you want the IT department to have.
>>
>> There are a few more options:
>>
>>  * if Alice and Bob can meet in person, they can give each other
>>business cards with their fingerprints on them.  If this is how Alice
>>finds Bob's e-mail address in the first place, this is a natural
>>place to exchange cryptographic details as well.
>>
>>  * the two companies could use WKD (web key directory), which is in its
>>infancy, but is at least supported by GnuPG 2.1.x.
>>
>>  * Alice and Bob could submit their keys to a third-party notary like
>>Symantec's PGP Global Directory (if such

Re: [Announce] Libgcrypt 1.7.5: secmem trouble

[Luis Ressel]

Hello,

since I've upgraded to libgcrypt 1.7.5, gpg emits the warning 'Warning:
using insecure memory!' (and hence refuses to run, since my config file
includes 'require-secmem').

Any hints for debugging this issue would the greatly appreciated.

Regards,
Luis Ressel

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

Re: Smartcards and tokens

[Andrew Gallagher]

> On 15 Dec 2016, at 19:24, Lou Wynn  wrote:
> 
> If the host machine is compromised, what's the purpose of doing encryption on 
> the SmartCard? Attackers don't need to know the key to get your plaint ext, 
> because it is on the host machine.

The difference is that if you use a smart card in a compromised host, the 
plaintext of particular messages may be compromised but the key itself remains 
secure. It also helps in the case of hardware loss or theft, because an 
encrypted drive can be brute forced, but smartcards have retry limits that 
can't be worked around short of dissecting the silicon. 

That's assuming it has been sufficiently hardened against side channel attacks, 
of course. And if you leave the smart card in the machine with an insufficient 
pass phrase timeout, the attacker could feed an arbitrary number of messages 
through it without you knowing. So it's no panacea.

Andrew

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

Re: Smartcards and tokens

[NIIBE Yutaka]

sivmu  writes:
> it seems using those specific devices actually decreases
> security, assuming it is easy to manipulate specialised vendors of
> security hardware compared to manipulating electronic hardware in general.

Exactly, that's my point.  This is the reason why my approach of Gnuk
and NeuG tries to avoid specialized things.  Even, I avoid using crypto
accelerator, which (many of) experts say mandatory.

I think that an approach using commodity hardware makes sense.  My
theory is that if it's simpler and cheap enough, difficulty putting
backdoor would increase.  I don't know if this is true, but I considered
opposite must be likely; With enough space of silicon and enough
complexly in design, attackers can do something more.

> With nitrokey,  both the hardware design and the software is open source
> and both have been audited.

Is it audited?  I didn't know that.  For me, audit by an expert (or two)
is not enough.  It should be possible by anyone, or at least, by any
user who purchases it.  It's sad for me that Nitrokey is not easy to
open physically.  I mean, opening the device to examine the board.

> Bu I don't think that will keep some people from intercepting
> deliveries of such devices or mess with the production.

I don't know about the former, it depends on country.  For the latter,
it is real concern for me now.

I make the hardware design as simple as possible so that inspection by
human eye can be effective against replacing/adding chip.

Difficult part (for me) is to assure initial firmware flashing in
a factory.

In (most of) factory environment, proprietary operating system
dominates.  I'm not sure if this is the weakest link, but this could be
weaker point.  When an attacker replaces the firmware to be written,
it affects all devices to be shipped.

Perhaps, it would be good if an MCU has a feature of reporting hash of
its content of flash memory (even if flash is protected and it is not
possible to read out its content).  Then, an end user could examine
the hash code.

I think that the better current practice is: purchase commodity hardware
and flash at the user side.
-- 

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

Re: Smartcards and tokens

[sivmu]

Am 15.12.2016 um 22:17 schrieb Damien Goutte-Gattat:
> On 12/15/2016 08:35 PM, sivmu wrote:
>> From what I understand, a malicious token can e.g. perform encryption
>> operations with weak randomness to create some kind of backdoor that is
>> hard to detect.
> 
> The token is normally not used to perform any *encryption*. You encrypt
> with the public key of your correspondant, which is stored on your
> computer, not on your token (there's no need to protect it since it is a
> *public* key). You use your token to *decrypt* messages that were sent
> to you--and at that time, even if the token is malicious there's nothing
> it can do to mess with the encryption.
> 

I assumed the public key of the recipient is transferred to the token so
that it can do the encrytion internally. This is one of the things I
worry about. If the token does the encryption (and signing) operations,
it needs randomness. Something that is often messed with and hard to
produce reliably compared to a device with user interaction.



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

Re: Hybrid keysigning party, your opinion?

[Lachlan Gunn]

Le 2016-12-14 à 04:34, Peter Lebbing a écrit :
> Oh, not at all, I hadn't even noticed one could see it that way.

My bad; such is the life of the email-user.

> Or hang a truly huge printout on the wall and at the start of the
> session, together observe that it is correct. Any latecomers can be told
> "look, everybody thinks it's completely normal that we have a 64 digit
> hex code on the wall, and that's because we all agreed it's the right one".

Yes, with paper that would work.  I rejected it because I was imagining
a projector, which obviously could change the hash halfway through.

Thanks,
Lachlan




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

Re: [Announce] Libgcrypt 1.7.5: secmem trouble

[NIIBE Yutaka]

Luis Ressel  wrote:
> since I've upgraded to libgcrypt 1.7.5, gpg emits the warning 'Warning:
> using insecure memory!' (and hence refuses to run, since my config file
> includes 'require-secmem').
>
> Any hints for debugging this issue would the greatly appreciated.

I think that you need to debug libgcrypt to locate the bug.  If you are
familiar with GDB, run gpg under GDB with a break point at main, and
then a break point at lock_pool_pages.

Well, please show us the information in which architecuture/OS you runs
GnuPG.  Are you using GnuPG 2.1.x or another version?

I'm afraid you are using libgcrypt 1.7.4.  In version 1.7.4, there was
a bug in configure script, which might cause such a trouble.
-- 

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