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  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 comple

Re: gpg: BAD signature from

[Pete Stephenson]

On Wed, Dec 23, 2015 at 1:14 PM, stevehendo34  wrote:
> Downloaded armory-bin.tar.gz from arch AUR
>
> On Armory site they gave public key text in ASCII format.
> I saved it to armory_key.txt
> I imported this public key from armory_key.txt file to my key ring.
> gpg --list-keys
> pub   rsa4096/98832223 2012-02-28
> uid [ unknown] Alan C. Reiner (Offline Signing Key)
> 
> uid [ unknown] Alan C. Reiner (Armory Signing Key)
> 
> uid [ unknown] Alan C. Reiner (Armory Signing Key)
> 
> sub   rsa4096/DE6B2D74 2012-02-28
> t
>
> The also gave signature in ascii and I saved that to armory_sig.txt
> gpg --verify armory_sig.txt  armory-bin.tar.gz
> gpg: Signature made Sun Jun  7 20:46:36 2015 CDT using RSA key ID 98832223
> gpg: BAD signature from "Alan C. Reiner (Offline Signing Key)
> " [unknown]
>
> The key ID 98832223 match whats on their site 0x98832223, and whats on my
> keyring, but
> Can you explain what the third line means why (BAD signature)?
>
> I am pretty much new to all this stuff!

Hi Steve,

Welcome!

The error means that the data you downloaded doesn't match the data
that was originally signed by the author. It's possible this could be
due to an error by the signer, a transmission error over the internet,
or intentional tampering.

Cheers!
-Pete

-- 
Pete Stephenson

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

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 you'

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 com

Re: failed decryption

[Pete Stephenson]

On Sun, Apr 19, 2015 at 11:21 AM, Mick Crane  wrote:
>
>
>> On 19 Apr 2015, at 06:42, Adam Gold  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: Enabling and using ECC keys (any reason not to?)

[Pete Stephenson]

On Thu, Mar 26, 2015 at 5:55 PM, Johan Wevers  wrote:
> On 26-03-2015 9:59, Mike Ingle wrote:
>
>> Is this just a backward
>> compatibility thing, or is the security of ECC keys not fully trusted yet?
>
> The buzz about Dual_EC_DRBG made it clear that it is possible to design
> curves where the designers have access to data that allows them to
> compromise the system. Wether the curves used in a given implementation
> are suspected to possibly have such a weakness is a matter of debate. I
> didn't check the status of this for the curves used in GnuPG 2.1.

Although Dual_EC_DRBG uses elliptic curves, the weakness in that
algorithm lies with the alleged backdoor in Dual_EC_DRBG itself and
not in the mathematics behind elliptic curve crypto in general.

GnuPG 2.1 implements the following curves:
   (1) Curve 25519
   (2) NIST P-256
   (3) NIST P-384
   (4) NIST P-521
   (5) Brainpool P-256
   (6) Brainpool P-384
   (7) Brainpool P-512

People have raised concerns about the NIST curves, but they are part
of the RFC 6637 standard so compliant programs must implement P-256,
may implement P-384, and should implement P-521.

To address potential concerns with the NIST curves, GnuPG also
supports the Brainpool curves which are similar in structure to the
NIST curves but use parameters chosen from nothing-up-my-sleeve
numbers and so should be reasonably trustworthy. Still, the structure
of such curves leaves a bit to be desired (see
http://safecurves.cr.yp.to/ for details, I'm hardly an expert).

Additionally, GnuPG implements the non-standard Curve25519 (but only
for signing at the moment -- encryption will come later after things
have been standardized) which should be safe.

Cheers!
-Pete

-- 
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"  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 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: 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 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: bugs.gnupg.org TLS certificate

[Pete Stephenson]

On Fri, Mar 13, 2015 at 12:21 AM, Hugo Osvaldo Barrera  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 Thu, Mar 12, 2015 at 10:56 AM, Werner Koch  wrote:
> On Wed, 11 Mar 2015 20:39, p...@heypete.com said:
>
>>> 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.
>
> Sorry, I do not understand the question.  The format is defined by the
> OpenPGP standard or the CMS standard (aka S/MIME).  There are also some
> other less common formats.
>
> Or is the question how applications present this to the user or whether
> a standard API is defined?  That is not defined by one of these
> protocols.

I (perhaps incorrectly) interpreted the question as "If GnuPG makes
backwards-incompatible changes in the future, would it be possible for
one who knows the encryption algorithm used, key, etc. of a message to
decrypt that message with other, non-GnuPG tools?"

For example, if one knows that CAST5-CFB, ZIP, and salted-and-iterated
S2K was used (as well as the value of the salt and number of
iterations), might one be able to decrypt the message using OpenSSL
and other common utilities? I suspect yes, as the encryption and
compression methods are standards, but doing so would probably be
non-trivial.

I could be wrong with both the interpretation of the question and the
answer, though.

Cheers!
-Pete

-- 
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/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: 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: Help need to use truecryt + openpgp applet.

[Pete Stephenson]

On Fri, Feb 20, 2015 at 7:00 AM, Doug Barton  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  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 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: How to reset the PIN counter

[Pete Stephenson]

On Feb 7, 2015 6:42 PM, "Rainer Keller"  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: Crypto device where I need to confirm every operation?

[Pete Stephenson]

On Thu, Jan 22, 2015 at 6:00 PM, Felix E. Klee  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  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 Dec 29, 2014 6:57 AM, "Haritwal, Dhiraj" 
wrote:
>
> Almost done now. After I signed partner’s public key, that warring has
gone.

Great!

> I am using below command to encrypt file with my private key & partner’s
public key & partner is using my private key & their public key to decrypt
it but it’s getting fail. M I using anything wrong here.
>
>
>
> ./gpg --local-user 'MY USER’ --recipient partner_pubkey --encrypt --armor
/tmp/test/data1.CSV

That looks reasonable. When you say you're getting a fail, what error
message are you seeing?

Also, it seems that you're still mixing up the terms for private and public
keys: this makes it a bit confusing to follow what you're doing. You should
be encrypting the message to your partner's public key (you can
additionally encrypt it to other public keys, such as your own. This is
useful if you want to be able to read the message after you sent it.) and
your partner should use their private key to decrypt it.

> Tried to use --sign which is asking passphrase which don’t want to use.
Can we sign without passphrase & only with public/private key.

Signing a message requires the sender's (i.e., your) private key to
generate the signature. In order to unlock the private key so that it can
be used to sign the message, you need to provide the passphrase for your
private key.

Short answer: no. You need to use your passphrase (and private key) to sign
a message.

> Dhiraj
>
>
>
>
>
> From: Pete Stephenson [mailto:p...@heypete.com]
> Sent: 23 December 2014 11:24
> To: Haritwal, Dhiraj
> Cc: gnupg-users@gnupg.org
>
> Subject: RE: Unable to encrypt file with private/public key
>
>
>
> On Dec 22, 2014 7:30 AM, "Haritwal, Dhiraj" 
wrote:
>
> >
> > Thank you very much for all the explanation/links. Now things are bit
clear.
> > Now I have to encrypt file with partner's Public Key. I tried with
below command which is still showing warning message (gpg: 89709B71: There
is no assurance this key belongs to the named user) whereas if I am
checking partner_pubkey, it's showing full trust. How can I remove this
message. Even I have added partner's public key as trusted.
> >
> > ./gpg --encrypt --recipient partner_pubkey --armor /tmp/test/data.CSV
>
> I'm glad things are working better.
>
> To resolve the issue with the assurance message, manually verify that the
key belongs to the recipient (e.g. meet in person or call them and verify
the fingerprint of their key) and then sign the key using GnuPG. (gpg
--sign-key 0xKEYID)
>
> In GnuPG you vouch that a particular public key belongs to a person (or
organization) by signing their public key. This signature can be local or
published publicly.
>
> "Trust" in GnuPG is different, and reflects how much you trust the other
key to correctly vouch for the identity of others. If you set their key as
fully trusted, keys that are signed by that key are treated by your copy of
GnuPG with the same level of assurance as if you signed them yourself.
Typically this should only be reserved for people you know to always check
the identity of other people thoroughly and correctly before signing their
keys. The default is for trust to be set to "marginal".
>
> By combining signatures and trust, one forms a "web of trust":
https://en.wikipedia.org/wiki/Web_of_trust
>
> Cheers!
> -Pete
>
>
> 
>
> This email is confidential and intended only for the use of the
individual or entity named above and may contain information that is
privileged. If you are not the intended recipient, you are notified that
any dissemination, distribution or copying of this email is strictly
prohibited. If you have received this email in error, please notify us
immediately by return email or telephone and destroy the original message.
- This mail is sent via Sony Asia Pacific Mail Gateway..
___
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 Dec 22, 2014 7:30 AM, "Haritwal, Dhiraj" 
wrote:
>
> Thank you very much for all the explanation/links. Now things are bit
clear.
> Now I have to encrypt file with partner's Public Key. I tried with below
command which is still showing warning message (gpg: 89709B71: There is no
assurance this key belongs to the named user) whereas if I am checking
partner_pubkey, it's showing full trust. How can I remove this message.
Even I have added partner's public key as trusted.
>
> ./gpg --encrypt --recipient partner_pubkey --armor /tmp/test/data.CSV

I'm glad things are working better.

To resolve the issue with the assurance message, manually verify that the
key belongs to the recipient (e.g. meet in person or call them and verify
the fingerprint of their key) and then sign the key using GnuPG. (gpg
--sign-key 0xKEYID)

In GnuPG you vouch that a particular public key belongs to a person (or
organization) by signing their public key. This signature can be local or
published publicly.

"Trust" in GnuPG is different, and reflects how much you trust the other
key to correctly vouch for the identity of others. If you set their key as
fully trusted, keys that are signed by that key are treated by your copy of
GnuPG with the same level of assurance as if you signed them yourself.
Typically this should only be reserved for people you know to always check
the identity of other people thoroughly and correctly before signing their
keys. The default is for trust to be set to "marginal".

By combining signatures and trust, one forms a "web of trust":
https://en.wikipedia.org/wiki/Web_of_trust

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: 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: Mainkey with many subkeys??

[Pete Stephenson]

On Mon, Dec 8, 2014 at 10:12 AM, gnupgpacker  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
 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  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  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  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 2:50 PM, Philip Jackson
 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: smart card under linux

[Pete Stephenson]

On Tue, Oct 21, 2014 at 12:36 AM, Philip Jackson
 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: [Announce] The maybe final Beta for GnuPG 2.1

[Pete Stephenson]

On Wed, Oct 15, 2014 at 1:00 PM, Peter Lebbing  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:
>
> ---8<>8---
> ***
> *** 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.
> ***
> ---8<>8---
>
> 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 6:39 PM, Werner Koch  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: [Announce] The maybe final Beta for GnuPG 2.1

[Pete Stephenson]

On Fri, Oct 3, 2014 at 4:35 PM, Werner Koch  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: NSA, PGP and RSA

[Pete Stephenson]

On Thu, Oct 2, 2014 at 3:09 AM, Robin Mathew Rajan
 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: gmail list replies [Re: Keeping .gnupg folder in cloud]

[Pete Stephenson]

On Thu, Sep 18, 2014 at 10:36 PM, Daniel Kahn Gillmor
 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: 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]



___
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
> ,
> now a separate project.
>   o 1.4.9
> ,
> 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  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 11:44 PM, Samir Nassar  wrote:
> On Friday, 2014-08-08 23:34:30 Pete Stephenson  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: [Announce] [security fix] Libgcrypt and GnuPG

[Pete Stephenson]

On Fri, Aug 8, 2014 at 12:17 PM, Werner Koch  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: CRC error

[Pete Stephenson]

On Mon, Jul 28, 2014 at 7:53 PM,  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  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 :

> 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: riseup.net OpenPGP Best Practices article

[Pete Stephenson]

On 6/24/2014 8:47 AM, Werner Koch wrote:
> On Tue, 24 Jun 2014 05:55, fr...@frase.id.au said:
> 
>> rounds today.  Quite a lot of good info, especially regarding key
>> strength and expiry, and digest preferences.
> 
> Just for the records: _I_ do not consider the use of a 4096 bit RSA key
> and a preference for SHA-512 a best practice.  For a secure system it is
> important to make the system stronger and not parts of the system which
> will never be attacked in real life.  Granted, there are user with a
> need for non default algorithms, but those users have the resources to
> develop a security policy which fits their use case.

I also generally agree that the default key size is a sensible choice
for most users.

I would think that adversaries will not try breaking the crypto at all:
there's plenty of alternatives, from keyloggers to compelling the sender
or recipient (through legal means or otherwise) to decrypt the message,
that require considerably less resources. ObXKCD: http://xkcd.com/538/

That said, is there any particular reason for avoiding SHA-2?

There's been discussion in the past regarding some other OpenPGP
software not playing nicely with SHA-512, with recommendations to not
use SHA-512. Is that still an issue? I've not run into any issues, but
that's merely an anecdote.

Would SHA-256 be a better (in the context of being more compatible)
choice if one preferred using a non-SHA-1 hash?

> How does a help 4096 key help if I can send you an encrypted mail which
> will lock up your MUA until you kill it (unless your MUA has some kind
> of timeout mechanism).  There are more important things to be made
> stronger than the key size.

Absolutely. Obviously, using a too-weak key (e.g. 512-bit RSA) is a
problem, but key size is not an issue with the defaults.

Cheers!
-Pete

___
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  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.


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
, 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,   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"  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: OpenPGP Smartcard: How to generated (non-exportable) keys on the card?

[Pete Stephenson]

On Apr 24, 2014 10:35 PM, "privacyfirst"  wrote:
>
>
> (The first attempt to send this message failed - so I'm resending it.)
>
> Hello,
>
> one of the features of OpenPGP v2 Smartcards is "Key generation on card".
>
> From this I would expect a high degree of security as the key is only
stored on the smartcard and *never* touches the disk and therefore should
not be able to be stolen without stealing the physical smartcard.
>
> I wanted to test this property.
> My goal was to generate a key that can not be exported (gpg
--export-secret-key should not be possible).
>
> This is how I generated my keys:
>
> gpg2 --card-edit
> > admin
> > generate
> Make off-card backup of encryption key? (Y/n) --> n
>
>
> After keys were successfully generated I tried to run
>
> gpg2 --export-secret-keys --armor
>
> to verify that it is not possible to export private keys generated on the
smartcard, but to my surprise it was possible and I got the private PGP key
block.
> Is this expected? (this even works after removing the cardreader, so I
> assume the key is on the disk)
> I did not choose the wrong keyid as there is only one.
>
> How can I generate a non-exportable key safely on the card?

You have done everything correctly: the "private" key block you're seeing
is a "stub" that tells GnuPG that the actual private key resides on a
smartcard with a specific serial number (to distinguish it from other
smartcards you might use for other keys).

It does not contain any private data.

If you were to go to a different system, import your public key (say, from
a keyserver), insert your smartcard, and run "gpg --card-status" then GnuPG
will automatically generate a new private key stub on that system so you
could use the card.

Cheers!
-Pete
___
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"  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
 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
 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  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 
)
-- 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  wrote:
> When reading
> , 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
 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  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  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

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: Usage of --symmetric

[Pete Stephenson]

On Wed, Jan 22, 2014 at 8:59 AM, Rahul R  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

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" 
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: Windows editor destroys gpg.conf

[Pete Stephenson]

On Wed, Jan 15, 2014 at 2:02 PM, Hauke Laging
 wrote:
> Two concerns:
>
> 1) Does anyone know what the problem is and/or whether I can avoid it by
> using another program which is part of Windows (or widely used)?

I like using Notepad++ <http://notepad-plus-plus.org/>. It understands
Unix and Windows end-of-line conventions and can switch between them
as needed. I've had no problems editing my gpg.conf file with it.

Cheers!
-Pete

-- 
Pete Stephenson

___
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
 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
 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
 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
 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 11:01 AM, Uwe Brauer  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: gpgsm and expired certificates

[Pete Stephenson]

On Sun, Oct 27, 2013 at 9:53 AM, Uwe Brauer  wrote:
>>> "Werner" == Werner Koch  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: 2048 or 4096 for new keys? aka defaults vs. Debian

[Pete Stephenson]

On Fri, Oct 25, 2013 at 2:19 AM, Christoph Anton Mitterer
 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: trust your corporation for keyowner identification?

[Pete Stephenson]

On Wed, Oct 16, 2013 at 4:20 PM, Johan Wevers  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: trust your corporation for keyowner identification?

[Pete Stephenson]

On Wed, Oct 16, 2013 at 2:04 PM, Brian J. Murrell  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: New GPLv3 OpenPGP card implementation (on a java card).

[Pete Stephenson]

On Wed, Oct 16, 2013 at 11:40 AM, Werner Koch  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: New GPLv3 OpenPGP card implementation (on a java card).

[Pete Stephenson]

On Tue, Oct 15, 2013 at 7:42 AM, Ann O'nymous  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
>>
> 
> 
> 
> 
>> --===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
 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_26&products_id=133&osCsid=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  wrote:
> On Monday 16 September 2013 at 7:57:04 PM, in
> , 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  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
 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  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  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: Why trust gpg4win?

[Pete Stephenson]

On Mon, Sep 9, 2013 at 11:39 PM, Robert J. Hansen  wrote:
> On 9/9/2013 4:52 PM, Jan wrote:
>> Imagine an intact offline PC without "auto play" enabled for USB drives.
>
> Can't.
>
> USB is a peer protocol.  There's an astonishing amount of computational
> power on both sides of that USB cable.  Protocol negotiation is complex.
>  Put it all together and you get a peer-to-peer protocol which you
> *cannot* secure because (a) there are too many computational resources
> available to an attacker and (b) the protocol itself is too complicated
> and there are many ways a malicious token could compromise the remote
> system even without autoplay installed.

I'm sure we've all seen serial-to-USB adapters. Now I wonder if it'd
be possible to do something in reverse: USB-to-serial.

Serial connections are pretty well-understood, well-documented, and
(hopefully) less likely/able to be an attack vector. It'd be
interesting to see if one could have a USB hub or something to which
one could connect a USB flash drive or other device, have the hub
negotiate the connection with the device, and then send serial data to
the computer where a relatively simple (and presumably
easier-to-secure) program could interpret it. Sure, speeds wouldn't be
anywhere near the same as with USB and one would have to do some
hackery to mount volumes (perhaps a USB-to-serial-to-FUSE interface
for common file systems?) but it might work for relatively small file
transfers (or for those willing to wait).

Is such a thing even possible?

-- 
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 Mon, Sep 9, 2013 at 12:28 PM, Ole Tange  wrote:
[snip]
> Hopefully that will stop people from recommending against 10kbit keys
> for the sake of the communication partners.

While it certainly seems that 10kbit keys offer reasonable performance
even for slow systems (thanks for doing the benchmarks on those
systems), there's also some practical concerns:

1. Most smartcards these days support 2048-bit keys, while OpenPGP
smartcards support 4096-bit keys. I'm not aware of any smartcard that
supports >4096-bits. It'd be nice to see hardware vendors offer cards
that can handle larger keys. I'm not sure what the demand for larger
keys is, but I imagine that smartcard support for larger keys would be
a long time coming.
2. How compatible are >4096-bit keys with various OpenPGP
implementations? It's nice to have a (presumably) secure key, but if
other people's software only support 4096-bit keys as a maximum then
you can't really communicate with them. New features are slow to add
to both the standard and to various implementations: even though RFC
4880 says that OpenPGP implementations MAY implement hashes other than
SHA1, I've read some concern about compatibility with SHA256 and
SHA512 signatures and key certifications (I've not observed any such
issues, but I rarely interact with people using older software
versions that are unlikely to support it). I'm not sure what other
programs implement the standard or how well-supported extra large keys
would be.
3. Generating large keys with GnuPG requires that one patch the source
and recompile. This limits the creation of extra-large keys to those
who feel comfortable with doing this. It'd be interesting to see if
Werner would change the hard-coded maximum keysize from the current
4096 to, say 8192 (or 15,360 or 16,384) bits so that users who desired
such keys could create them easily. (It'd probably be best to require
an "--expert" flag to expose such options, at least for a while.)

Thanks again for the interesting benchmarks and measurements.

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  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.org&hideResults=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: Some doubts about signature procedure

[Pete Stephenson]

On Mon, Sep 9, 2013 at 10:42 AM, Francesco C.
 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