Add key to card without substituting stubs for actual private key?

[Pete Stephenson via Gnupg-users]

Hi all,

Background:
I have an offline system I use for holding my private keys on-disk. I use 
smartcards for my day-to-day use on ordinary systems. I use the offline system 
to generate new primary keys when needed, as well as encryption subkeys (so I 
can always go back and decrypt things even if the smartcards are lost), and 
then transfer keys to smartcards using the "keytocard" command under gpg 
--edit-key . Signing subkeys are generated directly on the smartcards.

Issue:
Whenever I use keytocard, the selected private key is transferred to the 
smartcard as expected. The selected private key on the offline system is 
replaced with a stub pointing to that card (also as expected). In my use case, 
this is undesirable since I wish for the offline system to retain the actual 
private key after copying the private key to the card.

As a workaround, I've taken to making a backup of the .gnupg directory, 
performing the keytocard operation, then deleting the .gnupg directory that now 
contains the stubs and restoring the backup from before the operation. While 
functional, this is potentially error-prone.

Question:
Is it possible to transfer an existing private key from a computer to a 
smartcard without replacing the private key on the computer with a stub 
pointing to the card?

Request:
If it is not currently possible to do this, I request that such a feature (e.g. 
"copykeytocard" rather than "keytocard") be added when convenient.

Thanks!

Cheers!
-Pete

-- 
Pete Stephenson

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

Re: Comparison of RSA vs elliptical keys

[Pete Stephenson via Gnupg-users]

On Mon, May 11, 2020, at 5:15 PM, Mark wrote:
> I'm trying to understand the differences in strength between an RSA key
> and an elliptical one such ed25519 with cv25519. I know with RSA it is
> pretty easy to "gauge" the strength 1024 vs 2048 vs 4096. 
> 
> I could not really find anything to say how strong these elliptical keys
> are and how they compare to RSA ones. 

Good question! Broadly, and with several assumptions, elliptic curves have the 
same security level as symmetric (e.g., AES) keys that are half the elliptic 
key's length. See https://en.m.wikipedia.org/wiki/Key_size and the references 
therein as a starting point. 

For example, a 256 bit elliptic curve key has a similar strength to a symmetric 
key of 128 bits.

Due to various reasons, not all ECC keys are powers of 2 in length. For 
example, NIST P-521 is 521 bits long rather than 512 bits, and has equivalent 
security to a 256 bit symmetric key. 

Cheers! 
-Pete

-- 
Pete Stephenson

___
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

Re: Working with an Online and Offline Computer when using GnuPG - Best Practice?

[Pete Stephenson]

On Tue, Oct 10, 2017, at 05:39 PM, Whitey wrote:
> Pete Stephenson wrote:
> > On Mon, Oct 9, 2017, at 06:53 PM, Stefan Claas wrote:
> >> I read once here on the Mailing List that one should only use
> >> trusted USB devices, whatever that means, when using an USB
> >> device.
> > 
> > If you must use USB devices for some reason, take a look at the
> > <https://www.kanguru.com/storage-accessories/kanguru-flashtrust-secure-firmware.shtml>
> > flash drive.
> > 
> > It's designed specifically to protect against "badUSB", where the
> > controller and firmware can be compromised. The controller has the
> > developer's public key baked in during manufacture. The firmware is
> > signed and can only be loaded once (no provision is made for
> > in-the-field firmware updates). The controller verifies the firmware and
> > its signature at every power-on. If a malicious actor had physical
> > access and re-flashed the firmware, the controller would notice and fail
> > to load.
> > 
> > It also has a physical write-protect switch that can prevent unwanted
> > writes.
> 
> Since a flash drive is a read/write device, when would writes be
> unwanted?  When should I use this?

Vague answer: that depends on your threat model.

When interacting with an untrusted system, you may not want the
untrusted system to be able to write data to the USB drive that might
also be used on the trusted system. In my use case, I was more
interested in the novelty and principle of having a signed, verified
firmware running on the device that is not vulnerable to the badUSB
attack. The write protect switch is actually a bit of a hassle for me,
as the screen printing indicating which position is read-only has worn
off with use, so I always accidentally set it to read-only when I want
it in read/write mode (in much the same way that all USB plugs exist in
a superposition of multiple states, all aligned the wrong way). :)

-- 
Pete Stephenson

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

Re: Working with an Online and Offline Computer when using GnuPG - Best Practice?

[Pete Stephenson]

On Mon, Oct 9, 2017, at 06:53 PM, Stefan Claas wrote:
> I read once here on the Mailing List that one should only use
> trusted USB devices, whatever that means, when using an USB
> device.

If you must use USB devices for some reason, take a look at the
<https://www.kanguru.com/storage-accessories/kanguru-flashtrust-secure-firmware.shtml>
flash drive.

It's designed specifically to protect against "badUSB", where the
controller and firmware can be compromised. The controller has the
developer's public key baked in during manufacture. The firmware is
signed and can only be loaded once (no provision is made for
in-the-field firmware updates). The controller verifies the firmware and
its signature at every power-on. If a malicious actor had physical
access and re-flashed the firmware, the controller would notice and fail
to load.

It also has a physical write-protect switch that can prevent unwanted
writes.

It's a plain flash drive and doesn't have built-in encryption (though
the company sells those too) but it should have a higher assurance of
not being compromised or compromisable at the hardware level than a
typical off-the-shelf USB device.

I use it with my offline Raspberry Pi 2 that I use for private key
operations for my primary keys (as opposed to subkeys, which are on
smartcards). The Pi 2 uses LUKS for encrypting the microSD card it uses
for storage and is never connected to the network. It's more than
adequate in terms of performance and is cheap enough that I have a bunch
lying around the house anyway. ;)

Cheers!
-Pete

-- 
Pete Stephenson

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

Technical contact for mailing list?

[Pete Stephenson]

Hi all,

Who is the appropriate person to contact regarding technical issues with
the mailing list?

Specifically, it appears that the list doesn't play nice with anti-spam
measures like DMARC, SPF, and DKIM and so messages sent from domains
with restrictive DMARC and SPF rules get flagged as spam as mail servers
think the mailing list server is forging messages for those domains.

I'd be happy to provide more information but don't want to needlessly
add noise to the list.

Cheers!
-Pete

-- 
Pete Stephenson

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

Re: Creating Unique Fingerprint

[Pete Stephenson]

It's not as hard as you might think, at least in terms of 32-bit
fingerprints: https://evil32.com/
--
Pete Stephenson


On Mon, Jun 19, 2017, at 08:00 AM, Lou Wynn wrote:
> According to my understanding of crypto theory, your only way is to
> generate keys and compare their fingerprints and with the value you
> want. I would be surprised that you can find one in your lifetime. Or
> it'd be a breakthrough in cryptography if you managed to do it
> somehow.


> Thanks, Lou
>> On 06/18/2017 07:23 PM, Long Si wrote:
>> Hi  I am on Linux, and would like to generate a key with "unique 40"
>> fingerprint.  eg 1: Starts with ABCD  ...   eg 2: Starts with
>> AXXX  ... XXXA ends with A  eg 3:  ...  without any '0'
>> character at all  How would I go about writing such a script? Don't
>> mind running for months to get these sets.  Regards
>> ___ 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: Paper backup of all keys

[Pete Stephenson]

On Feb 4, 2017 04:33, "Daniel Kahn Gillmor"  wrote:

On Fri 2017-02-03 18:28:03 -0500, MyCraigs List wrote:
> Also, let's say the key associated with the email address (not a paper
> backup) gets corrupted or I delete it or render the key unuseable- can
> the paper backup of the key be used to type the key back in?

Sure, but it would likely be a pain to type the whole thing in.

You might be interested in the "paperkey" tool, written by David Shaw,
which does a good job at minimizing the typing you'll need to do
(assuming that all of the public parts of the certificate itself can be
recovered from the keyservers or your correspondents).

If you use debian or a debian derivative, just use "apt install


Maybe I'm doing something wrong, but paperkey only seems to produce
reasonably small output for DSA keys. RSA keys are still enormous.

I've had pretty good luck with something like Paperback:
http://www.ollydbg.de/Paperbak/index.html -- it backs up arbitrary data to
printable 2D barcodes with error correction. Simply scan the paperback
it'll reconstruct the original file.

Thus one can direct backup and restore the exported private key file
without too much trouble.

I thought there was a *nix version, but I may be in error.

Alternatively, one could have a shell script generate a QR code for each
line of the exported private key file, then print the resulting files 10 to
a page. I did this and, while annoying, it's not hideously inconvenient to
restore the QR codes using nothing more than a webcam.

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

Re: Unsubscribe me please

[Pete Stephenson]

Hi Lynda,

Unfortunately, that's not how it works. Essentially all of us are just
users and can't unsubscribe you. Instead, your message was sent to the
entire mailing list.

Thankfully, the self-service process is straightforward: if you wish to
unsubscribe, just click the link at the bottom of every message sent to the
list and follow the directions to unsubscribe.

Cheers!
-Pete

On Aug 24, 2016 18:51, "lynda.har...@sympatico.ca" <
lynda.har...@sympatico.ca> wrote:

> I have contacted you several times to unsubscribe me please.
>
>
>
>   
> *Lynda Harlos*
> Home based travel agent
>
> Orion Travelinx
>
> Home office: 905-433-4267
>
> Text: 905-723-9210
>
> www.facebook.com/TravelAgent.LyndaHarlos
>
>
>
> Referrals are the best compliment!
>
> Any price/s quoted not guaranteed until payment is made
>
> To unsubscribe please reply with unsubscribe in subject line
> *---Original Message---*
>
> *From:* martin 
> *Date:* 8/24/2016 12:32:12 PM
> *To:* gnupg-users@gnupg.org
> *Subject:* Re: Attacks on encrypted communicxatiopn rising in Europe
>
> On 24/08/16 15:37, Robert J. Hansen wrote:
> > I find the current state of detente to be pretty good, actually.  We're
> > allowed to design the best systems we can, and governments are allowed
> > to discover where we're not as clever as we think we are.  If there's a
> > flaw in Tor and the FBI uses it to pierce anonymity and go after a bad
> > guy, I can get behind that.  Way to go, FBI, you did it right, now
> > please hold on while we figure out how you did this and write a patch to
> > keep you from doing it again.
> >
> > I guess you could say my preferred solution to the crypto wars is to
> > encourage an ongoing escalating crypto arms race.  It's crazy, but it
> > seems to work.
>
> For my €0.02 I think the above is mostly valid bar 2 small details:
>
> 1. Seldom we do find the FBI breaking security of anonymity tools. Only
> if a high profile case shows up or someone leaks it. I think it is even
> more rare for the FBI to outright disclose the vulnerability they used
> so it can be patched. I don't even know if the other 3 letter agencies
> do it.
>
> 2. Crypto arms race also implies stock piling vulnerabilities -
> something Bruce Schneier is very vocal about [1][2]. I think the answer
> here is to find a balance of some sort - i.e. keep vulnerabilities in
> rare cases for short periods of time and then disclose and patch them.
> However for that to work we need to trust the govt. to do the right
> thing. Which I think is pretty much the core issue that started this
> discussion.
>
> Regards,
> Martin
>
> [1] Hacking Team, Computer Vulnerabilities, and the NSA -
> https://www.schneier.com/blog/archives/2015/09/hacking_team_co.html
> [2] Disclosing vs. Hoarding Vulnerabilities -
> https://www.schneier.com/blog/archives/2014/05/disclosing_vs_h.html
>
>
> 
>
> ___
> 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: Installing gnupg

[Pete Stephenson]

On Jun 9, 2016 09:15, "Alex Franklin"  wrote:
>
> Hi
>
> I don't know how to install the pgp software. I have downloaded the
tarball and signature from the website. I have OSX El Capitan. I have
terminal open but it is not clear as to what I need to do, what I need to
type in to Terminal.
>
> Please help?

Hi Alex,

The tarball is for if you want to compile GnuPG from source. This is
probably not what you want to do.

The GPGtools project has a nice, easy-to-use installer for GPG on OS X.
Their site is at https://gpgtools.org

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

Re: Installing gnupg

[Pete Stephenson]

On Jun 9, 2016 09:15, "Alex Franklin"  wrote:
>
> Hi
>
> I don't know how to install the pgp software. I have downloaded the
tarball and signature from the website. I have OSX El Capitan. I have
terminal open but it is not clear as to what I need to do, what I need to
type in to Terminal.
>
> Please help?

Hi Alex,

The tarball is for if you want to compile GnuPG from source. This is
probably not what you want to do.

The GPGtools project has a nice, easy-to-use installer for GPG on OS X.
Their site is at https://gpgtools.org

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

Re: managing OpenPGP cards in batch mode?

[Pete Stephenson]

On Thu, May 5, 2016 at 12:14 AM, Robert J. Hansen <r...@sixdemonbag.org> wrote:
> Dashamir, this list has very few rules.  I'm grateful for that, really.
> One of the few rules that must be obeyed, though, is "we will not
> advocate non-libre software or products here".

Out of curiosity, where are these rules defined?

The list information page
<https://lists.gnupg.org/mailman/listinfo/gnupg-users> doesn't make
any mention of such a rule.

Certainly, there are basic rules of netiquette that should ideally be
universally known and followed (don't send spam, don't flame people,
etc.), but "don't advocate non-libre software or products" isn't one
of them. I understand wanting to keep discussions related to GnuPG and
related subjects, so advocating or discussing third-party services may
be considered off-topic, but you seem to be referring to a more
specific rule.

Cheers!
-Pete

-- 
Pete Stephenson

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

Re: All mails identified as spams by Google

[Pete Stephenson]

On Mar 25, 2016 12:21 PM, "Guan Xin"  wrote:
>
> Hi All,
>
> All mails from gnupg-users are identified as spams by gmail since
yesterday. Google says that the mailing list "is in violation of Google's
recommended email sender guidelines".
>
> Why does it happen? This is the first time that I see 100% false positive
of the gmail spam filter.

I've observed the sane thing here on a Google Apps-hosted mail service

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

Re: Can the NSA Crack GnuPG

[Pete Stephenson]

On 2/23/2016 9:00 AM, Mercury Rising wrote:
> I saw his old disturbing post at:
> 

That post is a joke. It even says so.

> I am having a hard time believing it, but if Zimmerman did put in a
> backdoor code in PGP and GnuPG is based on that, wouldn't it be compromised?

If that happened, yes. So far, there's no credible, publicly available
evidence that this has occurred.

GnuPG is based on an open standard (RFC 4880) that is available for your
perusal at https://tools.ietf.org/html/rfc4880

Both the RFC and the GnuPG source code is publicly available. It's
unlikely (though not impossible) that an intentional backdoor exists,
particularly a backdoor that has been inserted undetected not only into
the PGP/GnuPG code, but also into the code of every compiler (including
new ones like LLVM) made in the last 24 years.

If one were particularly concerned, it's possible (albeit costly and
time-consuming) to write one's own disassembler and then disassemble the
compiled code and examine the assembly language for backdoors.

> I went to an EFF meeting in San Francisco and this big guy came up to
> me and said he had a program that would would break PGP. Then Elvis
> left the building fast so I could not follow him fast enough although
> I really tried. IMHO an agent of the Illuminati or its branch arm,
> the NSA.

People come in all shapes and sizes, can enter or leave public venues as
they please, move at whatever speeds they wish, and can say whatever
they want. That doesn't make this big guy's statement true, nor does it
imply membership in particular organizations, shadowy or otherwise.

If the NSA (or some other shadowy organization) could, in fact, break
PGP, why would they send someone to an EFF meeting in San Francisco,
have this person reveal this information to strangers, and then run
away? What purpose would that serve? If anything, I'd expect them to
keep such capabilities heavily guarded so they could use such a method
for intelligence-gathering.

> Cast doubts into the strength of 4096 or larger keys. I don't know
> how many prime numbers are possible between 2 bits (II binary =
> decimal 3) and 4096 bits = decimal a google maybe???)  are possible.

The Prime Number Theorem states that the number of prime numbers between
0 and x is:

x / ln(x)

The number of primes less than 2^4096 are thus:

(2^4096) / ln(2^4096)

which is about 1.84*10^1229.

That's a lot of numbers.

> Now multiply the two prime numbers of this size into a larger number
> then reverse factor and find the two originating prime numbers.

You say that one can "reverse factor" (which I interpret as "factor", as
"reverse factoring" is multiplication) as if it's something trivial.
It's not: as far as we know and barring any mathematical breakthrough,
factoring is hard (at least on classical computers).

If you can factor such enormous semiprimes in a reasonably efficient
way, there's a lot of people who would be interested.

> Now here's a question? If you had a chart showing every prime number
> multiplied by every other prime number couldn't there be a database for
> every multiplied larger number showing the possibilities of each of
> these prime number sets?

Short answer: Not in this universe.

Recall above how I mentioned that there's ~1.84*10^1229 prime numbers
less than 2^4096.

Even if we limit our search for numbers between 2^4096 and 2^4095, that
only reduces the search space by a factor of two. It's still enormous.

Considering there's only about 10^80 (~2^265.75) atoms in the visible
universe, you'd need to fit 2^(4096-265.75) = 1.05*10^1153 prime numbers
per atom in order to store a "chart" of all prime numbers less than 2^4096.

If you could do that you'd likely win multiple Nobel Prizes in different
disciplines. They'd probably have to invent new categories of Nobel
Prizes to award you.

> Some of these larger numbers may only have one pair of numbers that
> would work. AN ADVANCED Database program using array capabilities
> might help. How big would this data base be and how fast could it be
> searched?

Such a database would be unimaginably vaster than the universe.

Searching it would be all-surpassingly impractical. Leaving aside the
speed of light limitations of searching a database far (I've run out of
superlatives) larger than our universe, if you could get each atom in
the universe to output one of the 1.05*10^1153 prime numbers its storing
every Planck time (5.39*10^-44 seconds), it would still take 1.3*10^1092
times longer than the known age of our universe.

Current cosmological models suggest that the universe will reach its
heat death in about 10^100 years, so searching this database would take
~10^992 times longer than the heat death of the universe. How this would
take place is left as an exercise to the reader.

This doesn't consider the time needed to actually do any useful
computation using that data.

I suspect by the time that such a search was 

Re: backing up keys

[Pete Stephenson]

On 11/17/2015 1:39 PM, James wrote:
> All,
> 
> I'm new to GPG and am hoping to learn the ropes. Please forgive any
> ignorant questions.

No need to apologize: that's how we all learn.

> (a) are there any recommended methods by which to back up your private
> and public keys? I've seen some "paper" methods (paperkey) and some
> GitHub gists that have taken the private key, broken it in several
> pieces and used QR codes to back up. Which is better? Does it matter?

In addition to the security of your backups, one of your concerns should
be "How easily can I recover the key?"

If the procedure is complex, error-prone, and/or relies on the
availability of certain software that might not be available, it may be
less likely to work in the future.

Also, as Andrew says, what's your use case? Protecting your backed-up
private keys from you being forgetful or a destructive event like a
house fire or flood is different from protecting your keys from active
adversaries backed by force of law (e.g. feds with search warrants).

Using myself as an example, my two primary keys are each backed up to a
set containing:

1. Two CD-Rs from different manufacturers (for reliability).
2. Two USB flash drives from different manufacturers.
3. A Paperkey-produced printout.
4. A printout that consists of the ASCII-armored private key printed in
an OCR-friendly font. Additionally, each printout contains a QR code of
each line of the ASCII-armored private key so I can easily scan each
line without having to manually type everything in.

Obviously, recovering the key from #1 or #2 is the easiest, while #3 and
#4 are for last-resort recovery.

For my RSA primary key, I also keep a copy of the primary key on an
OpenPGP Smartcard which is kept with the set.

For each key, I make two such sets: one set stays at home in a locked
box, while the other is in a safe deposit box in a bank thousands of
miles away near my in-laws.

Additionally, I store printouts of revocation certs for those keys.
Since I have the private keys backed up, they shouldn't be necessary,
but you never know.

Overkill? Perhaps, but I've lost private keys in the past and it's a
pain. My main concerns are loss/destruction of the keys and electronic
compromise: thieves are more likely to care about my TV and shiny
computer rather than my PGP keys, and the authorities are unlikely to
care enough about me to seize the keys from my home or the bank vault
(even if they did get them, they'd need to crack the passphrase). Your
mileage may vary.

What if you can't recall the passphrase? You may have the encrypted
private key available from your backups, but if you don't have the
passphrase it won't do you much good.

Here's a few ideas for what you could do:
1. Split your passphrase up using something like Shamir's Secret Sharing
(a handy tool for accomplishing this is
http://point-at-infinity.org//) -- you can keep some shares for
yourself and give others to friends for safekeeping.

Shamir's Secret Sharing allows you to set a threshold for the number of
shares needed to recover the secret. For example, you could generate ten
shares and require three to recover the passphrase. You keep three
shares for yourself (so you can recover the passphrase any time you
want) and give seven to friends. If your house burns down and you lose
your shares, you'd just need to ask any three of those friends to give
you their share and you're good to go.

Any adversary that has fewer shares than the threshold (e.g. if they
only have two shares) gains no insight into your passphrase, which is
useful for security.

2. Print out your passphrase and store it with the backup set. While
handy, this has the disadvantage of also revealing your passphrase to
anyone who has access to the backup set (e.g. a thief), though at that
point you probably have bigger problems like bad guys breaking into a
bank vault or your home.

3. Backup the private key with no passphrase. This is the easiest, but
also the most risky: anyone who gets your key is able to use it without
needing the passphrase.

> (b) is your public key embedded in your private key? If you're not
> actually uploading your private key to a keyserver (perhaps using the
> key to secure data / files instead of email, thus no need for
> keyserver), is it sufficient to back up the private key only, or
> _must_ I back up both files?

For clarity, the private key is *never* sent to a keyserver, only the
public key.

The private key and public key are mathematically related: if you have
the private key, GnuPG can automatically generate the public key. The
reverse, of course, is not true.

Put a different way, it can be handy to backup the public key, but it's
by no means necessary.

> (c) Isn't the private key itself encrypted via AES256 when secured
> with a passphrase? If so, assuming the passphrase is secure enough,
> isn't it sufficient to upload this file to Dropbox, etc. for safe
> keeping? Would appreciate both real-world and theoretical 

Re: best practices for creating keys

[Pete Stephenson]

On 11/17/2015 1:32 PM, James wrote:
> All,
> 
> I'm just dipping my toes into GPG and am making a significant effort
> to "do things right" out of the gate.

Welcome!

> Based on my research, it is my understanding that "best practices"
> dictate we should have one master key with subkeys for specific
> purposes (personal work, "work" work, etc.). The master key is kept on
> an "offline" computer and then used only to revoke particular subkeys
> if needed.
> 
> Is this accurate?

At the risk of being vague, "best practices" depend on your situation.

The recommendations for someone wishing to exchange private love letters
with their spouse is far different than someone who would be subject to
physical harm, torture, etc. if the content of their messages were
revealed, or if an adversary were able to spoof messages appearing to
come from that person.

That said, using encryption and signing subkeys for day-to-day
operations and keeping your primary key safely stored and backed-up
offline is a reasonable and sensible thing to do in nearly all
circumstances.

> Below is an article that seems to discuss precisely this subject. It's
> a bit dated (2013), so am looking for clarification on whether or not
> this is the _best_ way to deal with GPG, key pairs, etc.
> 
> https://alexcabal.com/creating-the-perfect-gpg-keypair/
> 
> I've seen a few other StackOverflow questions about this matter and
> they all seem to recommend the same thing: create one master key, a
> subkey (or more than one) and use those instead of the master key for
> signing as needed.

Yes, this is a reasonable thing to do.

> I'm particularly confused regarding the lexicon used in the article
> above, mostly because of my ignorance (as the article is rather
> clearly written). The author indicates that:
> 
> - we create a keypair
> - added signing subkey
> - exported complete keypair _to TWO files_ (along with a revocation 
> certificate)
> - removed original signing subkey and stash that away safely (in a
> safe, offline)
> 
> My questions (and please forgive my ignorance):
> (a) when you create a the original keypair and export, it exports to
> _two_ files; how then, after adding another signing subkey, does the
> export also result in two files? Are both signing subkey keys
> (original and additional) embedded in your private key when exported?

The two files consist of, respectively, the (a) private and (b) public
components of that keypair.

In the directions provided at the link you mentioned, one creates the
primary key (which consists of the primary signing key and an encryption
subkey) and later creates a second signing subkey.

This bundle of three (sub)keys is exported for offline storage and
backup. There are separate exported files for the private components and
public components.

Later, the primary signing key is removed from the online system and
only the subkeys remain. If one later wished to backup this subkey-only
set of keys, they would be able to export the public components of all
three keys but only the private component to the subkeys. The private
component of the primary key would not be available for export since it
only exists in offline storage.

> (b) is this all really necessary? Aren't your private keys, when
> secured via a password, encrypted via AES256? If you have a super
> secure password / passphrase, is this all really necessary?

Yes, your private keys are encrypted and protected with your password.

However, this does little good if an adversary is able to compromise
your computer, copy the encrypted keyfile, and install a keylogger so
they know what password to use to decrypt it.

For typical users, this may not be an issue, but you never know.

In the case where a subkey is compromised, it can be easily revoked and
a new one generated.

In the case where one's primary key is compromised, it would also need
to be revoked and a new one generated, but it also means that one would
need to start from scratch to verify their identity to correspondents
and gain signatures from others -- the primary key represents one's
identity and reputation, so to speak, and rebuilding that can be
time-consuming and tedious.

Far better to take a few extra minutes generating a signing subkey and
moving the primary key to offline storage than dealing with the headache
of re-bootstrapping a new primary key.

> (b2) can someone please explain what sort of situation would be
> necessary for a private key that's been secured via a password is
> actually compromised? Are we talking about keyloggers, etc. here?
> Brute force? etc.

Assuming one has a strong password, brute force should be infeasible.

Keyloggers are a definite risk.

> (c) if your "laptop keypair" (terminology from article above) is
> compromised, data encrypted against that subkey will be compromised as
> well, correct? The only benefit to creating subkeys is that you can
> then revoke the subkey using your original signing key and let the
> world know that 

Re: failed decryption

[Pete Stephenson]

On Sun, Apr 19, 2015 at 11:21 AM, Mick Crane mick.cr...@gmail.com wrote:


 On 19 Apr 2015, at 06:42, Adam Gold a...@gmx.com wrote:

 I'm attempting to decrypt a symmetrically encrypted tarball appx 25GB in
 size.  It goes as follows:

 gpg [file].tar.bz2.gpg
 gpg: AES256 encrypted data
 gpg: encrypted with 1 passphrase
 gpg: packet(7) with unknown version 41
 gpg: WARNING: encrypted message has been manipulated!
 gpg: packet(5) with unknown version 241


 The problem with encrypting files for storage seems to be that if there is 
 any corruption there is no way to get any of it back.

In such cases it might be worthwhile to use some sort of
error-detection/correction system. Detecting errors is relatively
straightforward (you can sign a message and if the signature fails,
it's been modified) but correction is slightly more complex.

I generate PAR2 error-correction files[1] for important files or
archives. It allows one to detect errors and repair/recover any
damaged or lost sections up to a user-defined threshold. It uses more
disk space, but it can be a life-saver when dealing with critical
files on unreliable storage (and all storage is unreliable).

Alas, it's not retroactive and can't repair already-damaged data: you
need to generate the PAR2 files when the original file is still
undamaged and can then use it to recover damaged data later. In the
case of sensitive data, one should encrypt the data first and then
generate the PAR2 files -- that way no information about the encrypted
content can leak.

Cheers!
-Pete

[1] https://en.wikipedia.org/wiki/Parchive

-- 
Pete Stephenson

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

Re: upgrading v1 to v2

[Pete Stephenson]

On Mar 26, 2015 4:47 AM, Dave Kimble dave.kim...@riseup.net wrote:

 Ubuntu 14.04 with gnupg 1.4.16 installed from Ubuntu repository.
 Enigmail says it is about time I upgraded to gnupg v2.
 Ubuntu Software Centre says I have the latest version.

 I have git cloned gnupg ?v2.0.26? and attempted to configure.

Any particular reason you want GnuPG 2.0.x instead of 2.1? There's very
little difference for most users between 1.x and 2.0.x.

2.1.x adds ECC support, which is nice, but there aren't any packages yet
for it in Ubuntu.

Since you're on Ubuntu you could just run sudo apt-get install gnupg2 and
GnuPG 2.0.x would be installed alongside 1.x. Although it wouldn't show the
latest version number it'd still have all the security updates backported.

 Obviously I am doing something wrong, so its my fault, but this is
 ABSOLUTELY HOPELESS if you want people to adopt gnupg.  I work with
 clients who don't know what an email client is, let alone what theirs is
 called, on a wide variety of OSs.  They cannot possibly do this all
 this.  Is it too much to ask that you produce an Ubuntu-friendly
 repository that takes care of all the dependencies and compiling?

Compiling from source is not for the faint of heart. Fortunately, the
gnupg2 package exists on Ubuntu and makes the installation easy.

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

Re: Defaults

[Pete Stephenson]

On 3/17/2015 8:44 PM, Robert J. Hansen wrote:
 Given that 2.1 introduces a lot of new capabilities (mostly with respect
 to ECC), I think now, early on in the 2.1 series, would be a good time
 to discuss changing the defaults for newly-generated certificates.
 
 In a nutshell:
 
   * Offer Brainpool-512 and RSA-3072 as options for
 newly-generated certificates

I mostly agree. However, I have a few minor points:

- Above RSA-2048, keys and signatures become quite large. DSA signatures
increase slightly, but are considerably smaller than RSA signatures.

As long as we're considering legacy algorithms like RSA and DSA, is
there any particular reason for preferring RSA over DSA at such key
lengths? I know that DSA is only defined up to DSA-3072, so those who
wish to use larger keys would need to use RSA or ECC, but why not use
DSA as the default?

Is Deterministic DSA only available in 2.1, or do 1.x and 2.0.x also
have that feature?

- The Brainpool curves are similar in structure to the NIST curves,
though their curve parameters are chosen in a clear, open manner. While
that leads to increased trust that the parameters aren't chosen for
nefarious purposes, if one is already making a major change to ECC, why
not use some other, more modern curve that's designed at a high-security
level?

Curve M-511 comes to mind, as it's similar to Curve25519 (which GnuPG
already implements).

See http://safecurves.cr.yp.to/ -- djb and Lange clearly lay out their
criteria for different curves and why they're categorized they way they
are. I'm nothing more than an interested amateur in this subject, but
why not benefit from their efforts?

   * Use AES256 for a symmetric cipher
   * Raise a warning if the user attempts to encrypt more
 than 4 GiB with an old (64-bit block) cipher

Agreed.

   * Only use CAST5 if the user explicitly requests it via
 default-cipher-preferences: prefer 3DES over CAST5

(Rationale)
   * CAST5 is not in good health: as was recently mentioned in
 the IETF WG mailing list, the Canadians themselves still
 allow it to be used for applications requiring 128 shannons
 of uncertainty... but not for secrets that need to be kept
 for more than a week.  That doesn't inspire much confidence
 in the long-term prospects of CAST5.

Do you have a link to this discussion on the IETF list? I suspect the
community here would be very interested.

   * Only use IDEA if the user explicitly requests it via
 default-cipher-preferences: prefer 3DES over IDEA

(Rationale)
   * Attacks on IDEA haven't been getting much better, but IDEA's
 been giving me the heebie-jeebies for about fifteen years
 now.  I'd *really* prefer it if we got rid of it altogether.
 Barring that, only allow it to be used by explicit command
 will work for me.

Is there something particular about IDEA that concerns you?

   * Use SHA256 for RSA-3072/-4096 signatures and SHA512
 for Brainpool-512

Agreed.

   * We've needed to make all these changes for years now.  I've
 always said we should defer on making big changes to the
 defaults until we had ECC in place for users to migrate to.
 Well, we've got ECC: let's start encouraging users to use it.
 And while we're at it, let's see about making these other
 overdue changes.

Alas, a lot of Linux distributions are quite slow-moving: it's unlikely
that distributions like Debian and Ubuntu will have GnuPG 2.1.x
available (let alone installed by default) for several years.

Yes, the changes should be made, but ECC support won't be widely
available to most users for some time.

Cheers!
-Pete

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

Re: Defaults

[Pete Stephenson]

On 3/17/2015 11:25 PM, Robert J. Hansen wrote:
 As long as we're considering legacy algorithms like RSA and DSA,
 is there any particular reason for preferring RSA over DSA at such
 key lengths?
 
 I have reasons to prefer RSA, yes, but whether they'll convince you is a
 different matter.  :)
 
 Where signature size matters most is in email.

[snip]

Agreed. It's always a bit tedious to see large in-line signatures with
short messages. PGP/MIME, as you say, alleviates this issue somewhat by
hiding the signature, but it also tends to be somewhat fragile when
mailing lists are involved...but that's a different story altogether.

 And although it genuinely pains me to say this, I can understand why
 some OpenPGP users mistrust DSA.  I don't mistrust it and I think people
 who do mistrust it are doing so erroneously, but I understand.  NIST's
 reputation has taken a pounding in the last few years.

Yeah. I'm skeptical of non-RFC6979 DSA simply because it can fail
catastrophically if insufficient entropy is not available when making a
signature. RSA only requires entropy when generating a new key, while
DSA needs it for key and signature generation.

If DSA uses RFC6979 I have no issues with it.

 - The Brainpool curves are similar in structure to the NIST curves, 
 though their curve parameters are chosen in a clear, open manner.
 While that leads to increased trust that the parameters aren't chosen
 for nefarious purposes, if one is already making a major change to
 ECC, why not use some other, more modern curve that's designed at a
 high-security level?
 
 Because at present GnuPG supports the following curves:
 
   * NIST
   o P-256
   o P-384
   o P-521
   * Brainpool
   o P-256
   o P-384
   o P-512
 
 I cannot in good conscience recommend changing the defaults to an
 algorithm not yet supported by GnuPG.  :)

*laughs* Indeed!

I hope that everyone understood my point to be Since GnuPG is already
making a major change by implementing ECC, it'd probably be a good idea
to Do Things Right The First Time(tm), implement strong curves, and make
them the default.

Of course, it'd be a good thing to work with developers of other
OpenPGP-compatible software to ensure that such algorithms would be
widely supported even though the standards don't yet include such
algorithms.

 Do you have a link to this discussion on the IETF list? I suspect
 the community here would be very interested.
 
 https://www.cse-cst.gc.ca/en/node/227/html/15164
 
 Looking over it again, it turns out the Canadians are distrustful of
 128-bit crypto *in general*.  None of them are approved for periods
 longer than seven days.

True, but that's not uncommon: OpenVPN in TLS mode renegotiates a new
session key ever hour by default. GnuPG generates new session keys with
each message. Are there any common cryptographic implementations that
would use the same symmetric key for long periods of time?

 Is there something particular about IDEA that concerns you?
 
 About fifteen years ago I learned about a miss-in-the-middle attack on
 IDEA that broke 4.5 of 8.5 rounds (by ... Biham, I think).  That made my
 eyebrows go up.  It wasn't a full break, but it sure as hell was
 interesting, and attacks only ever get better over time.  That was when
 IDEA started giving me the heebie-jeebies.
 
 Khovratovich presented a break against full (8.5-round) IDEA in 2012.
 This attack isn't huge -- it reduces 128 shannons of uncertainty to 126,
 more or less -- but, at the same time, it's freaking enormous.  From
 here on out, every improvement is going to reduce the effective strength
 of IDEA.  We're no longer playing games of trying to extend things to
 the full cipher: for the last three years we've been watching the full
 IDEA be subjected to real attacks.
 
 So far those attacks haven't been successful.  Like I said, a
 two-shannon reduction isn't much.
 
 But imagine what it's going to be like in another five years.

Interesting, thanks.

Cheers!
-Pete


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

Re: Defaults

[Pete Stephenson]

On 3/17/2015 11:25 PM, Kristian Fiskerstrand wrote:
 On 03/17/2015 10:58 PM, Pete Stephenson wrote:
 On 3/17/2015 8:44 PM, Robert J. Hansen wrote:
 
 ...
 
 Is Deterministic DSA only available in 2.1, or do 1.x and 2.0.x
 also have that feature?
 
 
 RFC6979 is used for gnupg 2.0 compiled with libgcrypt = 1.6.0

Excellent. That's exactly what I hoped to hear.

Cheers!
-Pete


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

Re: bugs.gnupg.org TLS certificate

[Pete Stephenson]

On Fri, Mar 13, 2015 at 12:21 AM, Hugo Osvaldo Barrera h...@barrera.io wrote:
 On 2015-03-11 17:38, Werner Koch wrote:
 On Wed, 11 Mar 2015 15:12, br...@minton.name said:

  git.gnupg.org) don't use that certificate.  Have you considered a wildcard
  certificate?  I know this has been discussed before, e.g. at

 Too expensive ;-).  To stop all these complaints I will add a so called
 real certificate but first I need to move the tracker to another
 machine.


 Shalom-Salam,

Werner

 No need for a wildcard one. Just get one free certificate for each subdomain
 from StartSSL.

StartSSL's a great choice, as one can issue as many certificates as
one wishes for validated domain names.

Alternatively, several CAs[1][2] offer free certificates to
open-source projects. Resellers[3][4] also offer quite
reasonably-priced ($9 USD/year) certs as a standard price.

Cheers!
-Pete
Full disclosure: I'm a paying customer of StartSSL, Gandi, and
NameCheap, and have several certificates from each for different
purposes. Other than being a customer, I have no other interest in
those organizations.

[1] https://www.godaddy.com/ssl/ssl-open-source.aspx
[2] https://www.globalsign.com/en/ssl/ssl-open-source/
[3] https://www.namecheap.com/security/ssl-certificates/domain-validation.aspx
[4] https://www.gandi.net/ssl/standard

-- 
Pete Stephenson

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

Re: AES-NI, symmetric key generation

[Pete Stephenson]

On 3/11/2015 6:55 PM, Maricel Gregoraschko wrote:
 Thank you Pete for clearing things up. Makes a lot of sense to store
 passphrase-to-key identification data, in addition to actual algorithm
 used, in the output message rather than have the decryptor just assume
 things.

Indeed. The folks who created the OpenPGP standard were quite
forward-thinking in regards to such things.

 I figured out how to use --show-session-key: in my tests it doesn't show
 the key when encrypting, only when decrypting, that's good enough, I'm
 ok with doing a test decryption just to show the key.

Ah, that was my mistake: I forgot to specify that --show-session-key
only works when decrypting a message. Considering the intended purpose
of that option (being compelled to turn over a key), I suppose that's a
reasonable limitation in when it can be used.

 One more question: Is there any standardization in output formats
 between encryption programs and libraries, for example say you encrypt
 with AES128 in CBC, with the same key (directly or via passphrase), and
 since the output will have to have, in addition to the actual
 ciphertext, algorithm indentification on it, possible pasphrase-to-key,
 plus mode-specific data such as the iv/nonce, is there a specification
 of the format of how these come in?

You'd have to ask Werner, the head developer, about that.

RFC 4880 completely specifies how the algorithms are implemented. In
theory, it should be possible to split a message into it's various
packets (gpgsplit is designed to do this), then decrypt the
symmetrically-encrypted packet using the method specified in the RFC,
but I have not attempted to do this.

Cheers!
-Pete

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

Re: AES-NI, symmetric key generation

[Pete Stephenson]

On 3/9/2015 6:15 PM, Maricel Gregoraschko wrote:
 Hello All,

Hi!

 2.  When using symmetric encryption and providing a passphrase, I
 understand the actual encryption key is generated on the spot, used to
 do the encryption, and then discarded from memory and not stored
 anywhere, is that correct?

Correct.

 If the user wanted, can they dump the encryption key to store it
 securely, and use it to decrypt, instead of the password?

Yes, but the security is only as strong as the weakest link: if one uses
a weak passphrase to encrypt a message, an adversary could guess the
password.

If one used a long random string as a passphrase, this is functionally
equivalent to a strong key, so why bother with using the key itself to
decrypt instead of the passphrase?

You can show the symmetric session key for a message using the
--show-session-key option.

Here's an example of text I encrypted with gpg --symmetric:
-BEGIN PGP MESSAGE-
Version: GnuPG v1

jA0EAwMCYFod0NxVEONgySM6oLcax81PoXTPKk2R+zdP2XZ+rA1ILbKy3+sg0xs8
B8SW2A==
=Iz40
-END PGP MESSAGE-

The passphrase is test (no quotes).

pete@kaylee:~$ gpg --show-session-key  example.txt
[prompt for password]
gpg: CAST5 encrypted data
gpg: gpg-agent is not available in this session
gpg: encrypted with 1 passphrase
gpg: session key: `3:62A2421F805F6CB1767A9DF07983ADDF'
gpg: example.txt: unknown suffix

Later, I can use gpg with the --override-session-key option to supply
the decryption key directly. Use gpg --override-session-key [session
key], using the format given above:

pete@kaylee:~$ gpg --override-session-key
3:62A2421F805F6CB1767A9DF07983ADDF  example.txt
gpg: CAST5 encrypted data
gpg: encrypted with 1 passphrase
Hello world!
gpg: WARNING: message was not integrity protected

See the manpage or https://www.gnupg.org/documentation/manpage.html for
more details.

One interesting note about show/override-session-key: if one is
compelled to decrypt a message (or else...), one can use those options
on messages encrypted using GnuPG's symmetric or the more usual
asymmetric (i.e., public key) encryption methods. The manpage says,
This option is normally not used but comes handy in case someone forces
you to reveal the content of an encrypted message; using this option you
can do this without handing out the secret key.

In other words, if you're compelled to decrypt a message that was
encrypted to your public key, you don't need to hand over your private
key (which would allow someone to decrypt all your messages, sign new
messages, etc.). Instead, you would just hand over the encrypted message
and the session key used to encrypt it. Since each message uses a new,
random session key, only that single message can be decrypted and your
private key is not compromised.

Cheers!
-Pete


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

Re: AES-NI, symmetric key generation

[Pete Stephenson]

On 3/10/2015 8:28 PM, Maricel Gregoraschko wrote:
 Pete,
 Very useful info about using --show-session-key to avoid revealing your
 private asymmetric key.

No worries.

 In your example (gpg --show-session-key  example.txt) , had you
 somehow set up gpg to use symmetric by default, rather than asymmetric +
 symmetric?

No. It was a nearly out of the box setup with only some minor changes
to my gpg.conf file in regards to accessing keyservers. Nothing that
would affect the modes of encryption.

 If I explicitly pass --symmetric, --show-session-key does nothing
 (gpg4win) (and I guess the key is not really a random session key as
 when sending a PGP message) but rather the key deterministically
 generated from the passphrase.

Works fine for me. Try copy-pasting the text into the command prompt
rather than reading from a file. Use Ctrl-Z then Enter to tell GnuPG
you're done entering a message and it should start processing things.

Here's an encrypted message I generated with gpg --symmetric --armor
on GPG4Win 2.2.3:

-BEGIN PGP MESSAGE-
Version: GnuPG v2

jA0EAwMC2lG4z3grm9G1ySTYXvITlKTun7NvaLnznJZI4AhGJyTk+rFkAdufNRzB
cC6eqAI=
=j73k
-END PGP MESSAGE-

(password is test with no quotes)

gpg --show-session-key yields a session key of
3:C4A5BBCBB7C8F846FCA3A9BDDED0EB7F.

The same message encrypted a few seconds later with the same password
yields:

-BEGIN PGP MESSAGE-
Version: GnuPG v2

jA0EAwMCgnIlCp86aLq1ySQt2veDYta5U1uxPiust4siTyduBe7+CVhupax2HKeI
Zcm3Rx0=
=kZPs
-END PGP MESSAGE-

and a session key of 3:A81A96428D44DEAD3A6079CC22145B51

It appears that GnuPG uses the iterated-and-salted secret-to-key method
(see https://tools.ietf.org/html/rfc4880#section-3.7.1.3 ) to generate
the session key.

You're right: the key is derived from a passphrase and so is not truly
random, but the salt is random which helps a bit. Of course, the salt is
not encrypted, so the message protection depends only on the strength of
your passphrase.

 I agree, using key instead of passphrase doesn't enhance security
 (assuming an attacker knows that the key was derived from a passphrase
 and with what key derivation algorithm? I assume the randomness/entropy
 of the key itself is high enough regardless of the passphrase strength?). 

The attacker would be able determine quite a bit of information about
how the message was encrypted (as this same information would be needed
by a legitimate user to decrypt the message):

Here's an excerpt from the double-verbose (-vv) output from the second
encrypted message above (all this is available without entering the
passphrase):

:symkey enc packet: version 4, cipher 3, s2k 3, hash 2
salt 8272250a9f3a68ba, count 2752512 (181)

The attacker would know the cipher being used (cipher 3 = CAST5), the
fact that the key is derived from a user-provided string (the fact that
s2k is used), which string-to-key algorithm is used (s2k 3 =
iterated-and-salted), the hash used (hash 2 = SHA-1), the salt, and the
number of times to iterate the S2K algorithm.

The attacker won't know the strength of your passphrase -- it could be
cat or a long string of random characters -- but it tells them that
the key was generated using user-provided input.

 The reason I was asking if it's a possibility to store the symmetric key
 to decrypt with later, was to protect against future changes in the key
 derivation algorithm, that would make gpg generate a different key for
 the same passphrase, useless to decrypt previously encrypted data.

GnuPG follows the OpenPGP standard (RFC 4880). The standard defines
certain key derivation algorithms and provides the ability to add new
ones if needed. Adding new key derivation algorithms in the future
should not have any affect on existing encrypted messages.

Since each message clearly identifies the algorithm used to encrypt it,
future versions of GnuPG should have no problem decrypting it. Indeed,
the current version of GnuPG is able to decrypt messages generated from
old (even ancient!) versions of PGP and GnuPG with few, if any, issues.

Cheers!
-Pete

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

Re: Help need to use truecryt + openpgp applet.

[Pete Stephenson]

On Fri, Feb 20, 2015 at 7:00 AM, Doug Barton dougb@dougbarton.email wrote:
 On 2/19/15 12:16 AM, Pete Stephenson wrote:

 Considering the way it was abandoned by its developers, TrueCrypt is
 probably not the best choice going forward.

 We don't know the whole story about what happened there, so I would be
 hesitant to attribute malice. For some of us who need to have the same data
 accessible on multiple platforms there is not a better option.

No malice implied. My apologies if I was unclear.

I just feel that using publicly-abandoned security software,
particularly when it hadn't been updated in the two years leading up
to its abandonment and used old, crufty build dependencies[1] that
hadn't been updated in decades, is probably unwise if one desires a
high degree of security.

Don't get me wrong: I really like TrueCrypt and think it was a great
cross-platform disk encryption program that was remarkably easy to
use, but using it as a part of new projects probably isn't a good
idea.

Cheers!
-Pete

[1] https://madiba.encs.concordia.ca/~x_decarn/truecrypt-binaries-analysis/

-- 
Pete Stephenson

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

Re: Help need to use truecryt + openpgp applet.

[Pete Stephenson]

On Thu, Feb 19, 2015 at 5:53 AM, Ranjini H.K ranjin...@tyfone.com wrote:
 Hi all,

 Am trying to implement disk encryption/decryption using truecrypt with
 security token support. I have a java card with openPGP applet loaded on to
 it. Inspite of configuring truecrypt to use the security token, its not
 finding it and notififng me with an error saying : security token error
 FUNCTION NOT SUPPORTED .

Considering the way it was abandoned by its developers, TrueCrypt is
probably not the best choice going forward.

That said, TrueCrypt only supports smartcards that use PKCS #11
libraries. Does the JavaCard you're using support PKCS #11? Does the
OpenPGP applet?

-- 
Pete Stephenson

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

Re: How to reset the PIN counter

[Pete Stephenson]

On Feb 7, 2015 6:42 PM, Rainer Keller m...@rainerkeller.de wrote:

 Hello,

 while trying to setup gpg smart card to be used for SSH authentication
the PIN
 retry counter reached 0.

 I tried several things using the admin PIN in order to reset the counter:
 1. unblock PIN
 2. change PIN
 3. Setting a Reset Code and using that afterwards
 4. Change admin PIN

 Unfortunately none of these works. If I now try to unblock PIN I get the
 error message Error unblocking the PIN: Conditions of use not satisfied.

 What is the official intended way to reset all PIN counters?

http://lists.gnupg.org/pipermail/gnupg-users/2013-March/046261.html should
have the info you need.

I save the reset code block to a text file (reset.txt) and then run 
gpg-connect-agent  reset.txt. Remove and reinsert the card and it should
be back to factory defaults.

It is worth pointing out that this completely nukes any keys on the card.

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

Re: How to reset the PIN counter

[Pete Stephenson]

On Feb 7, 2015 10:36 PM, Duplicity Mailing List 
duplicitymailingl...@mail.ru wrote:

 On 07/02/15 20:45, Rainer Keller wrote:
  I save the reset code block to a text file (reset.txt) and then run 
  gpg-connect-agent  reset.txt. Remove and reinsert the card and it
should
  be back to factory defaults.
  Unfortunatly this seemed to brick the card.
  gpg: OpenPGP card not available: Not supported
  Gnupg does not detect the card anymore.
 
  Regards,
  Rainer

 What version was your card? It should work fine on a 2.0 smart card,
 but, it's by design made to brick 1.X cards. Pete probably should have
 warned you about this first.

In retrospect I should have, but the output of gpg --card-edit Rainer
posted showed he was using a version 2 card so it should be ok. My
apologies for any confusion.
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Crypto device where I need to confirm every operation?

[Pete Stephenson]

On Thu, Jan 22, 2015 at 6:00 PM, Felix E. Klee felix.k...@inka.de wrote:
 I currently use GnuPG with an OpenPGP Card V2.0 in a smart card reader
 with PIN pad. Surely, that adds a certain layer of security, as all
 encryption and signing operations happen on the card. However, there
 is one attack which I think could be easily prevented: With the card
 in the reader, the PIN entered, and Eve having remote access to my
 machine, she could sign and decrypt documents.

You can always enable the forcesig option, which requires that the
PIN be entered for every signature operation (you can enable by
inserting the card and then running'gpg --card-edit', then entering
'toggle', 'admin', 'forcesig').

I'm not aware of any similar option in regards to decryption.

-- 
Pete Stephenson

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

Re: Thoughts on Keybase

[Pete Stephenson]

On Mon, Dec 29, 2014 at 2:47 PM, Aaron Toponce aaron.topo...@gmail.com wrote:
 On Mon, Dec 15, 2014 at 01:40:22PM -0500, Robert J. Hansen wrote:
 Keybase (https://keybase.io) is trying to solve the Web of Trust problem in
 a new way.  They're currently in beta, but I was able to snag an invitation.
 (I have no invites to give out, unfortunately.)

 FWIW, I have 3 invites. If you want to grab me off-list.

 https://keybase.io/atoponce

At present, I have 10 invites and would be happy to share them with
those who are interested. Please contact me off-list as well.

Cheers!
-Pete

-- 
Pete Stephenson

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

Re: Unable to encrypt file with private/public key

[Pete Stephenson]

On 12/19/2014 5:36 AM, Haritwal, Dhiraj wrote:
[snip]
 One more query, partner is saying they are unable to decrypt this
 file with my private key which they have trusted  asking to encrypt
 this file with my private key  their public key (already trusted on
 my server). when I am suing both the key identifier's, giving some
 syntax error. Kindly suggest how can I do this.

I think you mean that your partner is unable to decrypt the file with
your *public* (rather than your private) key, right?

If so, that's expected behavior: if you have encrypted a message to your
partner's public key, your partner needs to use their private key to
decrypt the message.

They can use your public key for verifying your signature on the
encrypted file.

Cheers!
-Pete

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

Re: Unable to encrypt file with private/public key

[Pete Stephenson]

On 12/19/2014 6:05 AM, Haritwal, Dhiraj wrote:
 One more thing, this time when I encrypt the file with my private key
 (without sign  only with armor switch), it's still asking passphrase
 to decrypt it even  on my same server. That means it's still using
 PassPhrase to encrypt the file. Does it somewhere set by default in
 the Gnupg config.

I assume that you mean that you encrypted the file using your own public
key.

If so, it's normal for GnuPG to prompt you for your passphrase when you
decrypt the file: the private key is needed to decrypt the file, and the
passphrase is used to unlock the private key so it can be used.

When you're using symmetric encryption mode, the passphrase is used to
encrypt and decrypt the file.

When used with public/private keys, the passphrase is not used at all to
encrypt the file. The file is encrypted using the recipient's *public*
key[1] and sent to the recipient. The recipient uses their passphrase to
unlock their *private* key, which is used to decrypt the file.

Public-key crypto is somewhat of a black art, and there's many aspects
that can be quite confusing. You might find the Art of the Problem
video series on cryptography[3] to be interesting.

Mozilla also has an introduction to cryptography[4] which might also
help clarify things. While it focuses on the use of cryptography in a
general web browser-server system, many of the concepts apply to GnuPG.

Cheers!
-Pete

[1] This is a somewhat simplified explanation. In actuality, the file is
encrypted using a randomly-generated session key and a symmetric cipher
like AES, and the session key is encrypted using the recipient's public
key. This hybrid cryptosystem[2] has several advantages over
encrypting the whole file using the recipient's public key.

[2] https://en.wikipedia.org/wiki/Hybrid_cryptosystem

[3] https://www.youtube.com/playlist?list=PLB4D701646DAF0817

[4]
https://developer.mozilla.org/en-US/docs/Introduction_to_Public-Key_Cryptography

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

Re: Mainkey with many subkeys??

[Pete Stephenson]

On Mon, Dec 8, 2014 at 10:12 AM, gnupgpacker gnupgpac...@on.yourweb.de wrote:
 Kristian,
 I am a little bit confused about your key design ;)

 Main key has options SC.
 There is an active newer signing key S, so this will be always used for
 signing?

My understanding is that if you have multiple signing subkeys on one
computer, GnuPG will use the most-recently-created signing subkey for
signing messages by default.

However, nothing stops you have from creating multiple signing subkeys
and distributing these to your different devices (e.g. SubkeyA for
your desktop, SubkeyB for your laptop, etc.).

Since all these signing subkeys are bound to your main key, signatures
generated by any of them are valid. Recipients who verify the
signatures do not need to be aware of the existence of other subkeys,
so long as the binding between the main key and the subkey used to
sign the message exists.

 And there are two active encryption keys E:
 GPG uses in my opinion only the key generated latest, isn't it?

Encryption subkeys are handled a bit differently. Typically GnuPG will
encrypt messages to the recipient's most-recently-created encryption
subkey. This makes per-device encryption subkeys a bit less practical.

 So how to desire which key is used?

You can specify a particular keyID by appending an exclamation point (
! ) after the key ID, fingerprint, etc.

See https://www.gnupg.org/documentation/manuals/gnupg/Specify-a-User-ID.html
for details.

As an example, I have a DSA main key with the ID 0xDA122186. When I
generated it I also generated an ElGamal encryption subkey. Later, I
generated RSA encryption and signing subkeys. If I sign a message,
GnuPG will use the RSA signing subkey by default. If someone encrypts
a message to me, they will encrypt a message to the RSA encryption
subkey (as it is newer than the ElGamal one).

If I wanted to force GnuPG to sign a message with my DSA main key
instead of the RSA subkey, I could use the command gpg --clearsign
--armor -u DA122186!. Similarly, if someone wanted to force a message
to be encrypted to my ElGamal subkey they could use gpg --encrypt
--armor -r 19DF6C14!

Cheers!
-Pete

 And what's about backward compatibility?

 Thanks for any hint, regards, Chris


 -Original Message-
 From: Gnupg-users [mailto:gnupg-users-boun...@gnupg.org] On Behalf Of
 Kristian Fiskerstrand
 Sent: Sunday, December 07, 2014 10:16 PM
 Tomo: you'll find that my key have a few subkeys at least due to these
 practises. It doesn't provide any issue for either keyservers or to
 use more generally, but you are correct in that the information is
 retained.


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



-- 
Pete Stephenson

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

Re: card is permanently locked!

[Pete Stephenson]

On Mon, Nov 17, 2014 at 5:08 PM, Damien Goutte-Gattat
dgouttegat...@incenp.org wrote:
[snip]
 With gpg-agent and scdaemon running, you should be able to do that with
 the following commands:

 $ gpg-connect-agent
 SCD APDU 00 e6 00 00
 SCD APDU 00 44 00 00
 /bye

 Disclaimer: I’ve never actually tried that, but that’s what I would do
 in such a case after reading the specs. I guess that with a “permanently
 blocked” card, one does not have much to lose…

I have, and it works fine (if fine is defined as completely erasing
the card and starting from factory-fresh settings) on version 2
cards. Version 1 cards will be bricked according to [1].

I use the strategy outlined at [1]:
1. Add the following lines to a text file called reset.txt, omitting
the equals signs:

==
/hex
scd serialno
scd apdu 00 20 00 81 08 40 40 40 40 40 40 40 40
scd apdu 00 20 00 81 08 40 40 40 40 40 40 40 40
scd apdu 00 20 00 81 08 40 40 40 40 40 40 40 40
scd apdu 00 20 00 81 08 40 40 40 40 40 40 40 40
scd apdu 00 20 00 83 08 40 40 40 40 40 40 40 40
scd apdu 00 20 00 83 08 40 40 40 40 40 40 40 40
scd apdu 00 20 00 83 08 40 40 40 40 40 40 40 40
scd apdu 00 20 00 83 08 40 40 40 40 40 40 40 40
scd apdu 00 e6 00 00
scd apdu 00 44 00 00
/echo card has been reset to factory defaults
=

2. Insert the smartcard to be reset.

3. Run gpg-connect-agent  reset.txt

4. Remove the smartcard.

5. Wait a few seconds, then reinsert the smartcard.

6. Run gpg --card-status: the card should show as factory fresh[2].

Cheers!
-Pete

[1] http://lists.gnupg.org/pipermail/gnupg-users/2009-September/037414.html
[2] Fresh scent of pine is optional.

-- 
Pete Stephenson

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

Re: Fermi estimates

[Pete Stephenson]

On Fri, Nov 14, 2014 at 10:25 AM, Johan Wevers joh...@vulcan.xs4all.nl wrote:
 On 14-11-2014 3:15, Robert J. Hansen wrote:

 10**38 attempts at 10**6 bitflips per attempt equals 10**44 bitflips
 total.  At carpet-scuffing power, that's about 10**15 joules of energy,
 [...]
 But to make our brute-forcer 10**30 times faster (so it
 can run in one year), our brute-forcer also has to release 10**30 times
 as much heat.

 I'm not an astrophysicist, but that's the kind of energy levels one
 normally associates with phrases like perturb the false vacuum and
 unmake the universe at the speed of light.  Look at the time, I must
 be going.

 Fortunately there's no false vacuum left to perturb. :-)

 Anyway, compared to the Sun's output of 3.82*10**26W that's still quite
 large.

 10 billion is 10**10,

 PLEASE don't do that in a FAQ. The definitions of bilion, biljard etc.
 differ wether one uses imperial or SI units, and thuis makes it very
 confusing. For me, a bilion is 10**12. It wouldn't be the first estimate
 that was off by some factors 10**6 due to mixing these up. Better to
 avoid those terms completely.

Minor nitpick: the difference between the long and short scales
are a bit more involved than just imperial vs. SI.

More details are at https://en.wikipedia.org/wiki/Long_and_short_scales

But yes, avoiding ambiguous words like billion is a good idea. Using
notation like 10^9, 10^12, etc. would make things more clear to
readers regardless of what words they use to describe those numbers.

Cheers!
-Pete

-- 
Pete Stephenson

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

Re: [Announce] The maybe final Beta for GnuPG 2.1

[Pete Stephenson]

On Fri, Oct 3, 2014 at 4:35 PM, Werner Koch w...@gnupg.org wrote:
 Hello!

 I just released another *beta* version of GnuPG *2.1*.  It has been
 released to give you the opportunity to check out new features and to
 help fixing bugs.

Hi all,

I had a few minor issues/questions with GnuPG 2.1 beta895 that I
thought would be good to report/ask here:

1. Default key prefs[1] don't seem to permit encrypting+signing a
message to a brainpoolP512r1 key. Evidently that curve requires SHA512
only for signatures, and all other algorithms will fail. Since SHA256
and SHA384 are prioritized over SHA512 by default in the key prefs, an
error occurs.

Here's an excerpt of the terminal output, where AF25682B is a primary
test key using brainpoolP512r1 while D74B165F is a test encryption
subkey using the same curve:

=
pete@kaylee:~/gpg/gnupg-2.1.0-beta895/PLAY/inst/bin$ ./gpg2 --homedir
~/gnupg/ --encrypt --armor --sign -r AF25682B
gpg: NOTE: THIS IS A DEVELOPMENT VERSION!
gpg: It is only intended for test purposes and should NOT be
gpg: used in a production environment or with production keys!
Hello world!
gpg: ECDSA key D74B165F requires a 512 bit or larger hash (hash is SHA256)
gpg: checking created signature failed: General error
gpg: signing failed: General error
-BEGIN PGP MESSAGE-
Version: GnuPG v2

hL4DWouX3RbM7L4SBAMEbW91unR/0/0QZ9fxeeIo9StkO2c90E9RQT9Cxy4yM7pI
dz3siYcAgzEtohdCcpy8BWCPRscqyUcD9iX/QDcxpj3CGG3RHJWdq8ezXVg2m460
ONeb1SnkQGxKsU7oDOo5lu6qQ+pAsvEqhKooyBxlIXPu/qqrtkx3DTvmCudld+Aw
od3AWiOPPQOSAzkRDSfk12/FhrWsZUz/q7mq0W/DlYem+B0OvOD+n1dcPDuAJAXR
gpg: [stdin]: sign+encrypt failed: General error
=

Is it normal/desired for 512-bit curves to only work with SHA512? If
so, shouldn't a newly-minted key have default prefs appropriate for
that key so it will work as expected?

If a 512-bit digest is required for a 512-bit ECC key, shouldn't the
signing system know that and be able to override the key prefs that
might specify a non-512-bit digest?

Similarly, brainpoolP512r1 curves seem unable to make a signature
using digest algorithms other than SHA512. For example, if a
brainpoolP512r1 key is encrypting+signing a message to another key
with the default prefs, it uses SHA512. Is this intended?

Signing/clearsigning a message with a brainpoolP512r1 curve also uses
SHA512, even if one tries to override it. In this example, I try to
override it by using SHA1 instead of SHA512:

pete@kaylee:~/gpg/gnupg-2.1.0-beta895/PLAY/inst/bin$ ./gpg2 --homedir
~/gnupg/ --armor --clearsign -u AF25682B --personal-digest-preferences
SHA1
gpg: NOTE: THIS IS A DEVELOPMENT VERSION!
gpg: It is only intended for test purposes and should NOT be
gpg: used in a production environment or with production keys!
Test.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Test.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iJ4EARMKAAYFAlRTekYACgkQRgJQM68laCuoDwH+KNKsSm01h6lJ659FDEGDoorM
/TpWvaVyVbvRa4+8Xya6+c73jt6jSDAeJZMEFBBQYIx3tJy7T6eowYgx3P2eUAIA
gvlSuuFVLqiV2Iujd0oa46PEnZZnxIz8Di6vUWqDq/WhhASDuQiidqc1zQ2VexP8
ET23riihBSBDTdTTR8Dp2Q==
=sUNG
-END PGP SIGNATURE-

2. While Curve25519-based keys can be used for signing using Ed25519,
there doesn't seem to be any way to use Curve25519 for encryption.
While one could use non-Curve25519 subkeys for encryption, that seems
a little sub-optimal. I assume this is known already and will be
resolved prior to the production release.

3. Curve25519 has a security level of 128-bits. In addition to the
Brainpool curves, are there any plans to add other curves with higher
security levels like Curve41417 (200-bits)? I ask simply because
having various components (e.g. the symmetric, asymmetric, and hash
algorithms) at similar security levels is logical: it wouldn't make
sense to, for example, use 1024-bit RSA with SHA512 due to the wide
difference in security levels, but using a 3072-bit RSA key with
SHA256 would be logical.

4. Are there any plans to add user-specified arbitrary curves in
addition to baked-in curves like the NIST, Brainpool, and Curve25519
curves? I realize that using arbitrary curves is something that is not
for the faint of heart, but having options is nice.

5. Why are so many key-generating options hidden behind the
--full-gen-key flag? The regular --gen-key flag makes a 2048-bit
RSA key, which is fine. I understand hiding the ECC options, as
support is not widespread, but why hide traditional algorithms like
DSA/ELG?

Cheers!
-Pete

[1] Cipher: AES256, AES192, AES, 3DES
 Digest: SHA256, SHA384, SHA512, SHA224, SHA1
 Compression: ZLIB, ZIP, Uncompressed
 Features: MDC, Keyserver no-modify

-- 
Pete Stephenson

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

Re: [Announce] The maybe final Beta for GnuPG 2.1

[Pete Stephenson]

On Sun, Oct 26, 2014 at 7:56 PM, Murphy mac3...@gmail.com wrote:
 Problem solved.  The error in finding the shared libraries was
 resolved with a single command after the successful speedo install
 using the INSTALL_PREFIX=/usr/local option on my ubuntu 14.04 machine:

 sudo ldconfig

My apologies for not responding earlier.

I used the same method, only I used sudo ldconfig
/path/to/PLAY/inst/lib/ rather than installing the beta to
/usr/local.

Cheers!
-Pete

-- 
Pete Stephenson

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

Re: smart card under linux

[Pete Stephenson]

On Tue, Oct 21, 2014 at 12:36 AM, Philip Jackson
philip.jack...@nordnet.fr wrote:
[snip]
 This looks promising but I didn't take it any further because I want to get it
 going under my UbuntuStudio 1404 linux. Using gnupg2 2.0.26.

 Trying to use the GnuPG driver to access CCID cards, gpg2 --card-status 
 yields
 the following output :

 gpg: selecting openpgp failed: Card error
 gpg: OpenPGP card not available: Card error


 I've followed, I believe, all the instructions in the gnupg.com smartcard 
 howto.
  In para 2.3.1 CCID : I've tried both the instructions under 'with udev
 (preferred installation)' and further down 'with hotplug (deprecated in modern
 systems)'

 In the /etc/udev/rules.d/ directory there is a README which says that symbolic
 links should not be used in Ubuntu (unlike Debian) so I placed a copy of
 gnupg-ccid.rules directly in that directory.  But that didn't help.

 lsusb shows that the SCM card reader is recognised and present but gpg doesn't
 seem to be able to make contact.

 I'd appreciate any ideas for what to try next.

What is the result of running the command:

echo $GPG_AGENT_INFO

Cheers!
-Pete

-- 
Pete Stephenson

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

Re: smart card under linux

[Pete Stephenson]

On Tue, Oct 21, 2014 at 2:50 PM, Philip Jackson
philip.jack...@nordnet.fr wrote:
 On 21/10/14 09:25, Pete Stephenson wrote:
 What is the result of running the command:

 echo $GPG_AGENT_INFO

 echo $GPG_AGENT_INFO
 /tmp/gpg-9S6s3F/S.gpg-agent:1611:1

Interesting, thanks.

In the past when I've had issues similar to yours it turns out to be
the Gnome Keyring's GPG agent causing trouble[1] since it doesn't
support smartcards. However, that doesn't seem to be the case with
your issue (if it was, the command would mention keyring rather than
gpg-agent).

Perhaps others have a better idea what's going on?

Cheers!
-Pete

[1] 
https://bugs.launchpad.net/ubuntu/+source/gnome-keyring/+bug/884856/comments/8

-- 
Pete Stephenson

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

Re: [Announce] The maybe final Beta for GnuPG 2.1

[Pete Stephenson]

On Wed, Oct 15, 2014 at 1:00 PM, Peter Lebbing pe...@digitalbrains.com wrote:
 On 04/10/14 00:28, Pete Stephenson wrote:
 To my untrained, non-developer[1] eye, there appears to be several
 things that failed though I'm not sure how to interpret things
 correctly. The full config log is ~250kB. I've posted it to a Pastebin
 at http://pastebin.com/xZjzsZju if that would help.

 Wow, that is one verbose log. I started reading from the top, but
 switched to reading from the bottom up, which is more useful for
 configure logs. I didn't expect it to be quite that long at first.

Indeed.

 Near the end, there's this bit:

 ---88---
 ***
 *** The Dirmngr part requires an LDAP library
 *** Check out
 ***http://www.openldap.org
 *** for a suitable implementation.
 ***
 configure:16877: error:
 ***
 *** Required libraries not found. Please consult the above messages
 *** and install them before running configure again.
 ***
 ---88---

 Note how it says to consult the above messages. You should not interpret
 this as all lines up to that bit, but rather the bits that immediately
 precede that final message.

 I don't see any other showstoppers. It is normal that a lot of tests
 fail. For instance, it's not really realistic to expect the file
 ac_nonexistent.h to exist; it's all just part of the tests.

 The format of the message above made me look for three consecutive stars
 in the output, which only turned up the one you mentioned:

Thanks!

Success! Installing the libldap2-dev package resolves the issue and
the build process completes with no other errors.

When I add PLAY/inst/bin/ to my path and PLAY/inst/lib/ to the list of
shared libraries, everything works as expected.

Many thanks for your help and patience.

Cheers!
-Pete

-- 
Pete Stephenson

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

Re: [Announce] The maybe final Beta for GnuPG 2.1

[Pete Stephenson]

On Fri, Oct 3, 2014 at 4:35 PM, Werner Koch w...@gnupg.org wrote:
 Hello!

 I just released another *beta* version of GnuPG *2.1*.  It has been
 released to give you the opportunity to check out new features and to
 help fixing bugs.

Excellent!

[snip]

 GnuPG requires a couple of extra libraries, which need to be build and
 installed before GnuPG.  The configure script will tell you about the
 requirements.

 You may try the Speedo system as an alternative build method:

   make -f build-aux/speedo.mk native INSTALL_PREFIX=/usr/local

When I run

make -f build-aux/speedo.mk native

it does quite a bit, but always seems to spit out the following errors
and fails to complete. The bit about gnutls is non-critical for me,
but it'd be nice to resolve it. The required libraries not found
error seems to be a showstopper, though.

I'm doing the build on a stock Ubuntu Server 14.04 32-bit system. I've
installed the build-essential package from the repo, so I have gcc,
make, etc.

configure: WARNING:
***
*** Building without NTBTLS and GNUTLS - no TLS access to keyservers.
***
*** No package 'gnutls' found
***
configure: error:
***
*** Required libraries not found. Please consult the above messages
*** and install them before running configure again.
***
make[1]: *** 
[/home/pete/gpg/gnupg-2.1.0-beta864/PLAY/stamps/stamp-gnupg-01-configure]
Error 1
make[1]: Leaving directory `/home/pete/gpg/gnupg-2.1.0-beta864'
make: *** [native] Error 2

Any ideas?

 Maintaining and improving GnuPG is costly.  For more than a decade,
 g10 Code GmbH, a German company owned and headed by GnuPG's principal
 author Werner Koch, is bearing the majority of these costs.  To help
 them carry on this work, they need your support.  See

   https://gnupg.org/donate/

Thanks for the reminder.

Cheers!
-Pete

-- 
Pete Stephenson

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

Re: [Announce] The maybe final Beta for GnuPG 2.1

[Pete Stephenson]

On Fri, Oct 3, 2014 at 6:39 PM, Werner Koch w...@gnupg.org wrote:
 On Fri,  3 Oct 2014 17:40, p...@heypete.com said:

 make -f build-aux/speedo.mk native

 it does quite a bit, but always seems to spit out the following errors
 and fails to complete. The bit about gnutls is non-critical for me,
 but it'd be nice to resolve it. The required libraries not found

 That is easy: Install the libgnutls-dev package.

Now I get Requested 'gnutls = 3.0' but version of GnuTLS is 2.12.23
-- again, this isn't a big deal. I'm just trying to do a test build,
and I'm not worried about TLS connectivity to keyservers.

That said, if I did want to compile the latest version of GnuTLS from
source, where should one place the compiled results so that the GnuPG
build process would know about it?

 error seems to be a showstopper, though.

 configure: error:
 ***
 *** Required libraries not found. Please consult the above messages
 *** and install them before running configure again.
 ***

 You should see other warning messages in the config log which tells you
 which library is missing.  You should find the full config long in
 PLAY/build/gnupg/config.log.  My guess is that there is some problem
 with libiconv which is expected to exist. It is usually part of glibc
 but you need to install the development package.

To my untrained, non-developer[1] eye, there appears to be several
things that failed though I'm not sure how to interpret things
correctly. The full config log is ~250kB. I've posted it to a Pastebin
at http://pastebin.com/xZjzsZju if that would help.

[1] I've written and compiled a few ad-hoc C programs for my research,
but I'm very much a beginner at this sort of thing. I apologize for my
lack of knowledge in this regard. Thank you (and others) for your
patience and help.

Cheers!
-Pete



-- 
Pete Stephenson

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

Re: NSA, PGP and RSA

[Pete Stephenson]

On Thu, Oct 2, 2014 at 3:09 AM, Robin Mathew Rajan
robinmathewra...@yahoo.com wrote:
 Hi everyone!

 I'm Robin Mathew Rajan from India and I'm a new member here. I'm also new to
 PGP cryptographic concepts. I've some experiences with some other forms of
 crypto concepts though. I wish to explore more about PGP.

Excellent! Welcome!

 Straight to my question! According to many speculations out in the public,
 NSA has weakened RSA algorithm. Is it still safe to use the RSA as the
 underlying algorithm for generating the keys? Are there any viable
 alternatives which we can choose over RSA and DSA?
 Please correct me if I'm wrong. :)

There were some reports of RSA (the company) accepting funds from the
NSA to make Dual_EC_DRBG (a poor-quality and possibly backdoored
pseudorandom number generator) the default in their BSAFE toolkit.

RSA (the algorithm) is, as far as publicly-available knowledge goes,
still secure with appropriate key lengths and the non-existence of
suitably-powerful quantum computers.

Version 2.1 of GnuPG will support elliptic curve crypto, which will be
nice. However, ECDSA and ECDH (the signing and encryption algorithms
used in GnuPG 2.1) are also vulnerable to quantum computers.

Of course, it's certainly possible that the NSA or other adversaries
have compromised RSA or other algorithms, but there's no
publicly-available proof of this.

Cheers!
-Pete

-- 
Pete Stephenson

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

Re: Keeping .gnupg folder in cloud

[Pete Stephenson]

On 9/18/2014 11:32 AM, Sudhir Khanger wrote:
 What are your views on keeping .gnupg folder in cloud? I am working on
 a threefold backup system - a local external drive, a local nas server
 and a third-party cloud service like S3/CrashPlan. Backup will be
 fully encrypted client side. My plan is to avoid complexity by backing
 up everything in home folder which would include .gnupg folder by
 default. My threat level is non-existent. I use encryption and GPG as
 a matter of good internet and security practices and not because of
 necessity. What do you guys think?

In general, I'd recommend against it, but in your specific situation I
don't really see a problem.

Some people have gone so far as to publicly publish (is that redundant?)
their encrypted private keys[1] to the internet. Assuming that the
crypto is sound and the passphrase protecting the key is strong, and
your system has not been compromised (e.g. there's no keylogger),
there's very little to worry about. Still, probably not a good idea.

Cheers!
-Pete

[1]
https://filippo.io/on-keybase-dot-io-and-encrypted-private-key-sharing/


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

Re: gmail list replies [Re: Keeping .gnupg folder in cloud]

[Pete Stephenson]

On Thu, Sep 18, 2014 at 10:36 PM, Daniel Kahn Gillmor
d...@fifthhorseman.net wrote:
 On 09/18/2014 01:31 PM, Sudhir Khanger wrote:
 PS:- Gmail has a weird setup. It would not allow me to reply back to
 the mailing list email. Reply replies to person whose email you
 clicked reply from and reply all goes to everybody's email on the
 thread and not the list.

 You put this part of your message below your .sig, so many people might
 not have seen it.

 I don't use gmail, but perhaps one of the other people who use gmail on
 this list can give you pointers on how to interact with mailing lists
 like this one through their web interface.

I use Google Apps (in essence, Gmail for one's domain). Reply
composes a response to the sender (but not the list). Reply All
composes a response to the sender and CCs the list.

I have not observed the behavior that Sudhir reports. Perhaps things
behave differently between Gmail and Google Apps? There's some other
minor differences, but for everything else the compose/reply options
have always seemed to be quite similar.

Cheers!
-Pete

-- 
Pete Stephenson

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

Re: Help about GnuPG 1.4.9

[Pete Stephenson]

On 9/14/2014 11:05 PM, bonn...@sanboa.info wrote:
 Hello,
 
 I'm a completly new possible user of macgpg.
 I want to use it but somme security questions don't be resolved :
 I've a Mac with Mac OS 10.5.8 Intel Core 2 duo with AppleMail 3.6 and
 want to download the free software.

Welcome! Hopefully we can get you straightened out!

 I've falled on this site : http://macgpg.sourceforge.net/fr/index.html
 which lets download this :
 /GNU Privacy Guard/ - pour Mac OS X 10.1 (et suivantes)
 
   * Pour Mac OS X 10.4.x et plus nouveau
   o GnuPG v2.x
 https://sourceforge.net/project/showfiles.php?group_id=248469,
 now a separate project.
   o 1.4.9
 http://prdownloads.sourceforge.net/macgpg/GnuPG1.4.9.dmg?download,
 MD5: 36d9eb482a98774521bfd7bb73e4ad06
 
 I've choosen 1.4.9 

GnuPG 1.4.9 is a bit out of date. https://gpgtools.org/ should have a
more recent version, but it seems that it will only work back to Mac OS
X 10.6, not 10.5.

Can you upgrade to a newer version of Mac OS X? 10.5 is quite old and
reached end-of-life in 2011.

You might find
http://support.gpgtools.org/discussions/problems/10783-gpgtools-for-mac-osx-1058
to be of some interest.

 But after,  I've read : *Never use a GnuPG version you just downloaded
 to check the integrity of the source* - use an existing GnuPG installation. 
 on : https://www.gnupg.org/download/integrity_check.html
 and that's the problem for me :
 _how can I know if the software downloaded is secure or not ?_
 
 I followed the advices :
 
 gpg --verify 1.4.9
 
 sha1sum 1.4.9
 
 etc., on Terminal.app

It's possible that Mac OS X 10.5 does not have gpg, openssl, or sha1sum
installed. I'm not familiar with systems that old.

However, it appears that the system does have a means of calculating MD5
checksums. You should be able to run the following command from a terminal:

/sbin/md5 /Users/alain1/Desktop/GnuPG1.4.9.dmg

Alternatively, if the Mac has GPG installed already (I know that newer
versions of Mac OS X do, but I'm not sure about 10.5), you can run the
following from the terminal:

gpg --print-md MD5 /Users/alain1/Desktop/GnuPG1.4.9.dmg

 but never appeared the good suite MD5 of numbers and letters !
 history:
 'openssl md5 [nomDeFichier]'Last login: Sun Aug 16 17:52:58 on console
 Ordinateur-839:~ alain1$ 'openssl md5
 [/Users/alain1/Desktop/GnuPG1.4.9.dmg ]'-bash: openssl md5
 [/Users/alain1/Desktop/GnuPG1.4.9.dmg ]: No such file or directory
 Ordinateur-839:~ alain1$ 'openssl md5 [GnuPG1.4.9]'
 -bash: openssl md5 [GnuPG1.4.9]: command not found
 Ordinateur-839:~ alain1$ openssl md5 [/Users/alain1/Desktop/GnuPG1.4.9.dmg]'

What happens if you run the command without the square brackets ([]) or
the single quotes (')?

For example,

openssl md5 /Users/alain1/Desktop/GnuPG1.4.9.dmg

  Thus, my second question :
 _With which application can I check that the software downloaded is
 secure (writing openssl md5…)_

OpenSSL is installed in newer Mac OS X systems, but might not be
installed on 10.5. If it's not installed, you could install it but
that's typically not a trivial thing to do.

Check if it's installed by running:

openssl version

from the terminal.

As for your other questions, I'm not sure. Hopefully someone else can
answer.

Cheers!
-Pete



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

Is it possible to sign a message with multiple digest algorithms?

[Pete Stephenson]

Hi all,

Is it possible to sign a message (or certify a key) with multiple digest
algorithms?

For example, one might wish to sign a message with both SHA256 and
RIPEMD160.

If so, how would one go about doing this?

I would imagine that, if possible, the command would be similar to gpg
--armor --digest-algo SHA256 RIPEMD160 --clearsign but this fails.

If it is possible, how does GPG handle multiple signatures? That is, is
it required that all signatures must be valid for the message to be
considered valid, or is the message considered valid so long as one (out
of many) signatures is valid?

The former behavior would be useful to ensure message long-term message
integrity, in case one of the digest algorithms were found to be weak.
The latter behavior would be useful when using digest algorithms without
wide support (e.g. one might use SHA1 and SHA512, so as to support older
clients while providing greater security for modern ones).

Cheers!
-Pete

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

Re: [Announce] [security fix] Libgcrypt and GnuPG

[Pete Stephenson]

On Sat, Aug 9, 2014 at 10:49 AM, Werner Koch w...@gnupg.org wrote:
 On Sat,  9 Aug 2014 01:24, p...@heypete.com said:

 The GPG4Win folks are gearing up for a new release this August.

 Excellent. I look forward to it.

 The problem with gpg4win is that it is hard to build in particular the
 KDE stuff can't be easily cross compiled.  It is quite some work to
 maintain this software and donations are very low.  My tentative plan is
 now to separate GnuPG proper from the other stuff and provide it as a
 separate installer (for gnupg 2.1)

I'll bet. Fortunately, there are decent Windows front-ends for
mail-related tasks like Enigmail. Not much for file-related tasks,
though.

I would definitely be happy if the GPG binary was packaged separately:
I almost never use GPA or other GUI tools that come with the package.

Thanks for the reminder regarding donations: I really should chip in a
bit more this year.

Cheers!
-Pete

-- 
Pete Stephenson

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

Re: [Announce] [security fix] Libgcrypt and GnuPG

[Pete Stephenson]

On Fri, Aug 8, 2014 at 12:17 PM, Werner Koch w...@gnupg.org wrote:
 Hi!

 While evaluating the Get Your Hands Off My Laptop [1] paper I missed
 to describe [2] a software combination which has not been fixed and is
 thus vulnerable to the attack described by the paper.  If you are using
 a GnuPG version with a *Libgcrypt version  1.6.0*, it is possible to
 mount the described side-channel attack on Elgamal encryption subkeys.
 To check whether you are using a vulnerable Libgcrypt version, enter

   gpg2 --version

 on the command line; the second line of the output gives the Libgcrypt
 version:

   gpg (GnuPG) 2.0.25
   libgcrypt 1.5.3

 In this example Libgcrypt is vulnerable.  If you see 1.6.0 or 1.6.1 you
 are fine.  GnuPG versions since 1.4.16 are not affected because they do
 not use Libgcrypt.

Does this vulnerability apply to gpg4win users?

There's been no gpg4win updates since October of 2013 and there have
been several updates of GnuPG since then. I am somewhat concerned.

Is there any information about when an update for Windows users might
be released?

Cheers!
-Pete

-- 
Pete Stephenson

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

Re: [Announce] [security fix] Libgcrypt and GnuPG

[Pete Stephenson]

On Fri, Aug 8, 2014 at 11:44 PM, Samir Nassar sa...@samirnassar.com wrote:
 On Friday, 2014-08-08 23:34:30 Pete Stephenson p...@heypete.com wrote:
 Does this vulnerability apply to gpg4win users?

 It should, since the issues the GnuPG update addresses come after the latest
 release of GPG4Win.

I assumed as such, but it's good to be certain. I'm not sure if
there'd be some OS-specific details that would affect the issue.

 There's been no gpg4win updates since October of 2013 and there have
 been several updates of GnuPG since then. I am somewhat concerned.

 Is there any information about when an update for Windows users might
 be released?

 The GPG4Win folks are gearing up for a new release this August.

Excellent. I look forward to it.

-- 
Pete Stephenson

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

Re: CRC error

[Pete Stephenson]

On Mon, Jul 28, 2014 at 7:53 PM, pedro.mar...@ml1.net wrote:


 Thanks for the answers about the CRC error, i found what i needed, but it
 took me now to other questions. Actually i got the CRC error when i
modified
 some strings of a public key and then i tried to import it.

The CRC checksum can't tell the difference between intentional modification
of the type you describe and data corruption; it simply knows that the
checksum doesn't match what it thinks it should be, so it presents the
error.

 I told to my self that it would be interesting as securing method to sign
 stuff with a private key with out having the public key. this would
mean that only
 the person who has public key would have access to the data with out
needing
 a password.

When would this be useful? The public key is public, and anyone with it
could decode the message. To secure a message such that only the desired
recipient can read it, you should encrypt a message to the recipient's
public key so that only their private key can decrypt it.

Simply put, I don't understand a situation where using your system would be
an improvement over the current system, but perhaps I misunderstand
sometihng.

 (and the person with the private key too i think, it would be great if
only the person
 with the public key can decrypt the data, maybe there is one option, i'll
check for that.)

 So why i was asking about the CRC error?

Because the key was modified in a way that GPG did not expect.

 when i was testing this method, i removed the keys from my keyring, and
then
 i imported only the secret key. For my surprise there was also the public
key.
 Is there anyway to only import the secret key?

The public key can be (and is) regenerated as needed from the private key.
If you import a private key and there is no corresponding public key in the
keyring, GPG automatically recreates the public key and puts it in the
keyring. As far as I know there is no way to import only a private key
without the corresponding public key.

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

Re: GPG4Win question

[Pete Stephenson]

On Fri, Jul 11, 2014 at 11:45 AM, da...@gbenet.com da...@gbenet.com wrote:

 Hi All,

 In what folder does gpg4win store it's gpa.conf and pubring.gpg files?


In Windows 7 at least, it's in %appdata%\Roaming\gnupg

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

Re: Analogien um das Prinzip von PGP zu erklären

[Pete Stephenson]

I seem to recall someone on this list using a mailbox like the one at [1]
as an analogy for public-key encryption: anyone can walk up to the mailbox
and place a letter in the slot (encrypting a message to the recipient's
public key), but they cannot retrieve any other letters in the box [2].

That type of mailbox is essentially a one-way device, and messages placed
in the mailbox can only be retrieved by someone who has the key to unlock
it (the private key belonging to the recipient).

I'm not really sure of a similar analogy for signing.

[1]
http://www.signaturehardware.com/outdoor/mailboxes-and-slots/castle-locking-wall-mount-mailbox-with-newspaper-roll.html
[2] Obviously mailboxes can be broken into with relative ease, but it's
merely an example.


2014-07-03 12:50 GMT+02:00 Daniel Krebs mailingl...@krebs.uno:

 Hallo,
 da ich das gerade mit Matthias von der FSFE im Rahmen von
 #EmailSelfDefense diskutiere, mal eine Frage: Welche Analogien benutzt ihr,
 wenn ihr Menschen das Prinzip von PGP/GPG erklärt?
 Ich verwende ich meistens folgende Version:

 Es gibt ein Schloss mit zwei Schlüssellöchern. Jeder Schlüssel
 funktioniert nur in eine Richtung, also entweder Geöffnetes schließen
 oder Geschlossenes öffnen. Daran kann man dann auch das signieren
 erklären, was ja bei der klassischen Metapher (öff. Schlüssel =
 Schloss, priv. Schlüssel = Schlüssel) nicht funktioniert. Also:
 Verschlüsseln:
 Jemand verschließt mit meinem öffentlichen Schlüssel, ich öffne mit
 meinem geheimen.
 Signieren:
 Ich signiere mit meinem privaten Schlüssel, jemand anders überprüft mit
 meinem öffentlichen.

 Anregungen, Meinungen?

 --
 kind regards
 daniel krebs

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




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

Re: Alice, Blake, Chloe and Dharma.

[Pete Stephenson]

On Sun, Jun 8, 2014 at 2:19 AM, sonne kind...@gmail.com wrote:
 Hi all. Hello, Mike Ashley

 Reading gpg manuals, I wonder why the usual example agents of a
 cryptography-related situation are called in an unusual way.

 I notice that in related RFCs the usual Alice and Bob are used, and no
 apparent trace of Chloe or Dharma.

True, but there is a Carol, Charles, Dave, etc. Typically (but not
always) the names aren't just a placeholder for a participant, but the
first letter of the name means something (e.g. Eve is an
eavesdropper who can see but not modify the data between Alice and
Bob, Mallory is a malicious attacker who can perform active attacks,
etc.).

See http://en.wikipedia.org/wiki/Alice_and_Bob for details.

Bruce Schneier's book Applied Cryptography was published in 1996 and
contains reference to several of those names. I'm not sure if that's
the origin of their use in this context, though. Anyone else?

Cheers!
-Pete

-- 
Pete Stephenson

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

Re: list packets output other misc

[Pete Stephenson]

On 6/5/2014 10:44 AM, Werner Koch wrote:
 On Wed,  4 Jun 2014 23:15, shm...@riseup.net said:
 
 how can i mandatorily specify using other subkeys for the same primary
 key for 's' or 'e' either on command line or in an email client for
 example ?
 
   fortune | gpg -ea -r '12345678!'
 
 assuming 12345678 is the subkeys' keyid.  Same for -u.

To clarify, it's the exclamation point (!) that forces GPG to use a
specific key. Normally GPG will pick what it thinks is the appropriate
key, but the exclamation point will override that automatic choice and
use only the key ID specified by the user.

I'm not aware of any email clients that allow such an override -- it's
typically only used in the command line.

https://www.gnupg.org/documentation/manuals/gnupg-devel/Specify-a-User-ID.html
has some more details.

 is there a reference for the numerical values of version, hash, cipher,
 algo, sk2, etc ?
 
 --list-packets is a debugging aid and thus you need to look at the
 source or doc/DETAILS for some of these values.  However, most of these
 numbers are specified in RFC-4880.

Specifically, that information is available at
http://tools.ietf.org/html/rfc4880#page-62, in sections 9.1 through
9.4, inclusive.

Cheers!
-Pete


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

Re: what hardware entropy usb key equivalent Simtec entropy key take ?

[Pete Stephenson]

http://ubld.it/products/truerng-hardware-random-number-generator/
seems to be the closest I've seen in regards to a USB stick form
factor and price. It doesn't use the ekeyd daemon for adding entropy
to the pool, but rather shows up as a virtual serial port and one can
use rngd to feed that data into the kernel pool. I have no personal
experience with that product, but it would seem that even if the
entropy source was compromised in some way, that would not be a major
issue -- rngd does tests to detect biasing (which admittedly won't
catch more subtle manipulation) and /dev/random would stir the pool
with entropy from various sources, so it can only help.

While not a direct, drop-in replacement for the Entropy Key, I found
that a Raspberry Pi and it's internal hardware random number generator
makes a good source. The internal HWRNG in the Pi is extremely fast
(700kbps). I've not personally setup a Pi to share entropy over the
network, but I'd imagine this is something that could be reasonably
done. I only have the HWRNG generating entropy for local use. Anyone
have experience with a network setup?

In regards to getting the Pi's HWRNG setup,
http://vk5tu.livejournal.com/43059.html has all the details.

It's basically three steps:
1. Add bcm2708_rng to /etc/modules, then run modprobe bcm2708_rng
to activate the module.
2. Install the rng-tools package.
3. Edit /etc/defaults/rng-tools to access the HWRNG and feed the kernel pool.

My /etc/defaults/rng-tools file looks a bit different than that of the
previously-mentioned website. Here's the relevant lines from my file:

###
#Specify the HWRNG device
HRNGDEVICE=/dev/hwrng
# Check the kernel entropy pool once per second, and add HW-generated
entropy if it drops below 90%.
# You can change these values to whatever you feel would work best for you.
RNGDOPTIONS=--fill-watermark=90% --feed-interval=1
###

Please note this assumes that the HWRNG has not been subverted,
broken, or doing something unexpected.

I hope this helps.

Cheers!
-Pete

On Sun, May 25, 2014 at 8:57 PM,  tux.tsn...@free.fr wrote:
 Hello alls,

 As you know it is not more possible to buy a Simtec entropy usb key since 
 many years, so my question what hardware entropy usb key do you recommend now 
 to replace it (not too expensive) ?

 PS:  need to be compatible with GNU Linux / Debian

 Thanks in advanced for your return.

 Best Regards

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



-- 
Pete Stephenson

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

Re: Access to www.gnupg.org only via TLS

[Pete Stephenson]

On Apr 30, 2014 9:25 PM, Doug Barton do...@dougbarton.us wrote:

[snip]

 ... your whole premise seems to be invalid as there is no clear evidence
at this time (that I'm aware of, and I've been paying attention) that any
actual secret keys have been compromised by Heartbleed. It was listed as a
potential risk when the vulnerability was first announced, but several
groups have done research on that specific point and have found that it
would be sufficiently difficult, if not actually impossible; to render this
particular risk as negligible at best.

Cloudflare did a challenge where a Heartbleed-vulnerable system was exposed
to the internet with a challenge to recover the private key. They thought,
based on internal testing, it would be quite difficult if not impossible.
The key was found within hours:
http://blog.cloudflare.com/the-results-of-the-cloudflare-challenge

Interestingly, Heartbleed is being used by security researchers to access
online forums used by bad guys who, for whatever reason, have not patched
their servers:
http://www.bbc.com/news/technology-27203766 -- it is not clear if the
researchers are getting private keys, but it certainly appears to be
possible.

In regards to certs, I like the principles behind CAcert, but using their
certs on public-facing systems can be problematic due to their root not
being included in browsers. For practical reasons, using a CA included in
browsers is often a better choice.

I use and usually recommend StartSSL but if that's not an option for
whatever reason, several CAs offer free-of-charge certs for FOSS projects.
Two examples that spring to mind are GoDaddy [1] and GlobalSign [2].

For paid certs, it can often be (considerably) cheaper to buy through a
reseller: for example, a PositiveSSL cert from Comodo costs $49/year, but
the same cert purchased via NameCheap is only $9/year.

Gandi.net, a French registrar, also offers certs chained to Comodo at a
reasonable price, though they're slightly more expensive than US-based
NameCheap.

Cheers!
-Pete

[1] http://www.godaddy.com/ssl/ssl-open-source.aspx
[2] https://www.globalsign.com/ssl/ssl-open-source/
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Heartbleed attack on Openssl

[Pete Stephenson]

On Apr 10, 2014 12:22 AM, Felipe Vieira fmv1...@gmail.com wrote:

 So going back to the original question as I can see there is no
disagreement on its importance:
 1) What are the consequences to the ordinary user?
 All the news are lacking information on that. Can you point relevant
examples?

Any service using a vulnerable version of OpenSSL in the last two years
could have been silently attacked, with the attackers being able to gain
access to information stored in the servers memory.

The attacker might get memory containing empty sections, boring system
files, secret cryptographic keys (the compromise of which could, in some
cases, lead to user data being decrypted or a MITM being possible with no
warnings), user data, etc.

Its not clear of any bad guys knew about the bug prior to the announcement.
If they didn't and one patched any affected servers as soon as possible,
then the effects would be quite minimal. If they did know and exploited
things, or if one has not yet patched vulnerable systems, things could be
very bad.

In short: the consequences could be dire but there is no way of knowing for
certain what, if any, things have been compromised. Its probably best to
assume the worst.

 All I could gather is that the only major/well known server to be
compromised was Yahoo.

Yahoo fixed the issue shortly after the public announcement of the bug. It
is not clear of bad guys were able to compromise their systems before it
was fixed, but researchers were able to successfully probe various systems
at Yahoo prior to the fix, so one should assume bad guys could do the same.

 For example: Gmail and Dropbox and Hotmail seem to be imune to this. I
also found out that Mozilla/Firefox browser were also imune. If I would
persuade someone of this bug's importance, which other examples could I
give?

No service using an affected version of OpenSSL is immune. Some (like
Cloudflare) received advanced notice and patched their systems before the
public announcement, while others may have used other SSL libraries or
versions of OpenSSL that were not vulnerable.

 2) (specific question) Does Firefox use openssl to connect to some
servers while browsing?

No. Firefox is immune because it uses the NSS Crypto library.

The issue typically exists on and affects servers. A server using an
affected version of OpenSSL is vulnerable regardless of what browser
clients use.

 3) How about Ubuntu and other OSs? Do they use openssl to update
themselves? (as in apt-get update  apt-get upgrade).

Ubuntu and Debian use GnuPG to sign packages but updates typically take
place over unencrypted connections. The update mechanism is not affected by
this bug.

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

Re: Chipdrive SPR 532 and OpenPGP Card with 4096Bit RSA Keys

[Pete Stephenson]

On Sat, Apr 5, 2014 at 3:57 PM, Florian Wolters
flor...@florian-wolters.de wrote:
 But concerning the keys I got another question:  How can I tell gnupg to
 use keys that are already stored on the card? I do have my private key
 on the card already and want to use this card on another computer? Do I
 have to import my keypair again and then keytocard?

 Or can I tell gnupg somehow to use the key already existing on the card?

When you run keytocard the private key is moved to the card and then
the private key on the computer is then replaced with a stub that
says The private key is located on the smartcard with a serial number
of $SERIAL_NUMBER so GnuPG knows where to look and, if the card is
not present, prompt you for the right card. (Be sure you have a backup
of your actual private key before running keytocard, if that's
something you'd like to do.)

As far as I know, there are two options for setting up a second system
to have the stub without actually needing to import your actual
private key:

1. You can export the stub private key (I use quotes because unlike
a real private key, the stub is not sensitive information) from your
first computer and then import it into the second just as you would do
if you were importing any other private key.

2. Import only the your public key to the second computer, then insert
the smartcard and run gpg --card-status. This will detect the card
and generate the appropriate stub. This is the method I usually do.

Cheers!
-Pete

-- 
Pete Stephenson

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

Re: Size of client key jumped from 2KB to 25KB

[Pete Stephenson]

On Mon, Mar 10, 2014 at 4:36 PM, Steve Strobel
steve.stro...@link-comm.com wrote:
 When we export the public key with a command like gpg --output
 client-key.gpg --export -a ID49C207DF, is there a way to do so without the
 signatures?  We send that key to the server so it can be used to encrypt
 data for the client, but we don't really need to transfer any information
 about how trusted the client is.  Does that make sense?  Now that I think
 about it, the client key shouldn't have any signatures at all;  there is
 nothing else in the system to attest to them.  I posted the complete
 --list-packets (and --list-keys) output at the URLs below in case it is
 helpful:

Adding --export-options export-minimal should do the trick.

That is, gpg --output client-key.gpg --export --export-options
export-minimal  -a ID49C207DF.

See 
http://www.gnupg.org/documentation/manuals/gnupg-devel/GPG-Input-and-Output.html
for details.

Cheers!
-Pete

-- 
Pete Stephenson

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

Re: Trying to understand the bond between master and subordinate key pairs

[Pete Stephenson]

On Wed, Feb 12, 2014 at 4:02 AM, Faru Guredo farugur...@gmail.com wrote:
 I’ve read GNU Privacy Handbook, the FAQ and thought I understood the purpose
 of all four keys initially generated with --gen-keys.
 But then I found this https://wiki.debian.org/subkeys and lost it.

 tl;dr: There is suggested backup of ~/.gnupg, creation of a new pair of
 subkeys for signing, then all public keys and secret subkeys are exported,
 master key (for signing) is removed (but still available in backup) and
 finally public keys along with secret keys are imported back. This is
 suggested — as far as I understand — in order to keep the original master
 key for signing in a secret place, because master signing key = my genuine
 identity. But.

Right, this is a reasonable thing to do. It's not mandatory, of
course, but it has various advantages.

 Which public keys should be uploaded to the keyserver? Other people may
 verify your signature and encrypt files for you only if they have
 corresponding public keys (of yours). But what about gathering signatures of
 other people on your own public key? Should I upload public key of my master
 signing key along with the public key of the subordinate keypair I am
 planning to use daily? If not, what is the purpose of the public part of the
 master keypair? If I will not upload it, how other people will verify
 signatures I made on their keys or my own keys? Does it all mean I need at
 least three public keys to be known to other people — two for daily signing
 and encrypting and one to verify master key signatures? Do they even need to
 verify what I sign with my master key (I mean my keys and their keys)?

You should upload the public key of your primary (master) key to the
key servers. If you do this in GnuPG, it will automatically upload the
public keys for your primary key and all the subkeys. If you use the
--export command to export your public key, it will export the
public key of your primary key and subkeys in one file.

Similarly, when people search for your public key on the key servers
they should search for the KeyID of your primary key. When they
download it, they will also get the public keys for the subkeys.

 I don’t get the bond between master keys and subordinate keys. Does it even
 exist? To me they look like totally different keys. Okay, when I usually
 sign files with key  when I send them to Alice, and eventually I
 want to sign her key (…which of her keys, actually? The one she uses daily
 or the one she keeps like me? If she keeps it, how did it get to me? Which
 public keys supposed to collect signatures of other people — of the master
 one or newly created subordinate one?), I need to use my master key
 . How does she know that  is also my key if they have
 different IDs? (Let’s assume public key of the master pair is irrelevant,
 and signing pubkey exchange is done via subordinate pair which never
 expires.)

Subkeys are bound to their respective primary key by signatures made
by the primary key.

When you sign someone else's key, you sign the public key of that
person's primary key. Similarly, when they sign your key, they sign
your primary key. Since the subkeys are bound to their respective
primary keys, the trust in the primary key is automatically applied to
any subkeys without any additional signatures being required. For
example, see my key 0x85EB9F44 (which can be found on the keyservers
at 
http://pool.sks-keyservers.net:11371/pks/lookup?op=vindexfingerprint=onsearch=0x9A5CC3A485EB9F44)
-- my primary key (pub) has collected signatures from several people
on my user ID (uid). I also have signing and encryption subkeys
(sub) that are bound (sig sbind) to the primary key and which I
use for day-to-day signing and encrypting of files and messages.

I only use my primary key for signing other people's public keys
(subkeys cannot make certifications on other people's public keys)
or when generating new subkeys. Otherwise, the subkeys are used for
all the usual purposes.

In general, people do not need to know the KeyIDs of the subkeys --
that is handled automatically by GnuPG. Similarly, you generally do
not need to concern yourself with the KeyIDs of your subkeys, nor do
you need to tell GnuPG to specifically use them (GnuPG will sign
messages with the newest signing subkey by default).

In short: your subkeys are linked to your primary key and GnuPG will
handle subkeys automatically and transparently without your needing to
worry about their KeyIDs.

Cheers!
-Pete

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

Re: Difference between setpref and options in the configuration

[Pete Stephenson]

On Sun, Feb 9, 2014 at 2:39 PM, Stephane Bortzmeyer bortzme...@nic.fr wrote:
 When reading
 https://alexcabal.com/creating-the-perfect-gpg-keypair/, which
 advises to use gpg --edit-key and setpref to choose better
 algorithms, I told myself Why risking forgetting the right
 command-line when you can simply use the configuration file? So, I
 put this in ~/.gnupg/gpg.conf :

 # SHA1 by default
 cert-digest-algo SHA256
 # Crypto preferences
 personal-cipher-preferences  AES256 AES192 AES128
 personal-digest-preferences SHA512 SHA384 SHA256 SHA224
 personal-compress-preferences  ZLIB BZIP2 ZIP Uncompressed

 And generated a key, with two UID. But it seems the preferences in
 personal-*-preferences have been completely ignored:

That's because the personal-*-preferences don't change the preferences
in the key itself. They merely change the order of ciphers, hashes,
and compression methods that you prefer when communicating with others
(so long as you both support those algorithms).

According to 
http://www.gnupg.org/documentation/manuals/gnupg-devel/GPG-Esoteric-Options.html
you'll want to use default-preference-list followed by the list of
preferences for your key. For example, putting
default-preference-list SHA512 SHA384 SHA256 SHA224 AES256 AES192 AES
CAST5 ZLIB BZIP2 ZIP Uncompressed in your gpg.conf file and then
generating a new key (or running edit-key KEYID, setpref with an
empty string for the preferences, and save on an existing key) will
set the key preferences to that string.

Cheers!
-Pete

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

Re: trying to find a folder

[Pete Stephenson]

On Sat, Jan 25, 2014 at 1:37 AM, Justin Quakenbush
justinquakenb...@gmail.com wrote:
 wheres my gnupg folder?

The folder containing the keyrings and configuration files is
typically in ~/.gnupg/ on Linux and in %appdata%/gnupg on Windows,
though it may be different on your specific system.

-- 
Pete Stephenson

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

Re: his public key is 5 monitors high, and her same key is 1 ?

[Pete Stephenson]

On Fri, Jan 24, 2014 at 2:24 PM, shm...@riseup.net shm...@riseup.net wrote:
 what are the factors involved in creating such discrepancies with folks'
 public key lengths ?

As far as I can tell, the two major factors that affect the size of
public keys are:
1. Key length. (That is, a 4096-bit key will be larger than a 2048-bit
or 1024-bit key.)
2. Number of signatures on the key. A brand-new key will be
considerably shorter than one that has accumulated numerous signatures
from other people.

 are public, private, and key pairs in general stronger/safer (what ever
 that may mean) if observing their public keys are many monitors high or
 have they gone to extreme measures in something in particular ?

Key length does have an effect on security: 2048-bit keys are larger
and harder to brute-force than 1024-bit keys. The same applies to 3072
and 4096-bit keys compared to 2048-bit ones, though there is a point
of diminishing returns.

-- 
Pete Stephenson

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

Re: Revocation certificates [was: time delay unlock private key.]

[Pete Stephenson]

On Thu, Jan 23, 2014 at 9:25 PM, Leo Gaspard ekl...@gmail.com wrote:
 On Thu, Jan 23, 2014 at 05:53:57PM +, nb.linux wrote:
 And, you can be prepared for such an event (i.e. having created the
 revocation certificates in advance, stored them in a save but accessible
 place, printed out on paper,...).

 Actually, this is something I never understood. Why should people create a
 revocation certificate and store it in a safe place, instead of backing up the
 main key?

It's a sensible thing to do both, of course.

 So long as the primary key is encrypted and the passphrase is strong, this
 should not lead to any security danger. (Anyway, it's stored in a safe 
 place.
 And a revocation certificate misused is dangerous too, as it ruins a web of
 trust.)

 And the advantages of doing so are that in case or accidental erasing of the
 private key (who never accidentally deleted an important file?), it also 
 allows
 the main key to be retrieved.

 The primary key allows one to create a revocation certificate, not the other 
 way
 around. So, why store a safe revocation certificate?

The most damage that a misused revocation certificate can do is
revoking one's certificate. This is a bit of a pain, in that one would
need to create a new keypair, get it signed, etc., but it wouldn't
result in the compromise of sensitive information, messages, etc.
Misuse of a revocation certificate is a minor denial-of-service, but
not a complete break of security.

For example, one could easily give a trusted friend or family member a
copy of a revocation certificate (perhaps printed on paper) to keep in
a physically distant location. They would need to be trustworthy
enough to not abuse the revocation certificate by revoking your
certificate, but otherwise would not need to be given absolute trust
that comes with having a copy of the private key. Same thing with
keeping revocation certificates in a bank safe deposit box or some
other location protected by a third-party -- if the box were
compromised (say by the authorities with a court order), your private
key would not be compromised.

 Leo

 PS: Please, do not tell me one might have forgotten his passphrase. In this 
 case
 there is no harm in shredding the secret key and waiting for the expiration
 date, answering persons emailing you encrypted files that you lost your
 passphrase. Anyway, in this case, you're screwed, and a revocation certificate
 would be no better -- unless it was stored unencrypted, at the risk of having 
 it
 used when you do not want it to be.

Actually, that's a fairly reasonable scenario. Someone may have
forgotten their passphrase for whatever reason (ranging from
forgetfulness to head trauma) and would like to inform others that
their key is no longer usable. Replying to people saying that their
key is lost is essentially indistinguishable from a man-in-the-middle
attack -- some people might simply resend the encrypted message in
plaintext, defeating the purpose of encryption in the first place.

A revocation certificate allows one to revoke the certificate even
without access to the private key, so one could reply with their
now-revoked public key (or direct someone to the revoked key on the
keyserver) and say Sorry, I lost the private key and had to revoke
it. -- while this doesn't resolve the issue of people resending
things in plaintext, it does permit someone to actually show that
their key is, in fact, revoked.

Also, not all keys have expiration dates. I, for one, tend not to set
expiration dates on my primary keys, but instead rotate encryption and
signing subkeys (which do have expiration dates) for day-to-day use.
While I could put an expiration date on the primary and extend the
date as needed, it's easier for me to just make revocation
certificates and keep them stored off-site.

Your mileage may vary, of course.

Cheers!
-Pete

-- 
Pete Stephenson

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

Re: Usage of --symmetric

[Pete Stephenson]

On Wed, Jan 22, 2014 at 8:59 AM, Rahul R rahul.ra...@gmail.com wrote:
 Hi all,

 I am trying to run

 gpg --symmetric test.txt

 But its asking for Passphrase. Is there any way to skip this while running
 this command?

No.

When you symmetrically encrypt something you need to specify the
passphrase that is used as a key to encrypt and decrypt that file.

-- 
Pete Stephenson

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

Spam sent in response to GnuPG-users messages?

[Pete Stephenson]

Hi folks,

It appears that there's a spammer who has subscribed to the mailing
list and is sending out cute girl wants to chat spam in response to
messages sent to the list.

They're not sending mail to the list itself, but rather to the
individual sender addresses that have sent messages to the list.

Has anyone else received similar messages? Is there some way of
identifying the trigger address that's subscribed to the list and
results in these messages being generated? I'd be happy to supply the
spammy messages in question (off-list, of course) if that would help
identify the offending spammer.

Cheers!
-Pete

-- 
Pete Stephenson

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

Re: Any way for two correspondents to set up gnupg within a few moments without having to become expert?

[Pete Stephenson]

On Jan 21, 2014 5:32 PM, Hauke Laging mailinglis...@hauke-laging.de
wrote:

 Am Di 21.01.2014, 16:06:36 schrieb Michael Anders:

  I don't know if hash preference information is additionally attached
  to keys. I would guess it is not, it wouldn't make sense to me.

 Unfortunately that's not a reliable guide.


http://www.gnupg.org/documentation/manuals/gnupg-devel/GPG-Esoteric-Options.html

 --default-preference-list

I've found http://www.debian-administration.org/users/dkg/weblog/48 to be a
reasonably sensible guide for setting stronger preferences. I also added
Twofish and Blowfish after AES256 and AES, respectively.

I've not heard of any issues with that setup, but your mileage may vary.
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: article about Air Gapped OpenPGP Key

[Pete Stephenson]

On 11/18/2013 6:21 PM, adrelanos wrote:
 Hi,
 
 An article about air gapped OpenPGP keys has been written by me:
 https://www.whonix.org/wiki/Air_Gapped_OpenPGP_Key
 
 Please leave feedback or hit the edit button. Maybe it's useful for
 someone. It's under public domain.
 
 Cheers,
 adrelanos

Excellent work!

Here's some minor suggestions and personal opinions.

1. If you set the keyprefs in your gpg.conf configuration file before
you generate a new key it will generate new keys with these stronger
defaults rather than having you need to edit them later. See
http://www.debian-administration.org/users/dkg/weblog/48 for details
and examples.

I'd like to call your attention to the cert-digest-algo SHA256 line --
this means that your primary key will make stronger signatures on other
keys (e.g. your subkeys and other people's public keys). This is
probably a Good Thing.

2. Have you considered adding TWOFISH and BLOWFISH to the list of
ciphers? I put TWOFISH after AES256 and before AES192, and I put
BLOWFISH after AES but before CAST5. I like having diverse, strong
ciphers available to those who might elect to use them. Since the
versions of GnuPG I use support those ciphers and they're generally
well-regarded I see no reason to exclude them, but your mileage may vary.

I've been tempted to add prefs showing I can use the CAMELLIA cipher --
does anyone know of a good reason not to?

3. When generating the key and you're prompted to pick a key type, I
recommend selecting #4 (RSA (sign only)). This generates only the
primary signing/certification key but does not generate an encryption
subkey at the same time. Later you can add the encryption and signing
subkeys. This can be useful if you want to mix-and-match algorithms and
expiration dates.

For example, I have a 3072-bit DSA sign/cert primary key, a 2048-bit RSA
encryption subkey, and a 2048-bit RSA signing subkey. The two subkeys
have a 5-year expiration time while the primary key has no expiration time.

Of course, selecting option #1 and creating an RSA sign/cert primary key
with an RSA subkey of equal strength with the same (if any) expiration
date, followed by adding a new signing subkey also works. It's simply a
matter of personal preference -- I like generating each key individually
so I have control over that specific key.

4. Are there any known issues with your air gapped system being the
same physical hardware as your everyday system even if you use a LiveCD?
I don't know if there'd be the potential for hardware compromises.
Depending on one's security needs, it might be useful to get a separate,
isolated, never-connected-to-the-internet computer specifically for
high-security needs. (See
https://www.schneier.com/blog/archives/2013/10/air_gaps.html for some
pointers.)

5. Smartcards are also useful, as you can generate keys on your isolated
computer, back them up safely, then copy the keys to the smartcard. You
can then use the smartcard on your everyday system without risk of
exposing the private keys. I have an RSA primary key on one smartcard
and RSA signing/encryption subkeys on another smartcard. (I also have a
third card which has the RSA subkeys for the key I mentioned in point #3
above. I rather like smartcards.)

Cheers!
-Pete

Cheers!
-Pete

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

Re: Duplicating smartcard

[Pete Stephenson]

On Sun, Nov 10, 2013 at 11:50 AM, Alexander Truemper
hasgar...@hellshell.de wrote:
 Hello everyone,

 since I could not reveal anything useful on google, here my question.

 I want to have a safe backup of my smartcard which contains my primary
 key and two subkeys.

Did you generate the keys on the smartcard, or did you generate them
on the computer and then later transfer them to the smartcard?

If you generated them on the card itself, you cannot backup the keys.

If you generated them on the computer, you can back up the keys to
other media prior to transferring the keys to the smartcard. Once
they're on the card the private keys cannot be exported.

 I guessed the private keys can not be exported as it would make no
 sense then to have a smartcard.

Correct.

 But if I run 'gpg --export-secret-keys' for my keys, it actually seems
 to export the private keys according to pgpdump.

 How can this be? (I see no smartcard activity on the terminal and no
 PIN is asked)

It exports the stub private keys that, in essence, say The actual
private keys exist on the smartcard with $SERIAL_NUMBER. These stubs
are not private at all, and contain no actual key material.

Cheers!
-Pete

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

Re: 2048 or 4096 for new keys? aka defaults vs. Debian

[Pete Stephenson]

On Thu, Oct 31, 2013 at 10:02 PM, Hauke Laging
mailinglis...@hauke-laging.de wrote:
 Am Do 31.10.2013, 16:31:02 schrieb Daniel Kahn Gillmor:

 http://www.enisa.europa.eu/activities/identity-and-trust/library/deliverable
 s/algorithms-key-sizes-and-parameters-report

 There is one point I don't understand:

 [3.6 Recommendations]

 there is general agreement this should be above the 100-bit level

 for long term use AES-256

 But this http://eprint.iacr.org/2009/317 (mentioned by the German Wikipedia
 article for AES) claims that AES-256 was down to 99.5 bits.

That attack is only valid if different messages have related keys. If
the keys are chosen randomly, the attack does not apply. I'm not aware
of any crypto system that implements AES with related keys (though if
anyone knows of some, I'd like to know so I can avoid it).

See https://en.wikipedia.org/wiki/Related-key_attack and
https://en.wikipedia.org/wiki/Advanced_Encryption_Standard#Security
for details .

According to the Wiki, the best attack on full-round AES-256 not using
related keys requires 254.4 operations (see
https://research.microsoft.com/en-us/projects/cryptanalysis/aesbc.pdf
).

Cheers!
-Pete

-- 
Pete Stephenson

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

Re: gpgsm and expired certificates

[Pete Stephenson]

On Sun, Oct 27, 2013 at 9:53 AM, Uwe Brauer o...@mat.ucm.es wrote:
 Werner == Werner Koch w...@gnupg.org writes:

 On Sat, 26 Oct 2013 22:03, o...@mat.ucm.es said:
 know by the date of the certificate which certificate to use for which
 message?

 -  old for old messages

 Note, that there is no need for a certificate for decryption - only the
 private key is required.  The certificate is only used to show some meta
 information.

 Now I am confused. Most likely my knowledge of certificates is not
 correct. (I played around with openssl to generate my own, useless,
 certificates).

 I thought a certificate consists of a key pair (private/public) which is
 signed by the Authority (here comodo).

Mostly correct.

All that is needed to encrypt/decrypt/sign/verify messages is the
public/private keys themselves. The certificate is a signed,
structured format that binds a particular public key to an identity
(be it an email address, a name, a website, etc.). The certificate is
for public consumption: Comodo is asserting to the world that this
particular public key (and it's corresponding private key, which only
you know) belongs to you (or your website, email, etc.).

On your end, all you need is the private key to decrypt messages
encrypted to your public key. You don't need a certificate to decrypt
messages that had already been encrypted to that public key -- a
certificate may expire at a certain time, but the private key has no
baked-in expiration date.

 When I apply for a certificate, the keypair is generated by the crypto
 module of the browser and then signed.

Correct.

 So I thought when I apply for a new certificate  a new key pair
 is generated which gets signed again.

Correct, though it is possible (but usually recommend against) to
create a new certificate using the same private keypair as before. In
general, you should create a new keypair when applying for a new
certificate.

 But your comment above seems to indicate that the old pair gets a new
 signature. Is this correct?  But what if I apply with a different
 browser I applied the last time.

I interpreted Werner's comment to mean In order to decrypt messages
encrypted to you, you only need a private key. You don't need a valid
certificate to decrypt old messages that were encrypted to a
now-expired certificate.

If you generate a new keypair for the new certificate (which is
probably a good idea) then gpgsm (and presumably any other
certificate-using software) will figure out what private key will be
needed to decrypt a particular message and, so long as you still have
the private key on your system, will use it as needed even if the
corresponding certificate has expired.

Cheers!
-Pete

-- 
Pete Stephenson

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

Re: gpgsm and expired certificates

[Pete Stephenson]

On Sun, Oct 27, 2013 at 11:01 AM, Uwe Brauer o...@mat.ucm.es wrote:

 If you generate a new keypair for the new certificate (which is
 probably a good idea) then gpgsm (and presumably any other
 certificate-using software) will figure out what private key will be
 needed to decrypt a particular message and, so long as you still have
 the private key on your system, will use it as needed even if the
 corresponding certificate has expired.

 So gpgsm (and others) will also figure out which private key to use for
 signing: that is the new one, once the old certificate is expired?

 Which means in the case of smime, also to embedd the corresponding
 new public key in the signature.

I can't speak specifically for gpgsm, as I only use GPG with OpenPGP
keys and not x.509 certs, but I would venture that the answer to your
question is yes, gpgsm will select the correct private key for
signing as that's standard behavior for such software.

Werner or others could answer authoritatively.

-- 
Pete Stephenson

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

Re: 2048 or 4096 for new keys? aka defaults vs. Debian

[Pete Stephenson]

On Fri, Oct 25, 2013 at 2:19 AM, Christoph Anton Mitterer
christoph.anton.mitte...@lmu.de wrote:
 On Thu, 2013-10-24 at 21:05 +0200, Sylvain wrote:
 Is this zealotry on the Debian front, or something to update in gnupg?
 As they write,... they don't see a specific (i.e. technical or
 performance) reason not to do so.

 Some people may argue that 2048 is secure enough for many many years to
 come. Similar things have been said for 1024 not so many years ago.

 And especially under the light of the NSA/friends scandal,... why using
 less when you have no strong reasons to do so?

In my particular case, I mainly use GnuPG with emails and RSA
signatures tend to be quite large and unwieldy for non-GnuPG-using
users, mailing lists, etc. when one uses 4096-bit keys. As a
compromise, I use a 4096-bit primary key (used only for certifying
keys) and 2048-bit subkeys for encryption and signing, thus keeping
signature sizes a bit more manageable. This also lets me periodically
rotate subkeys as needed.

For Debian devs, the signatures are (mostly?) used for package signing
and so an extra few hundred bytes isn't really a big deal as it's rare
for anyone to actually see the signature itself as it's processed
automatically by the package manager. In their case, there's no
specific reason to *not* use 4096-bit keys.

It all depends on your use case, I suppose.

Cheers!
-Pete

-- 
Pete Stephenson

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

Re: New GPLv3 OpenPGP card implementation (on a java card).

[Pete Stephenson]

On Wed, Oct 16, 2013 at 11:40 AM, Werner Koch w...@gnupg.org wrote:
 On Tue, 15 Oct 2013 11:41, p...@heypete.com said:

 Also, are there any smartcards out there that would support DSA/ELG
 keys? All the cards I've seen and used support RSA only.

 You don't want DSA on smartcards - at least not until they are able to
 do deterministic DSA (rfc-6979).

I knew that DSA fails catastrophically with low entropy (where
catastrophically = leaking the private key), but I would hope that
any DSA-capable smartcard would have a decent hardware RNG built in.

I'm not familiar with RFC 6979. Thanks for the link. It's good to see
people taking that issue into account.

Cheers!
-Pete

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

Re: trust your corporation for keyowner identification?

[Pete Stephenson]

On Wed, Oct 16, 2013 at 2:04 PM, Brian J. Murrell br...@interlinx.bc.ca wrote:
 If you worked in a corporate environment, would you trust the HR
 department there to have verified the identity of employees well enough
 to leverage that into signing a GPG key?

In general, I'd be fine with that. Corporations generally need a
fairly large amount of information about their employees (e.g. for tax
purposes) and so should be able to verify the identity of employees
with a high degree of confidence.

 Let's say such an environment had an messaging system where employees
 had to authenticate with their corporate IT credentials in order to use
 the system.  Would that, and the assertion by HR/IT that a message that
 I get from Bob really did come from the employee HR verified as Bob
 (i.e. when they hired him) be enough for you trust the key you get from
 Bob enough to sign it that it really is really Bob's?

 I guess what I am describing is a virtual key signing party where the
 verification of IDs is being done by the corporation instead of the
 individuals.

In my specific case, I only publicly sign (as opposed to locally sign)
keys when I have (a) personally met a person and verified their ID and
key fingerprint/details or (b) a person is well-known to me (e.g. a
family member, long time friend, etc.) and they provide me their key
fingerprint and communicate in a way that I can verify who they are
(e.g. I call them on the phone, recognize their voice, and they read
me their key fingerprint).

I would be reasonably sure that a key signed by an HR department
actually belongs to the named person, but I wouldn't publicly assert
that by signing their key.

Your mileage may vary. :)

Cheers!
-Pete

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

Re: trust your corporation for keyowner identification?

[Pete Stephenson]

On Wed, Oct 16, 2013 at 4:20 PM, Johan Wevers joh...@vulcan.xs4all.nl wrote:
 On 16-10-2013 15:28, Pete Stephenson wrote:

 I would be reasonably sure that a key signed by an HR department
 actually belongs to the named person,

 Although I would certainly NOT assume that that person would be the only
 one with access to the secret key. Most companies would keep a copy.

Good point. That would definitely throw a wrench in the system.

Cheers!
-Pete

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

Re: New GPLv3 OpenPGP card implementation (on a java card).

[Pete Stephenson]

On Tue, Oct 15, 2013 at 7:42 AM, Ann O'nymous c6.321197...@gmail.com wrote:
 If anyone is interested I wrote a java card implementation of the OpenPGP
 card and released it under the GPLv3

Excellent!

 Features and limitations:
 - 2048 bit RSA keys only

Is this a hardware limitation, or could it be increased in the future?

Also, are there any smartcards out there that would support DSA/ELG
keys? All the cards I've seen and used support RSA only.

Cheers!
-Pete

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

Re: OpenPGP Smartcard + signing email = two signatures?

[Pete Stephenson]

On 10/11/2013 10:40 PM, John Clizbe wrote:
 Nothing nefarious going on, nor is it a bug. Take a look at the source of your
 PGP/MIME signed email.
 
 This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
 --===0134039850==
 Content-Type: multipart/signed; micalg=pgp-sha512;
 --^
  protocol=application/pgp-signature;
  boundary=hORQu9nh08cKrD0xFen8m9Kf4P5mAgQLH

 This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
 --hORQu9nh08cKrD0xFen8m9Kf4P5mAgQLH
 Content-Type: text/plain; charset=ISO-8859-1
 Content-Transfer-Encoding: quoted-printable

 message
 boundary
 signature attachment
 boundary
 --===0134039850==
 
 In order for Enigmail to generate the outside email header
 (multipart/signed...), it has to know the digest that will be used later to
 construct the signature part, in this case SHA-512, but all the message
 processing happens in a single pass with the signature part at the end.
 
 To do this, a small test message is signed and then examined for the digest
 that was used. This is the first time you are asked for your PIN. The second
 is when the message signature part is being generated.

Aha, that explains it! Many thanks.

I never really made the connection between that section in RFC 3156 and
this behavior.

 We used to see this on the Enigmail list a lot as folks started using
 gpg-agent instead of Enigmail's more limited internal passphrase caching.
 With no PIN/passphrase caching in effect, I'd expect you to be asked twice on
 PGP/MIME messages, but only once on inline OpenPGP.

Oddly, this doesn't always happen, even with the force signature PIN
bit set on the smartcard.

That is, in-line signing only requires one PIN entry. PGP/MIME
often requires the PIN to be entered twice, but not always.

Some informal testing over the last few minutes seems to suggest that
I'll be prompted for the signature PIN twice when sending the first
PGP/MIME message of a particular Thunderbird session. If I don't exit
Thunderbird and send other PGP/MIME messages then I will only be
prompted once for each signed message. Exiting Thunderbird and
re-opening it resets stuff, so I'm again prompted for two signature PINs
on the first PGP/MIME message but only one on following messages.

Does Enigmail cache the hash type used for the signature for a length of
time (say, the duration that Thunderbird remains open) so it doesn't
need to prompt for two signature PINs?

 HTH,
 
 -John

It does indeed. Thank you.

Cheers!
-Pete


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

Re: OpenPGP Smartcard + signing email = two signatures?

[Pete Stephenson]

On 10/1/2013 7:48 PM, Peter Lebbing wrote:
 On 30/09/13 23:10, Pete Stephenson wrote:
 Has anyone else observed this behavior? If so, is there an explanation?
 
 It's probably a benign bug, but it would obviously also be a reasonably good 
 way
 to get signatures if somebody had compromised your PC. Put a payload in GnuPG
 such that when you try to sign something, it will first sign the attackers
 message with your first pinentry prompt, and then just prompt again for your
 signature. People who work with computers generally just try again if the 
 first
 time mysteriously failed.

Indeed. I assumed it was merely a bug rather than something with
malicious intent, as it occurred even with fresh-from-the-CD VMs that I
was testing. I assume the bug also occurs without the force signature
PIN bit enabled on the smartcard and with non-smartcard based keys.
I've been in touch with Olav at Engimail and provided him with debugging
information that might help.

And yes, if one's computer was compromised  then this is a good way for
a bad guy to get signatures. In my case, I take reasonable precautions
to prevent compromise and, while I can't prove it, I am reasonably
certain that my systems are clean. (Let's hop!)

 This does presume that you enter your PIN on the cardreader, because otherwise
 it would be simpler to just use the PIN you give to the PC :).

In this particular case, I'm using card readers without built-in PINpads
(one is USB and connected to a desktop system, the other is integrated
into a laptop) -- I'm being prompted for the pin by PINentry, which
comes with GnuPG2.

 But I think it's more likely there's a little bug somewhere that loses the 
 message.

That's my thought too. I'll post any updates to this thread.

Cheers!
-Pete




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

OpenPGP Smartcard + signing email = two signatures?

[Pete Stephenson]

Hi all,

I use Thunderbird, Enigmail, and GnuPG on Windows 7 (among others).

I have my primary cert/sign key on one smartcard and two subkeys
(signature + encryption) on another. I have the force signature PIN
option enabled for both cards.

Tonight I was using the card with the subkeys to sign an email message
that I was sending. As expected I was prompted by pinentry to enter the
card PIN and that the card had made N signatures before. I entered the
PIN and immediately pinentry popped up again asking for me to re-enter
the PIN and indicated that N+1 signatures had been made before,
suggesting that it had made the previous signature. Again, I entered the
PIN and the message was correctly signed and everything seems to work
normally. There is only one signature on the message -- it seems that
one of the signatures goes missing.

I've noticed this happening intermittently over the past few months, but
only when using Enigmail and Thunderbird -- if my memory serves me right
it also happens intermittently when I use Ubuntu Linux on a different
computer, Thunderbird, and Enigmail so it doesn't seem to be a
Windows-specific problem.

Although this has happened for a while, it's only happened
intermittently and I can't reproduce it on demand (e.g. it happened to
the first signed message I sent today, but not the second. It occurred
when I tried signing this message.) Has anyone else observed this
behavior? If so, is there an explanation?

Cheers!
-Pete



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

Re: Question about a perfect private Key store for today's environment

[Pete Stephenson]

On Sat, Sep 21, 2013 at 11:06 PM, Aleksandar Lazic
al-gnupg_us...@none.at wrote:
 What could be a perfect or at least a very good storage of the
 private Key.

Probably a smartcard -- this keeps your key entirely on the card and
it is not accessible to the computer (that is, a bad guy with control
of your computer cannot extract the key from the card).

It's almost certainly possible that a well-equipped adversary with
chip-disassembly equipment (read: a major government) could physically
take apart the chip and read the data off the internal parts directly,
but that's a different story altogether. Personally, I use a smartcard
to prevent my private keys from being revealed if my computer is
compromised by malware or some other sneaky stuff. If someone is
willing to go through with seizing my smartcard and taking it apart, I
have bigger problems. :)

 My definition of today's user environment:

 1.) Private  mobile device, tablet, notebook with private E-Mail program
 2.) Business mobile device, tablet, notebook with company E-Mail program
 with company key and private key
 3.) Private  mobile device, tablet, notebook with Web mail only access
 4.) Business mobile device, tablet, notebook with Web mail only access
 5.) more to defined

 There are for different clients different tools available but the problem
 from my point of view is that you must always add your private key into the
 different clients.

 This is a lot of work and sometimes not possible as in point 3+4 defined.

 Point 1+2 are also not very secure due to the fact that nobody knows what
 really happen on such devices.

Well, #1 is probably the most secure: it's your own device and your
own mail client (e.g. Thunderbird).

#2 is probably the least secure, as the company has access to your private key.

 There are some HW-Solutions like

 http://g10code.com/p-card.html
 http://shop.kernelconcepts.de/product_info.php?cPath=1_26products_id=133osCsid=503b6045b0863ea8f4bc84757e89ee81

 but how could this or other HW-Solutions be usable along with Point 1+2
 definitions?

Easy: many mail clients have OpenPGP support built-in, or available
through an add-on like Enigmail for Thunderbird. Many can read the
smartcard and handle the encryption/decryption/signing operations
through the normal interface. Even without a smartcard, they can
access one's keyring and perform the various operations.

 In case you have your own server with your own web mail solution like
 roundcube, Horde or any other and you have secured your private Key on this
 server then you have a solution for point 3+4  but not for 1+2.

I'm not sure how much I'd trust a web service, even one operated by
myself or a company, with my private keys. I'd much rather keep them
on a smartcard, accessible only to myself.

 What solution is available for public Web mail providers like gmail, gmx,
 hotmail,  .?

Gmail permits access with mail clients (e.g. Thunderbird), so one
could use such a client in conjunction their OpenPGP software to send
and receive encrypted mails.

For webmail-only providers, you'd need to compose your message offline
(say in a text editor like Notepad or something similar), then perform
the encrypt/sign operations, then copy-paste the encrypted/signed
output into the webmail compose window.

 What are your opinions about the thought above?
 What are your solution which you use?

Usability is a big concern, and it's difficult with webmail-only
services that people use these days. It becomes much more
straightforward if one uses a mail client program.

Cheers!
-Pete

-- 
Pete Stephenson

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

Re: Sign key and export for each UID

[Pete Stephenson]

On Mon, Sep 16, 2013 at 9:45 PM, MFPA expires2...@ymail.com wrote:
 On Monday 16 September 2013 at 7:57:04 PM, in
 mid:52375480.7020...@dougbarton.us, Doug Barton wrote:
 I have another philosophy that works for me because I
 prefer not to sign uids that are not valid.

 What, in your opinion, makes a UID not valid?

I can't speak for Doug, but I consider UIDs corresponding to
no-longer-functioning email addresses to be invalid and won't sign
them as I have no idea if the keyholder is the actual owner of that
address.

-- 
Pete Stephenson

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

Re: Pgp key

[Pete Stephenson]

On Sun, Sep 15, 2013 at 6:54 PM, Jack Szary jgsz...@gmail.com wrote:
 I have someone's PGP key and he said to use that to send him information, how 
 do I use his key to send him a message?

Hi Jack,

Do you have GnuPG (or some other OpenPGP-compatible software) installed?

If so, do you already have your own PGP key?

Cheers!
-Pete

-- 
Pete Stephenson

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

Re: newbie and smartcard, I'm lost.

[Pete Stephenson]

On Fri, Sep 13, 2013 at 3:33 PM, Didier
gnupg-us...@wiroth.neomailbox.net wrote:


 Hi,
 I'm a newbie ... and I would like to do file and mail encryption from
 different PCs at different locations with gnupg.
 In any case I would not like to copy my private key on other pcs!
 As far as I understood, using a smartcard was the ideal solution as I won't
 have to store my private keys on each pc. I would simply have to use my
 smartcard f.ex. to encrypt a file with my private key on a given PC when I
 need to.

Indeed. Sounds like a good plan.

 1) Why did gpg create a secret key file secring.gpg  in the %appdata%\gnugpg
 directory, shouldn't the secret key file only be stored on the smarcard?

GPG creates a pseudo-secret key that includes stubs that tell GPG
that your private key is located on a card number with serial number
13B1. This pseudo-secret key (there's not actually anything secret
about it, as it's just the stubs) is stored in the secring.gpg.

The private key was generated entirely on the card and cannot be exported.

 Now I'm simulating a move to another computer and I'm renaming the
 %appdata%\gnugp to %appdata%\gnupg.old
 Now I'm reissuing the gpg2 --card-status command:
 gpg: keyring `C:/Users/test/AppData/Roaming/gnupg/secring.gpg' created
 gpg: keyring `C:/Users/test/AppData/Roaming/gnupg/pubring.gpg' created
 Application ID ..: D27600012401020513B1
 Version ..: 2.0
 Manufacturer .: ZeitControl
 Serial number : 13B1
 Name of cardholder: Test Test
 Language prefs ...: fr
 Sex .: male
 URL of public key : [not set]
 Login data ...: [not set]
 Signature PIN : forced
 Key attributes ...: 2048R 2048R 2048R
 Max. PIN lengths .: 32 32 32
 PIN retry counter : 3 0 3
 Signature counter : 5
 Signature key : F699 1939 18B7 C5E1 B01D  2D43 17D9 B703 7289 B2FC
   created : 2013-09-13 12:59:23
 Encryption key: E0A0 95F9 646A 95ED F3E5  49A2 428B F92C 9E5C 75ED
   created : 2013-09-13 12:59:23
 Authentication key: B925 6ED8 BEF6 F17F 7A4D  4E4E F5DC BD13 9899 BBE7
   created : 2013-09-13 12:59:23
 General key info..: [none]

 2) Why is General key info empty now?
 If I do a gpg2 --list-keys, no keys are listed anymore.
 3) How can I encrypt a mail or file with my smartcard now on another PC
 without copying any files?

If I remember correctly, you need to import the public key (whether
from the keyserver, a flash drive, or some other storage medium) to
that computer, insert the card, run gpg --card-status, the General
Key Info will be correctly populated, and new pseudo-secret stubs will
be created, and you'll be able to use the smartcard on that system.

If you put your public key online somewhere (say on your website, by
itself, in a text file) you can program that URL into your smartcard
in the URL of public key section (gpg --card-edit, admin, url). When
you get to a new computer, you can insert the card, run gpg
--card-edit, then run fetch and GPG will fetch the public key from
that URL. If there's no URL entered then I think it will attempt to
retrieve the public key from the keyserver but you might want to
check.

Cheers!
-Pete

-- 
Pete Stephenson

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

Re: Why trust gpg4win?

[Pete Stephenson]

On Wed, Sep 11, 2013 at 11:01 AM, Jan takethe...@gmx.de wrote:
 On 10/09/2013 15:18, NdK wrote:

 You'd be exposed nearly to the same attack vectors. Plus some more (the
 ones that handle the extra layer), so you'd have to check more code.

 So what about using that free USB stack for AVR's to implement a flash
 device?  You would be able to audit about everything; flylogic even has
 these nice pictures of the ATmega88 masks...

 Sorry, I don't follow your reasoning here.
 Pete proposed to use an USB-to-Serial interface to avoid attacks against
 the USB stack on the PC. Why should an AVR be used to implement a flash
 device?


 Maybe Pete meant such an USB-to-Serial interface
 http://www.robotsimple.com/Computer_Interface/USB_to_Serial_Adapter ?

Actually, I was thinking of something that was the exact opposite:
some device (which I don't think exists) that would allow one to
connect a USB flash drive to the device, and have the device convert
that into RS232 serial data for the computer, thus avoiding any USB
interaction with the computer itself. The computer would then need to
process the serial data to read or write files on the drive. As far as
I know, nothing like that exists and I'm not sure if it'd be possible
to do. Even if it was possible, it'd be immensely slower than normal
USB connections.

My thought was that since serial is older and simpler than USB that it
would be possible to better audit and secure the connection between
the flash drive and the computer using such a method. My idea was
derived from one of the ways CAcert keeps their root certificate
secure: the signing system is kept offline, but is connected via a
serial cable to an online computer (e.g. the web server). The simple
daemon that listens on the serial port of the signing system will only
respond to requests for signing things but they did not implement any
file-transfer-over-serial functionality so it would (presumably) be
impossible to compromise the root certificate remotely. My idea would
be for something similar, but with file-transfer capability over
serial.

The device you linked to, which is quite common, is the opposite: one
can connect a serial device (say a microcontroller, a UPS, etc.) to
the device, which converts it to USB and transmits that data to the
computer. The device appears as a serial port on the computer.

In brief, the device you linked to tunnels serial-over-USB. My thought
was to do filesystem-access-over-serial.

Mine is probably a very silly idea and I was basically throwing the
idea at the wall to see if it'd stick. :)

-- 
Pete Stephenson

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

Re: Problems using 10kbit keys in GnuPG instead of 4kbit keys

[Pete Stephenson]

On Tue, Sep 10, 2013 at 3:31 PM, Ole Tange ta...@gnu.org wrote:
 I have not heard of the primary certification key before. Is it the
 'C' in 'usage: SCEA'?

Yes. The certification key is used when signing (more properly,
certifying) other people's public keys.

A signing key can be used for signing files or messages but the
certification key is used for signing other people's keys.

In short, it's the primary key.

 Can that be changed without losing signatures on the public key? If
 so, then the size of that can be increased slowly when needed.

Unfortunately not. It is the primary key and its properties (e.g. key
length) cannot be changed.

Cheers!
-Pete

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

Re: Some doubts about signature procedure

[Pete Stephenson]

On Mon, Sep 9, 2013 at 10:42 AM, Francesco C.
anything.everythin...@gmail.com wrote:
 Hi, here I come back to ask you some clarification about the signature
 procedure.
 The purpose of signature procedure is making sure of anybody can't modify
 the file you're trying to send.

 Many times they use also the check of Md5sum or SHA512Sum, but anyway my
 question is:

 if any spiteful person succeed in tapping a file transmission of mine, he
 surely succeed in signing the modified file. So how can my addressee realize
 of that?

 In other words, if this spiteful person succeed in replacing a modified file
 in a server he also succeed in replacing also the signature file, doesnt'
 he?

Hi Francesco,

That's a good question! The short answer to the question is there's
more to a PGP signature than just the hash of the file.

In the situation you propose where a file and a hash (for example, the
sha512sum) are publish on a server, an adversary with access to that
system could modify the file and simply add a new, correct sha512sum
for the modified file. There's no way to bind the hash of the file to
the identity of the person who produced the hash. Put another way,
there's no way to tell if the hash was produced by the proper person
or a bad guy.

However, PGP signatures have more than merely the hash of the file --
when PGP (or GnuPG or any other program that implements the OpenPGP
standard) produces a signature, it produces a hash of the file and
encrypts the hash with the signer's private key. The signature is then
included with the file. (Of course, this is a very simple, general
description of what happens. There's a lot more details but this
simple explanation should suffice for now.) This binds someone's
identity to the signature.

Let's say that Alice wants to sign a file. She calculates a hash of
the file, then encrypts the hash with her private key.

Bob downloads the file and wants to verify the signature. He
calculates the hash of the file. Next, he uses Alice's public key
(which is widely available) to decrypt the hash. If the decrypted hash
from Alice and the hash he calculated himself match, then he knows
that the file has not been modified since Alice signed it.

Additionally, since only Alice's public key can decrypt a message
signed with Alice's private key, he knows that only Alice (or, more
generally, someone with Alice's private key) could have produced the
signature. Unless he has Alice's private key a bad guy cannot forge
signatures to appear to come from Alice.

Put very simply, a hash can show that a file has not been altered
since the hash was generated but it provides no assurance as to *who*
produced the hash. A signature provides assurance of both integrity
and authentication: someone verifying the signature can check that the
file has not been altered but also that the signature was produced by
a specific person.

Of course, this assumes that Bob has the public key that actually
belongs to Alice. This can be accomplished by meeting in person,
exchanging public key details over the phone (if they recognize each
other's voices), etc. It's not uncommon for people to meet up at a
keysigning party (see
https://en.wikipedia.org/wiki/Key_signing_party ), verify each other's
identity and public key details, and then digitally sign each other's
keys. In such a way, people establish a Web of Trust where different
people vouch for the identity of each other.

You might find more details about digital signatures at
https://en.wikipedia.org/wiki/Digital_signature . There may also be a
Wikipedia article that describes signatures in your own language.

 In this case I can't understand the benefit of signing procedure.
 I'm sorry if my exposure was not as good as an english professor :p but I
 promise next times it wil be better and better.

Your English is quite good.

Cheers!
-Pete

-- 
Pete Stephenson

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

Re: SSL on gnupg.org

[Pete Stephenson]

On Mon, Sep 9, 2013 at 3:19 PM, Werner Koch w...@gnupg.org wrote:
 Due to public demand I enabled https for www.gnupg.org on v4 and v6.  IT
 is a 2048 bit CaCert certificate, so you need to install the cacert root
 certificate.

Excellent.

 Note also that recent Mozilla browsers tell you in the certificate
 details that they can't verify the certificate because it uses an
 insecure algorithm - which seems to be SHA-1.  Now if SHA-1 would be the
 weakest link in the whole web security domain we could easily solve all
 problems.  It is just funny how they try to fix a broken infrastructure.

According to 
https://www.ssllabs.com/ssltest/analyze.html?d=www.gnupg.orghideResults=on
that's because the CAcert Class 3 intermediate cert was signed using
MD5, which is indeed insecure for such purposes. See
http://www.win.tue.nl/hashclash/rogue-ca/

They have a newer Class 3 intermediate cert at
http://www.cacert.org/index.php?id=3 that is signed by the CAcert root
using SHA256. Simply swapping out the intermediates should solve the
issue.

Personally, I prefer the free certs issued by StartSSL as their root
is installed by default in most systems/browsers. The CAcert root
isn't (yet -- there's a bunch of work needed to be done to get the
CAcert root to pass an audit and be included). Your mileage, of
course, may vary.

-- 
Pete Stephenson

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

Re: How can I send a public key exported with --armour option?

[Pete Stephenson]

On Sun, Sep 8, 2013 at 8:37 AM, Francesco C.
anything.everythin...@gmail.com wrote:
 Hello everybody, I'm a beginner of Gpg and encryption's world in general, so
 I apologize if my questions will be so banal.

Hi Francesco,

Welcome! No need to apologize! We're all pretty friendly here. :)

 I created a new pair of public-private keys and now I'm trying to export the
 public one.

Excellent.

 I read the How-To and it describe the more useful option --armour. I can't
 understand how to send a ASCII text print on my screen to an other user.

 Is not more useful the --output options?

You can add --armor (or --armour, I had no idea that GnuPG
supported the British spelling of the word. Interesting!) to
essentially any command that involves data being output. For
consistency I will use the spelling without the u, but both are
equivalent.

For example, if you created a key with the KeyID of KEYID, you could
export the public key for it to the terminal using gpg --export
--armor KEYID.

If you wish to export the public key to a text file which you can then
include in an email, post on the web, etc., you could use gpg
--export --armor KEYID  filename.txt where 'filename' is whatever
you wish the file to be called.

The armor feature is indeed quite useful, but it comes at a slight
cost: armored files/messages are slightly larger than their unarmored,
binary counterparts.

Cheers!
-Pete

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

Re: Issues with primary key subkeys on different smartcards

[Pete Stephenson]

On Sat, Sep 7, 2013 at 9:45 AM, Paul R. Ramer free10...@gmail.com wrote:
[snip]
 It seems that the keytocard command is the way to correctly load the
 subkeys and primary key onto the smartcards.  I had not thought about
 splitting the primary and subkeys across the two smartcards, but it
 works quite easily by using the keytocard command.  I tested it to see
 how it works, and I feel certain that the keytocard method that you used
 is the correct way to do it.
[snip]

Hi Paul,

Indeed, the keytocard command is the correct way to load the keys onto
the cards and to generate the stubs initially. As you mention, that
works as expected and generates the correct stubs pointing at both
cards.

The issue I'm running into is not the initial loading of the private
keys onto the cards, but rather if I'm trying to use the cards on a
computer that does not already have the private keys.

If I start on that new computer with only my public key, insert one of
the two cards (e.g. the card containing my primary key) and run gpg2
--card-status, GnuPG will generate a private key stub that points at
that card. That's fine and works as expected. However, if I try doing
the same thing with the second card (the one with my subkeys), the
stub is not added. Only the details of the second card are displayed,
but the stub pointing to that card is not added.

This is not what I expected: I expect that GnuPG will add a stub for
each of the cards after I run --card-status for each card, but this
doesn't happen and only the stub for the first card (i.e. whichever
one I use with --card-status first) is added.

In short, I expect to be able to get the same result using
--card-status and both cards as I do when I use keytocard to
initially move the keys to the cards, but this does not occur.

 Now you are done, and the cards work great.  If you need either the
 primary key or subkey, pinentry will prompt you to insert the
 appropriate card.  The only thing is that if you need a backup of the
 secret keys before moving them to the smartcards, you need to do that
 before following the example above.

Right, I definitely have backups, but it's always a good thing to
remind people. :)

 Anyway, Pete, thank you for bringing this subject up and experimenting
 with it and helping make us all a little smarter.  I can't answer the
 question as to whether it was designed to work that way, but I don't
 feel there is any doubt.

You're welcome.

If it is designed to work that way, I respectfully ask that the
developers consider changing how it works so that keytocard and
--card-status both produce the same key with stubs pointing to each
respective card. The way it currently works, where --card-status will
only add one stub to a key, is not what I would expect to happen.

As my programming abilities are not sufficient to make a patch to
change this behavior, I'd be happy to offer a financial contribution
if someone with more skill were to give it a shot.

Cheers!
-Pete

-- 
Pete Stephenson

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

Re: NSA backdoors and Set Preferred Cipher

[Pete Stephenson]

On Sat, Sep 7, 2013 at 2:11 PM, Mike Acker mike_ac...@charter.net wrote:
 a lot of information has been reported recently regarding NSA an back-door
 entries behind digital encryption

 attached are some notes I offered recently on the MINT forum

 i have altered my cipher preference list as follows

 TWOFISH CAST5 BLOWFISH 3DES AES AES192 AES256 CAMELLIA128 CAMELLIA192
 CAMELLIA256

 based on recent revelations we should probably not use any commercially
 offered cipher

Hi Mike,

Interesting. Would you care to explain your logic as to why you set
the preferences in that particular order?

In particular, why did you prioritize 3DES over the three AES
variants? I can understand being skeptical of CAMELLIA, as it was
developed commercially, though it has been approved for use by both
the Japanese CRYPTREC project and the European NESSIE project and is
widely available to researchers and cryptographers. That is, it's not
a black box.

Similarly, AES is an open standard and went through rigorous review by
both government and the public cryptographic community.

As far as I'm aware, all the ciphers used in GnuPG have no major,
publicly-known cryptographic weaknesses so the choice as to which ones
to use comes down more to a matter of personal preference and
compatibility reasons.

-- 
Pete Stephenson

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

Re: Issues with primary key subkeys on different smartcards

[Pete Stephenson]

On Thu, Sep 5, 2013 at 8:35 PM, Pete Stephenson p...@heypete.com wrote:
[snip]
 I wish to have a single private key file in my GnuPG keyring that
 includes stubs to the primary key on smartcard #1 and the subkeys on
 smartcard #2. This way, if I need to certify a public key belonging to
 someone else I will be prompted to insert smartcard #1. If I wish to
 sign a message or decrypt an encrypted message sent to me I will be
 prompted to insert smartcard #2.
[snip]

Hi all,

Quick followup: I was also able to create the correct private key with
stubs pointing at both smartcards by loading the actual private keys
onto the smartcard using keytocard, as expected.

However, I'm unable to re-create this file starting only with the
public key and running gpg2 --card-status for each card. It seems
like running gpg2 --card-status for each card should be able to
create the stubs, but if there's already a stub associated with a
particular smartcard, then running gpg2 --card-status doesn't seem
to have any effect other than to display the card info.

Put simply: running gpg2 --card-status will create one stub pointing
at the card, but running that command again with a different card only
displays the card info and doesn't add any additional stubs. This
seems inconsistent and not what I would expect.

Sorry again for the really long previous message.

Cheers!
-Pete

-- 
Pete Stephenson

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

Issues with primary key subkeys on different smartcards

[Pete Stephenson]

. Run gpg2 --export-secret-keys KEYID  subkeys-stub.key to export
a private key file containing the stubs of the subkey.
6. Run gpg2 --delete-secret-keys KEYID to delete the subkey stubs
from the keyring. Only the public key remains in the keyring.
7. Put each exported key file into a separate directory, then run cat
primary-stub.key | gpgsplit and cat subkeys-stub.key | gpgsplit in
the respective directories to separate the keys into packets.
8. Move the subkey stub packets from their directory into the primary
key directory, overwriting the subkey packets in the primary key
directory.
9. Run cat *  complete.key in the primary key directory to
reassemble the key file.
10. Run gpg2 --import complete.key to import the reassembled key file.
11. Success! Everything works as expected: running gpg2 --edit-key
KEYID, then toggle shows that the primary key and the subkey stubs
exist and point at their respective cards. Certifying a key requires
smartcard #1 and signing/decrypting messages requires smartcard #2.

Although this was successful, I think that it's something that should
be doable within GnuPG itself rather than by splitting keys and
working manually on packets.

Cheers!
-Pete

-- 
Pete Stephenson

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

Re: AES256 AES192. (Was: Can I revitalise an old key-pair?)

[Pete Stephenson]

On Mon, Sep 2, 2013 at 8:28 PM, Nicholas Cole nicholas.c...@gmail.com wrote:
 On Mon, Sep 2, 2013 at 5:04 AM, Henry Hertz Hobbit
 hhhob...@securemecca.net wrote:

 [snip]


  Paradoxically, AES256  AES192 had
 weaknesses that made them less safe than AES (AES-128) several
 years back.  May I humbly suggest TWOFISH or one of the
 CAMELLLIA ciphers as a first choice UNTIL you determine whether
 or not the fixes for AES-256 and AES-192 are retroactive?  DID
 THEY GET THEM FIXED?  I am just assuming they did but that means
 I HOPE the older implementation and the newer one can easily be
 discerned when you do the decipher.


 [snip]

 I was curious about this. The wikipedia page mentions the Related Key
 Attack on these cyphers, but is vague about whether they were ever
 fixed.

 Does anyone know?

 And did fixes make it into the version used by Gnupg?

Even more importantly, were they ever an issue with GnuPG in the first place?

That is, does GnuPG generate related keys?

I was always under the impression that GnuPG randomly generated
session keys rather than creating related session keys; if true,
wouldn't this mean that the related-key attack doesn't apply?

In regards to fixing the cipher, I'm not really sure that one can just
issue a patch that would update the cipher itself (as opposed to a
specific implementation of it): the cipher is standardized and is
implemented in both hardware and software in zillions of devices and
programs around the world. Adding more rounds or changing its
functionality in some way to counter this attack would cause that
changed version to diverge from the standard and it presumably not
interoperate with standard AES.

Cheers!
-Pete

-- 
Pete Stephenson

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

Re: Can I revitalise an old key-pair?

[Pete Stephenson]

On Sun, Sep 1, 2013 at 2:57 PM, MartinHvidberg mar...@hvidberg.net wrote:
 I'm returning to GPG, and Enigmail, and not for the first time. This means
 that I have earlier generated key-pairs and uploaded them to servers like
 keys.pgp.net or something like that. I did this first time in 1999 and have
 done several new attempts later, and now have seven key-pairs on the server.
 Latest I have generated a key-pair in 2011.

While it can be tempting to use particularly old keys (such as those
made in 1999), the maximum length at the time (1024-bit DSA keys)
makes them borderline too-short for modern usage. Even if you regain
access to your 1999-era secret key, you should probably consider
transitioning to a new, stronger keypair. See
http://www.debian-administration.org/users/dkg/weblog/48 for some
useful information on the subject.

 My problem:
 I stead of generating yet another key-pair, how do I revitalise on of my
 existing key-pairs.
 This said, I have only what I can download from a key-server, and I do in
 fact remember the password, for some of them.

The keyservers only store the public part of your key. This is not
sufficient to derive the secret key (if it was, that'd be a Bad
Thing). If you do not have your secret key that corresponds to the
public key you wish to, as you say, revitalize, then there's nothing
you can do except create a new keypair. That, or develop some major
advancements in the field of mathematics that would allow you to
derive the secret key from the public key (which would break the whole
system, rendering the exercise moot).

 Do the key-server have all the information I need to re-use an existing
 key-pair (provided I remember the password)?

Unfortunately not.

 Or do I need to get one of my old computers up and running, hoping to find
 some sort of key file there.

If you go through your old systems and are able to find the relevant
secret key files or the GPG/PGP keyring files, then you can continue
using that keypair. If you cannot find the secret key, you'll need to
create a new keypair. :/

 If you can point to any online material, tutorial or the likes, that do not
 start with 'Generate a key-pair' then I would appreciate the a lot... :-)

I suppose the only step that'd come before that would be find your
secret key. If you can't do that, you're sort of hosed. :)

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

Re: Why trust gpg4win?

[Pete Stephenson]

On Sat, Aug 24, 2013 at 11:14 PM, Jan takethe...@gmx.de wrote:
 It seems quite easy to advice people to have an offline windows PC with
 gpg4win on it and all their private stuff and a windows(?) online PC next to
 it. They could transfer encrypted messages with an USB stick from one PC to
 the other. I think this is a vector for an attacker, but how serious is this
 problem?

It depends. For the average user not under any specific attack?
Probably not so serious. Even using PGP/GPG in the normal,
private-key-on-online-computer mode is almost certainly better than
not using it at all though one would need to be careful, just as one
would need to be careful with any sensitive communication.

For larger organizations or governments who may be under attack by
various adversaries? Probably more serious: look at Iran and Stuxnet
for an example of air-gap hopping malware that caused bad things to
happen (though not PGP-related).

The easiest and least-expensive solution to this situation is using
smartcards: http://g10code.com/p-card.html -- the private key is kept
securely on the smartcard. Any private-key operations (i.e. signing or
decrypting) are handled on-card and the private key is not accessible
to the computer. You could, of course, generate the key on an offline
computer and then transfer it to the smartcard and keep an offline
backup (that's what I do) rather than having the key generated
entirely on-card with no backup (which is an option).

Cheers!
-Pete

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

Re: searching for keys

[Pete Stephenson]

On Sun, Jul 14, 2013 at 9:46 AM, kardan kar...@riseup.net wrote:
 Thanks for the inspection! From my limited view I can not say what
 makes a keyserver legitmate. This is what whois says for me

Domain Name: SKS-KEYSERVERS.NET
Registrar: PDR LTD. D/B/A PUBLICDOMAINREGISTRY.COM
Whois Server: whois.PublicDomainRegistry.com
Referral URL: http://www.PublicDomainRegistry.com
Name Server: NS1.KFWEBS.NET
Name Server: NS10.SKS-KEYSERVERS.NET
Name Server: NS11.SKS-KEYSERVERS.NET
Name Server: NS12.SKS-KEYSERVERS.NET
Name Server: NS13.SKS-KEYSERVERS.NET
Name Server: NS6.SKS-KEYSERVERS.NET
Status: clientTransferProhibited
Updated Date: 17-feb-2013
Creation Date: 01-dec-2006
Expiration Date: 01-dec-2015

Did you follow the referral and query whois.publicdomainregistry.com
to get the more detailed information about the domain? For example,
http://smartwhois.com/whois/SKS-KEYSERVERS.NET will follow the
referral and yields the registrant's contact information (which I will
not include here).

 Searching for the owner via gpg brings different results without
 success. I assume the pool is not that well mantained?

I searched for the registrant of sks-keyservers.net on the keyservers
and found two current, valid public keys for them: a 4096-bit RSA key
signed by lots of people (0x6B0B9508) and a 15,360-bit(!) RSA key with
only a self-sig (0x43E67CF7).

My understanding is that the pool and the SKS keyserver software it
runs is well-maintained. http://www.sks-keyservers.net/status/ shows
53 active servers in the pool.

 * Connected to pool.sks-keyservers.net (198.82.169.69) port 443 (#0)
 * found 1 certificates
 in /etc/ssl/certs/hkps.pool.sks-keyservers.net.pem
 * server certificate verification failed.
 CAfile: /etc/ssl/certs/hkps.pool.sks-keyservers.net.pem CRLfile: none

Interesting. According to
http://www.sks-keyservers.net/overview-of-pools.php (see the very
bottom), the pool uses its own CA to sign server certs for HKPS
servers it lists. Server certificates for pool servers are signed by
the pool CA. If the certificate in
/etc/ssl/certs/hkps.pool.sks-keyservers.net.pem is a server cert for
one specific HKPS server in the pool, you will get certificate errors
when you query other servers in the pool (as they each have their own
unique certificate).

They pool CA certificate is available at
https://sks-keyservers.net/sks-keyservers.netCA.pem

Do you have GnuPG configured to use the CA certificate for the pool?
It looks like you're telling GnuPG to use one particular server
certificate as the CA, which won't work.

When I downloaded the pool CA and performed a key search over HKPS as follows,

$ gpg2 --search --keyserver hkps://hkps.pool.sks-keyservers.net
--keyserver-options ca-cert-file=./sks-keyservers.netCA.pem 0xDA122186

everything works as expected. (0xDA122186 is the KeyID for one of my own keys.)

You can also specify the ca-cert-file in your config file:

~/.gnupg/gpg.conf:
  keyserver hkps://hkps.pool.sks-keyservers.net
  keyserver-options ca-cert-file=/path/to/CA/sks-keyservers.netCA.pem

The PEM certificate you mentioned,

 SSL certificate for hkps.pool.sks-keyservers.net:

 -BEGIN CERTIFICATE-
 MIIGkzCCBXugAwIBAgIDCsjWMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJ
[snip]

Appears to have been issued by StartSSL, a well-known CA, and has not
been signed by the pool CA. The key is issued with a
CN=www.secretresearchfacility.com. There is a pool key server running
under that domain, keyserver.secretresearchfacility.com, but it's
running on a server that uses SNI to use multiple SSL certificates on
a single server.

GnuPG appears to support SNI and so works correctly (gpg2 --search
--keyserver hkps://keyserver.secretresearchfacility.com
--keyserver-options ca-cert-file=./sks-keyservers.netCA.pem 0xDA122186
 works properly) but does curl? If not, curl would not specify the
correct hostname it's looking for and the server (which doesn't know
what hostname the client wants) would present its default CA, which is
the StartSSL-issued one.

Cheers!
-Pete

-- 
Pete Stephenson

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

Re: Smart card works with GPG v1 but not with GPG v2 on Ubuntu

[Pete Stephenson]

On 6/29/2013 2:49 PM, Jan Geep wrote:
 hello
 
 I have a CryptoStick v1.2 and am trying to get it to work with gpg
 2.0.17 on Ubuntu 12.04.2
 
 It works perfectly when I use gpg v14.11 and I am trying to figure out
 what to do to get gpg2 to work would any people have suggestion?

Did you install the libccid and pcscd packages, as described at
https://www.crypto-stick.com/start ?

If that doesn't work, also try installing the gpgsm package -- for
whatever reason, my Crypto Stick didn't work until I installed that
package. If the package is removed, the Crypto Stick stops working. This
was the case for several Ubuntu and Mint systems, even fresh-from-the-CD
systems I created in VMs for testing, though your mileage may vary.

Cheers!
-Pete

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