Re: Key distribution via NFC

[Robert J. Hansen]

> Read-only you say?

Given I've only been playing around with these things for the last few
hours, you'll have to forgive the occasional newbie mistake.  :)  But
damn, they're *neat*!

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

Re: riseup.net OpenPGP Best Practices article

[Robert J. Hansen]

This will be my last on the thread.

You've said several times that your interest is in making sure crypto
isn't the weak link in the chain.

Well, it's not.  We know it's not.  (And not just because of XKCD,
either.[*]).  Roughly one in four desktop PCs is already exploited.
Applications are a seething morass of Metasploit targets.  Physical
access trumps all and that the government is skilled at using Van Eyck
devices, black bag teams, subpoenas, national security letters, and more
to get what they want.  Organized crime has even fewer scruples and
nothing's off the table for them, including field expedient dentistry.

Given what a target-rich environment the net is, the difference between
a 3DES level of keyspace and an AES256 level of keyspace does not matter
a tinker's damn to whether your communications are safe.  I want to
emphasize this: the changes that you are passionately arguing about *do*
*not* *matter*.  And passionate argument about things that don't matter
is... bikeshedding.

No more bikeshedding.  My final statements about this thread:

* I've seen very little support from the list for your proposed
  best practices document,
* I conclude the community's sentiment is that the defaults are
  good,
* The FAQ will continue to recommend people use the defaults. [**]


[*] http://xkcd.com/538/
[**] as always, Werner gets final say!




signature.asc
Description: OpenPGP digital signature
___
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

[Micha Rosenbaum]

On 03.07.2014 16:16, Werner Koch wrote:
> Signing is a very different thing than encryption.  It has nothing to do
> with encryption.  Using the terms decryption or encryption to describe
> signature creation and verification leads to confusion

I think the term «signing» leads to confusion, too. When I receive a
signed statement from a good friend, I have no chance to prove whether
he signed or not. And proving if something was added after he signed it
is even more difficult. But as far as I know this is all possible with
an OpenPGP signature.

So are there analogies that can easily explain what signing does?

-- 
PGP: 0x7694EB9B (http://rosetree.de/pgp)
http://www.email-nur-an-dich.de/



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

Re: Key distribution via NFC

[Johan Wevers]

On 04-07-2014 6:18, Robert J. Hansen wrote:

> But what if giving them your key was as simple as putting down a
> read-only NFC token and telling people, "there, scan that"?

Read-only you say? NFC writers are cheap (they were even sold out here
when someone foud out you could use them to top-up the new public
transportation cards with them). Maybe even my phone could do it.

And with Android 4.4 or Cyanogenmod, you could even try setting it in
NFC host mode and use the phone as NFC tag. Although that might be not
as easy as it should, I tried programming my phone to replace the badge
I have to enter my work but failed (it uses some Mifare classic chip).

-- 
ir. J.C.A. Wevers
PGP/GPG public keys at http://www.xs4all.nl/~johanw/pgpkeys.html


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

Re: Key distribution via NFC

[Daniel Kahn Gillmor]

On 07/03/2014 11:54 PM, Robert J. Hansen wrote:
> the ability to store 400 bytes, to
> access it quickly and easily, and all in a tag that costs less than a
> dollar and can be read with almost any modern smartphone, is kind of cool.

it is cool indeed.

You can also get all of the above properties, plus the ability for
(sighted) humans to detect any deliberate interference, and to know when
the device is reasonably shielded from eavesdroppers, with a QR code or
other medium-density bar code for which free readers are available.

The monkeysign project and the guardian project are both doing good work
in that direction.  Moving the signalling from visible light to the RF
part of the spectrum seems like it would be a regression to me.

--dkg



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

Re: Key distribution via NFC

[Robert J. Hansen]

> You can also get all of the above properties...

*Almost*.  NFC is significantly more convenient than fumbling with your
phone's camera app, taking a snapshot, etc.  Wave it and it's done.  NFC
has some interesting human interface engineering behind it.



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

Re: riseup.net OpenPGP Best Practices article

[Robert J. Hansen]

> Of course.  And Alice can always send Bob cleartext too.  does that mean
> that Bob shouldn't offer any encryption key at all because there's no
> guarantee that it will be used?

It means Bob should have a line item for that in his security model.
"Alice may send me cleartext."

It also means Bob should have a line in his security model, "Even if
Alice correctly uses OpenPGP to encrypt her email to me, I can only rely
on 112 bits of keyspace."

> stronger keys are not about guaranteeing any particular level of
> security -- they are about *permitting* that level of security (or, more
> likely, about providing that much larger of a buffer against unknown
> mathematical advances), should the other actors in the game do something
> different.

I love this idea: "permits."  Who permits it?  When designing a system,
you must assume that anything that's not a game-over is under the
enemy's control.  You're relying on *the enemy permitting it*.

If I'm trying to break your traffic, Daniel, the last thing I'll do is
tackle even 80-bit crypto.  Seriously.  Life's too short.  But if I have
to, the very first thing I'll do is find a way to degrade you into using
an inferior level than your model expects.  I'll go after Alice.  I'll
find some way to convince her to shift to 3DES.  And just like that, I,
the enemy, will revoke your permission to have 256-bit crypto on the
Alice->you link.  You'll have 112, because that's what I'll allow.

> GnuPG's current default of a 2048-bit RSA key is roughly 103-bit
> symmetric equivalent.

According to one group; according to NIST, it's 112.  That's quibbling,
though: a factor of 2**9 is irrelevant.

> Except that you can't even rely on 112 bits of keyspace at all.  even if
> alice doesn't just send cleartext, she could select bad keys for 3DES,
> or have a compromised RNG, or lots of other failure modes.

Sure, but this requires me to compromise Alice's box and violates the
game-over assumption that the endpoints are secure.

> let's look at it the other way: if you do assume that the symmetric
> ciphers in use give you 112-bit security, wouldn't a lot of people blink
> a few times and ask "well, why would use an asymmetric key with 1/500th
> the resistance to brute force attack?"

Because (a) according to NIST they're equivalent, (b) nine bits is
irrelevant, and (c) if you check the archives you'll discover I've been
rather kind to RSA-3072; it's beyond that where I've always said "oh,
give me a break already."




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

Re: riseup.net OpenPGP Best Practices article

[Daniel Kahn Gillmor]

On 07/04/2014 12:08 AM, Robert J. Hansen wrote:
> Bob is all about "I must have at least 256 bits of keyspace in all my
> email!"  But Bob can't do that, because Alice can *always* degrade him
> to 112 bits by choosing 3DES.

Of course.  And Alice can always send Bob cleartext too.  does that mean
that Bob shouldn't offer any encryption key at all because there's no
guarantee that it will be used?

> And since Bob is the target, and since
> we're assuming the enemy is well-financed and professional and capable
> of tricking people, Bob needs to stop thinking he can somehow guarantee
> 256 bits of keyspace in his emails.

stronger keys are not about guaranteeing any particular level of
security -- they are about *permitting* that level of security (or, more
likely, about providing that much larger of a buffer against unknown
mathematical advances), should the other actors in the game do something
different.

GnuPG's current default of a 2048-bit RSA key is roughly 103-bit
symmetric equivalent.  When using keys of that size, breaking the key is
more likely to be accessible to a well-funded attacker than breaking the
symmetric cipher itself.  And consider the value of the different parts
of the cryptosystem: breaking the asymmetric key lets you break all the
ciphertexts ever encrypted to that key, whereas breaking the symmetric
cipher only allows access to a single ciphertext...

> "Using long certificates *may* give a larger effective keyspace, but
> really, you can only ever be certain of 112 bits of keyspace, so you
> should design your security model such that it only relies on 112 bits
> of keyspace" is accurate.

Except that you can't even rely on 112 bits of keyspace at all.  even if
alice doesn't just send cleartext, she could select bad keys for 3DES,
or have a compromised RNG, or lots of other failure modes.  You can't be
certain of any of it.  What you *can* do is offer stronger keys so that
the buffer against attack is able to be larger should the other aspects
hold up.

> But I think if long certificates were to be
> marketed that way, a lot of people would blink a few times and ask,
> "well, what's the point, then?"

let's look at it the other way: if you do assume that the symmetric
ciphers in use give you 112-bit security, wouldn't a lot of people blink
a few times and ask "well, why would use an asymmetric key with 1/500th
the resistance to brute force attack?"

--dkg




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

Re: Key distribution via NFC

[Robert J. Hansen]

> 1) might it be possible to combine several of these storage devices 
> (reading them one after the other) to add up their capacity?

Probably, but once you've got a dozen of these things they sort of stop
being a convenient form factor.  :)

> 2) wouldn't it be enough to transfer the mainkey? Or even a fingerprint? 
> The rest could be safely taken from the keyservers.

Yes, but...

Remember why the keyservers exist: because when a key is several
thousand bytes it's pretty inconvenient to keep it with you.  Only
keeping a 40-hexit SHA-1 hash is much more convenient: give the
recipient that and let them look it up on the keyservers.

But what if giving them your key was as simple as putting down a
read-only NFC token and telling people, "there, scan that"?

It might be popular with the crowd that shuns keyservers, for whatever
reason.  ("I don't like spammers," "I think they're probably monitored,"
"I don't know the keyserver operators so how can I trust them," etc. --
many of these reasons are ridiculous, but that doesn't mean there aren't
a lot of people who hold those beliefs.)





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

Re: Key distribution via NFC

[Robert J. Hansen]

> This is too large to store an RSA or DSA2 certificate, unfortunately.

Too *small*.  Sorry.  Time for me to go drink coffee straight from the pot.

Also, for Americans, happy Fourth of July.  :)


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

Re: riseup.net OpenPGP Best Practices article

[Robert J. Hansen]

> I think you're talking about personal-cipher-preferences here, which
> Alice uses to govern the cipher she uses.

Correct.

> Note that she could even put IDEA first here.

Sure, but it wouldn't take unless Bob had IDEA in his preference list.
If Bob's preference list is AES256 CAMELLIA256 3DES, then if Alice's
choice of IDEA will be ignored.  The choice of 3DES won't be, which is
why 3DES is relevant here.

> actually advertise all ciphers her openPGP implementation is capable of?

I'm saying only that she puts 3DES ahead of Bob's preferred 256-bit
ciphers in her personal-cipher-preferences.

Bob is all about "I must have at least 256 bits of keyspace in all my
email!"  But Bob can't do that, because Alice can *always* degrade him
to 112 bits by choosing 3DES.  And since Bob is the target, and since
we're assuming the enemy is well-financed and professional and capable
of tricking people, Bob needs to stop thinking he can somehow guarantee
256 bits of keyspace in his emails.

Bob can guarantee 256 bits of keyspace in *what he generates*.

Bob cannot guarantee 256 bits of keyspace in *what he receives*.

Telling people to use extremely large keys because "then your
correspondents will be using RSA-ungodly, which has an effective
something-ridiculous keyspace" sounds nice, but it's not true.  Bob can
only guarantee up to 112 bits of keyspace in the traffic that gets sent
to him, because Bob can't prohibit his correspondents from using 3DES.

Anyone who simply, glibly, says "use long certificates because they give
a larger effective keyspace," is committing fraud, IMO.  You're making
promises that aren't true and which you can't back up.

"Using long certificates *may* give a larger effective keyspace, but
really, you can only ever be certain of 112 bits of keyspace, so you
should design your security model such that it only relies on 112 bits
of keyspace" is accurate.  But I think if long certificates were to be
marketed that way, a lot of people would blink a few times and ask,
"well, what's the point, then?"



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

Re: Key distribution via NFC

[Hauke Laging]

Am Do 03.07.2014, 23:54:39 schrieb Robert J. Hansen:

> Bring it close
> to a mobile phone and presto, bang, it can access the 400 bytes.
> 
> This is too large to store an RSA or DSA2 certificate, unfortunately.

I don't even have a smartphone... but

1) might it be possible to combine several of these storage devices 
(reading them one after the other) to add up their capacity?

2) wouldn't it be enough to transfer the mainkey? Or even a fingerprint? 
The rest could be safely taken from the keyservers.


Hauke
-- 
Crypto für alle: http://www.openpgp-schulungen.de/fuer/unterstuetzer/
http://userbase.kde.org/Concepts/OpenPGP_Help_Spread
OpenPGP: 7D82 FB9F D25A 2CE4 5241 6C37 BF4B 8EEF 1A57 1DF5


signature.asc
Description: This is a digitally signed message part.
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Key distribution via NFC

[Robert J. Hansen]

A good friend just gave me a handful of NFC tags that are capable of
storing about 400 bytes.  It's a convenient form factor: a cardboard
disk with an adherent backing, perhaps 2.5cm across.  Bring it close to
a mobile phone and presto, bang, it can access the 400 bytes.

This is too large to store an RSA or DSA2 certificate, unfortunately.
But it got me thinking that with the move to elliptical-curve crypto in
GnuPG 2.1, it might be interesting to think about the possibility of
using NFC tags for certificate distribution.  Keep an NFC tag on your
keychain.  If someone asks you for your certificate, you don't have to
trade a SHA-1 fingerprint -- just put down your keychain and let the
person wave a cell phone over it.

Obviously there are risks associated with NFC, and I haven't done any
real looking at the security model of NFC -- it's very likely there are
big things I'm overlooking.  But the ability to store 400 bytes, to
access it quickly and easily, and all in a tag that costs less than a
dollar and can be read with almost any modern smartphone, is kind of cool.

It might be worth thinking how this can be used.  :)


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

Re: riseup.net OpenPGP Best Practices article

[Daniel Kahn Gillmor]

On 06/28/2014 12:09 AM, Robert J. Hansen wrote:
> When faced with that, it's only a matter of time until Alice decides to
> put 3DES first in her own preference list.  And then all her
> communications to Bob have 112 bits of keyspace, not the 256 Bob
> demands.

I think you're talking about personal-cipher-preferences here, which
Alice uses to govern the cipher she uses.  Note that she could even put
IDEA first here.  Are you suggesting that she *removes* all other cipher
algorithms from her advertised preference list as well, or does she
actually advertise all ciphers her openPGP implementation is capable of?

> And unless Bob is paranoid enough to check the symmetric
> algorithm used on every single encrypted message, Bob will never know
> that Alice's communications to him have been degraded.

well, OK.  Alice could also publish the cleartext on her blog, and Bob
would never know it if he doesn't read her blog.  Bob can't control what
Alice does; what he can do is to advertise his preferences in a
cryptographically-verifiable way, and set *his own*
personal-cipher-preferences to prefer stronger ciphers.

then, unless Alice has actively removed all ciphers from her advertised
preferences except for 3DES, Bob's personal-cipher-preferences will take
precedence in the messages that he sends.

I feel like i shouldn't have to point this out, but:

 * This is what the best practices page we've been discussing is suggesting.

This is the right thing to do, and Bob should do it, regardless of
whatever bad advice Alice has bought into.

Arguing that it's hopeless/pointless/harmful to prefer stronger ciphers
yourself because one of your correspondents might be tricked into
disabling stronger ciphers makes no sense from either a security or
interoperability perspective.  I'm really sorry to hear about your
graduate student debt, Rob, but this is not the best way to pay it off :P

> Werner and others are absolutely right: there is no *technical* way to
> degrade things to 3DES.  But given that cipher preference lists are
> fundamentally a *human* decision, well... the human being is always
> exploitable.

Of course.  And we should make our defaults better and encourage
stronger mechanisms for everyone, instead of trying to claim that using
well-known, widely-adopted, clearly-specified, longstanding algorithms
is somehow "breaking the spec".

I'm sure you're not trying to claim that AES is actually a worse cipher
than DES, or that members of the SHA-2 family are actually worse digests
than SHA-1.  So i think the scenario you paint above reinforces the
points made by the riseup best practices document.

--dkg



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

Re: [fa...@ariis.it: Re: How to verify a signed mail (silly question maybe, sorry ; )]

[Ingo Klöcker]

On Thursday 03 July 2014 08:49:12 Linux DEBIAN wrote:
> Hello,
> 
>   thanks for your reply.
> 
> Maybe I do soemthing wrong and following the instructions, still
> receiving 'bad signature'.

I'm not surprised. It seems that Francesco Ariis has left out a crucial 
step (or you have removed it when you quoted his message). RFC 3156 
reads

=

Upon receipt of a signed message, an application MUST:

   (1)   Convert line endings to the canonical  sequence before
 the signature can be verified.  This is necessary since the
 local MTA may have converted to a local end of line convention.

   (2)   Pass both the signed data and its associated content headers
 along with the OpenPGP signature to the signature verification
 service.

=

> It's my mail and my signature (for testing purposes) so I'm sure
> signature is ok, btw.
> 
> Does it matter if in the beginning of the part is:
> 
> Content-Type: Text/Plain;
> charset="utf-8"
> Content-Transfer-Encoding: quoted-printable

No.


> and the whole copied part ends with:
> 
> =3D

It shouldn't matter.


> Also, when I copy the text, when using Kate (text editor for KDE,
> Linux), I always use utf-8 for opening/saving documents.
> Shall I change to another charset ?
> There is no choice for exactly 'ascii', just e.g. western european ISO
> 8859-1 and many others.

The charset should be irrelevant because quoted-printable encoded text 
does not contain any non-ASCII characters.

Concerning (1) in the excerpt of RFC 3156 quoted above, you have to tell 
Kate to switch the line endings to Windows line endings (Tools->End of 
Line->Windows/DOS) before saving the text to a file. Or run unix2dos on 
the saved text to convert the line endings on the command line.


If you do all of this correctly, then you might be lucky that the 
signature verification succeeds. You might not be so lucky when the next 
signed message arrives.

IMHO trying to verify an OpenPGP/MIME-signed message by hand is at most 
a nice exercise, but it's certainly nothing one should do regularly.


Regards,
Ingo


signature.asc
Description: This is a digitally signed message part.
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: How to verify a signed mail (silly question maybe, sorry ;)

[Ingo Klöcker]

On Wednesday 02 July 2014 19:38:41 Linux DEBIAN wrote:
> Hello all,
> 
> 
>   now I use KMail post client where it's alla automatically checked
> but when I am on the webmail where the signing and verifying is not
> "built-in" supported and when I receive an e-mail with an attchement
> "signature.asc", how can I verify the signature, please ?

I think you've left out a few constraints. When you are on webmail, what 
tools are available to you? It seems obvious to me, that Linux is not 
available to you (because otherwise you'd most likely also have KMail 
available). What else is not available to you? What is available to you? 
Why do you only have webmail?

Regardless of your answers to those questions, my suggestion is to 
switch to a webmail solution with built-in support for OpenPGP/MIME. 
Alternatively, if you do not want to make a complete switch, then still 
create an account at a webmail provider that does support OpenPGP/MIME 
and then forward signed messages for verification to this webmail 
solution.


Regards,
Ingo


signature.asc
Description: This is a digitally signed message part.
___
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

[Werner Koch]

On Thu,  3 Jul 2014 14:56, fr...@frase.id.au said:

> encryption, but will lead to more confusion when attempting to
> understand/explain signing - where indeed the public key is used to
> decrypt a digest encrypted by a public key.

Signing is a very different thing than encryption.  It has nothing to do
with encryption.  Using the terms decryption or encryption to describe
signature creation and verification leads to confusion (it is actually
only partly true for the RSA algorithm).

We use two different keys, one for encryption and for signatures.
OpenPGP merely puts them together on the same "keyring" (technically
called a keyblock) for convenience.


Shalom-Salam,

   Werner

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


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

Re: [Announce] The fifth Beta for GnuPG 2.1 is now available for testing

[Werner Koch]

On Thu,  3 Jul 2014 13:27, kristian.fiskerstr...@sumptuouscapital.com
said:

> Functionally things are working nicely for me using git master. A
> feature request might be to make the number of objects for a keyserver
> refresh customizable as I can't refresh my keyring using 2.1 (but can
> using 2.0), anyhow, more importantly.

I'll be on vacation the next two weeks.  I'll take care of it then
(patches anyone)?

> These all belong in tests/pkits. Please find enclosed logs of the
> failing tests.

I have not run pkits tests for ages ;-).  Needs to be checked of course.


Shalom-Salam,

   Werner

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


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

Re: Analogies to explain the basic principles of encryption as used by OpenPGP

[Daniel Krebs]

Hi Olav,

Am 03.07.2014 14:00, schrieb Olav Seyfarth:

I'd also rather use the analogy of a "padlock without key" to be distributed by
the receipient of a message. That way you're able to explain the prerequisite
for asymmetric crypto as we use it in OpenPGP: the receipent must "do something"
BEFORE anyone can send anything (secured by that means) to him. Everyone knows
what happens if you snap the lever into the lock - you're only able to unlock it
if you have the key (or a big tool, OK).


But how would you explain signing from that point of view?


--
kind regards
daniel krebs

___
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

[Robert J. Hansen]

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

'Twas me.  :)

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

Analogies to explain the basic principles of encryption as used by OpenPGP (was: Re: Analogien um das Prinzip von PGP zu erklären)

[Olav Seyfarth]

-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160

Hi Daniel,

I'd also rather use the analogy of a "padlock without key" to be distributed by
the receipient of a message. That way you're able to explain the prerequisite
for asymmetric crypto as we use it in OpenPGP: the receipent must "do something"
BEFORE anyone can send anything (secured by that means) to him. Everyone knows
what happens if you snap the lever into the lock - you're only able to unlock it
if you have the key (or a big tool, OK).

Olav
- -- 
The Enigmail Project - OpenPGP Email Security For Mozilla Applications
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (MingW32)
Comment: Dies ist eine elektronische Signatur - http://www.enigmail.net/

iQGcBAEBAwAGBQJTtUXYAAoJEKGX32tq4e9W6CIL/A/fs634GpvCyGjc0adwSygW
fBu29jUwyeA5WkNf6nfEG4t7Ez+4eI8ME7msOz/z3RVv/Ugey5IUy8abuNV1QPhZ
anWTsRcZF6tCIcKSj/zxSN+ShaRWhmHo+98hliltuxBzkZVzli6G86NJwcNyzgtV
vpXRP0paKvYEeZf/v/YqdW+MkCfKTVcXh4mMwy3aP4ZrlHXsAR1VsPj930iJhA26
LIdTVZEirnclE/4EUP5giweh+XDkXh/ke5wBJdaYQMzADGTygIFmuWsbAuATvkDq
INd5F3/s8fbXLcHgNAJiPW4B8qs/NpGH/Of3gCsgGZjT0PaXk3wjMNxoHasD1y52
zaeGcwHZ/NmI35QVeeBGxdH6tuIwpwxyr21Zv4U/8lOa85o91hmyFsSAOTueyLh1
TLn0NsiQrUB7WgoL/K4ic+y9KJkGXyM/8c53V6V4KQHTLHNsidebKv99uH1S06d3
BsgHNAOgjYgKqVVbQkMOjpQbI9dJ7elaLA8OEbPhRA==
=hiE3
-END PGP SIGNATURE-

___
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

[Fraser Tweedale]

On Thu, Jul 03, 2014 at 10:56:30PM +1000, Fraser Tweedale wrote:
> On Thu, Jul 03, 2014 at 01:46:33PM +0200, Neal H. Walfield wrote:
> > At Thu, 03 Jul 2014 12:50:50 +0200,
> > Daniel Krebs wrote:
> > > 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?
> > 
> > You might want to take a look a this:
> > 
> >   
> > https://freedom-to-tinker.com/blog/randomwalker/why-king-george-iii-can-encrypt/
> > 
> >   Email encryption, although cryptographically straightforward,
> >   appears too complicated for laypeople to understand.  In our
> >   project, we aimed to understand why this problem has eluded
> >   researchers for well over a decade and expand the design space of
> >   possible solutions to this and similar challenges at the
> >   intersection of security and usability.
> > 
> >   ...
> > 
> >   In PGP’s metaphors, each user posses two items, a private key and a
> >   public key.  Have you inferred how the protocol works yet?  Unless
> >   you have previous exposure to cryptography, likely not.  Why do I
> >   have two keys? What do these keys open? Aren’t all keys private?
> >   When you want to send a message to someone, you encrypt it with his
> >   public key, which is known to everyone.  The recipient can decrypt
> >   it with his private key, which only he possesses.  But can’t anyone
> >   use the public key to decrypt the message again?  Nope.  A public
> >   key can only encrypt, not decrypt.  Just trust us on that one.
> >
> Not so; this analogy might seem useful for explaining message
> encryption, but will lead to more confusion when attempting to
> understand/explain signing - where indeed the public key is used to
> decrypt a digest encrypted by a public key.
> 
Whups.  The digest is encrypted by the *private* key, of course :)

> Fraser
> 
> >
> >   You’re probably starting to understand why secure email is so hard
> >   to use.  Bear with us for one paragraph longer.
> > 
> >   ...
> > 
> >   We decided to test whether better metaphors might be able to close
> >   this gap between security and usability.  Specifically, we wanted
> >   metaphors that represented the cryptographic actions a user performs
> >   to send secure email and were evocative enough that users could
> >   reason about the security properties of PGP without needing to read
> >   a lengthy, technical introduction.  We settled on four objects: a
> >   key, lock, seal and imprint.  To send someone a message, secure it
> >   with that person’s lock.  Only this recipient has the corresponding
> >   key, so only they can open it.  To prove your identity, stamp the
> >   message with your seal.  Since everyone knows what your seal’s
> >   imprint looks, it’s easy to verify that the message came from you.
> > 
> > 
> > Neal
> > 
> > ___
> > 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



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

Re: This time in English: How to explain the principles of PGP, looking for metaphors

[Fraser Tweedale]

On Thu, Jul 03, 2014 at 02:06:04PM +0200, Daniel Krebs wrote:
> Sorry!
> I picked the wrong language / list last time...
> So in English:
> What metaphors do you use when explaining people PGP? Two examples:
> 1. A lock with two keys?
> 2. A lock (public) and a key (private)
> Something completely different?
> 
> Problems with both:
> 1. Seems to be kind of hard to understand for most people, because a 
> lock with one key to open and one key to close is rather special.
> 2. Signing emails is hard to explain this way. Signining by putting a 
> lock on it?
> 
> Any ideas are appreciated.
> 

The way I attempt to explain public key encryption and signing:

Each key in the keypair - one kept private to the owner, the
other made public - is both:

a) A set of instructions for building a lock that *only* the
   other key can unlock; and
b) The key for such a lock as could be built with the other key.

Therefore, a encrypted message can be sent to someone by using
their public key to build a "lock" for the message.  Only the
private key is able to "unlock" it.

Similarly, a sender of some message can authenticate it by using
their private key to "lock" the message.  If it can be
"unlocked" by their public key, only a person who possesses the
private key could have built that lock.

I hope this explanation makes sense.  Let me know if you could
suggest improvements to this analogy.

Cheers,

Fraser

> An Interesting approach (Thanks Neal for the link): Using 4 items: key, 
> lock, seal and imprint.
> https://freedom-to-tinker.com/blog/randomwalker/why-king-george-iii-can-encrypt/
> 
> 
> -- 
> kind regards
> daniel krebs
> 
> ___
> Gnupg-users mailing list
> Gnupg-users@gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-users


pgp4UTWf3rfRy.pgp
Description: PGP signature
___
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

[Fraser Tweedale]

On Thu, Jul 03, 2014 at 01:46:33PM +0200, Neal H. Walfield wrote:
> At Thu, 03 Jul 2014 12:50:50 +0200,
> Daniel Krebs wrote:
> > 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?
> 
> You might want to take a look a this:
> 
>   
> https://freedom-to-tinker.com/blog/randomwalker/why-king-george-iii-can-encrypt/
> 
>   Email encryption, although cryptographically straightforward,
>   appears too complicated for laypeople to understand.  In our
>   project, we aimed to understand why this problem has eluded
>   researchers for well over a decade and expand the design space of
>   possible solutions to this and similar challenges at the
>   intersection of security and usability.
> 
>   ...
> 
>   In PGP’s metaphors, each user posses two items, a private key and a
>   public key.  Have you inferred how the protocol works yet?  Unless
>   you have previous exposure to cryptography, likely not.  Why do I
>   have two keys? What do these keys open? Aren’t all keys private?
>   When you want to send a message to someone, you encrypt it with his
>   public key, which is known to everyone.  The recipient can decrypt
>   it with his private key, which only he possesses.  But can’t anyone
>   use the public key to decrypt the message again?  Nope.  A public
>   key can only encrypt, not decrypt.  Just trust us on that one.
>
Not so; this analogy might seem useful for explaining message
encryption, but will lead to more confusion when attempting to
understand/explain signing - where indeed the public key is used to
decrypt a digest encrypted by a public key.

Fraser

>
>   You’re probably starting to understand why secure email is so hard
>   to use.  Bear with us for one paragraph longer.
> 
>   ...
> 
>   We decided to test whether better metaphors might be able to close
>   this gap between security and usability.  Specifically, we wanted
>   metaphors that represented the cryptographic actions a user performs
>   to send secure email and were evocative enough that users could
>   reason about the security properties of PGP without needing to read
>   a lengthy, technical introduction.  We settled on four objects: a
>   key, lock, seal and imprint.  To send someone a message, secure it
>   with that person’s lock.  Only this recipient has the corresponding
>   key, so only they can open it.  To prove your identity, stamp the
>   message with your seal.  Since everyone knows what your seal’s
>   imprint looks, it’s easy to verify that the message came from you.
> 
> 
> Neal
> 
> ___
> Gnupg-users mailing list
> Gnupg-users@gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-users


pgpUVPHGi9WBO.pgp
Description: PGP signature
___
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

This time in English: How to explain the principles of PGP, looking for metaphors

[Daniel Krebs]

Sorry!
I picked the wrong language / list last time...
So in English:
What metaphors do you use when explaining people PGP? Two examples:
1. A lock with two keys?
2. A lock (public) and a key (private)
Something completely different?

Problems with both:
1. Seems to be kind of hard to understand for most people, because a 
lock with one key to open and one key to close is rather special.
2. Signing emails is hard to explain this way. Signining by putting a 
lock on it?


Any ideas are appreciated.

An Interesting approach (Thanks Neal for the link): Using 4 items: key, 
lock, seal and imprint.

https://freedom-to-tinker.com/blog/randomwalker/why-king-george-iii-can-encrypt/


--
kind regards
daniel krebs

___
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

[Werner Koch]

On Thu,  3 Jul 2014 12:50, mailingl...@krebs.uno said:

> Anregungen, Meinungen?

You should translate your question to English or send it to
gnupg...@gnupg.org.


Salam-Shalom,

   Werner


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


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

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

[Neal H. Walfield]

At Thu, 03 Jul 2014 12:50:50 +0200,
Daniel Krebs wrote:
> 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?

You might want to take a look a this:

  
https://freedom-to-tinker.com/blog/randomwalker/why-king-george-iii-can-encrypt/

  Email encryption, although cryptographically straightforward,
  appears too complicated for laypeople to understand.  In our
  project, we aimed to understand why this problem has eluded
  researchers for well over a decade and expand the design space of
  possible solutions to this and similar challenges at the
  intersection of security and usability.

  ...

  In PGP’s metaphors, each user posses two items, a private key and a
  public key.  Have you inferred how the protocol works yet?  Unless
  you have previous exposure to cryptography, likely not.  Why do I
  have two keys? What do these keys open? Aren’t all keys private?
  When you want to send a message to someone, you encrypt it with his
  public key, which is known to everyone.  The recipient can decrypt
  it with his private key, which only he possesses.  But can’t anyone
  use the public key to decrypt the message again?  Nope.  A public
  key can only encrypt, not decrypt.  Just trust us on that one.
  You’re probably starting to understand why secure email is so hard
  to use.  Bear with us for one paragraph longer.

  ...

  We decided to test whether better metaphors might be able to close
  this gap between security and usability.  Specifically, we wanted
  metaphors that represented the cryptographic actions a user performs
  to send secure email and were evocative enough that users could
  reason about the security properties of PGP without needing to read
  a lengthy, technical introduction.  We settled on four objects: a
  key, lock, seal and imprint.  To send someone a message, secure it
  with that person’s lock.  Only this recipient has the corresponding
  key, so only they can open it.  To prove your identity, stamp the
  message with your seal.  Since everyone knows what your seal’s
  imprint looks, it’s easy to verify that the message came from you.


Neal

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

Analogien um das Prinzip von PGP zu erklären

[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

[Announce] The fifth Beta for GnuPG 2.1 is now available for testing

[Werner Koch]

Hello!

I just released the fifth *beta version* of GnuPG 2.1.  It has been
released to give you the opportunity to check out new features and
to fix the bugs in the last beta.

  If you need a stable and fully maintained version of GnuPG,
  you should use version 2.0.25 or 1.4.18.

This versions is marked as BETA and as such it should in general not be
used for real work.  However, the core functionality is solid enough for
a long time and I am using this code base for a couple of years now.


What's new in 2.1.0-beta751 since beta442
=

 * gpg: Make export of secret keys work again.

 * gpg: Create revocation certificates during key generation.

 * gpg: Create exported secret keys and revocation certifciates with
   mode 0700

 * gpg: The output of --list-packets does now print the offset of the
   packet and information about the packet header.

 * gpg: Avoid DoS due to garbled compressed data packets. [CVE-2014-4617]

 * gpg: Screen keyserver responses to avoid importing unwanted keys
   from rogue servers.

 * gpg: The validity of user ids is now shown by default.  To revert
   this add "list-options no-show-uid-validity" to gpg.conf.

 * gpg: Print more specific reason codes with the INV_RECP status.

 * gpg: Cap RSA and Elgamal keysize at 4096 bit also for unattended
   key generation.

 * scdaemon: Support reader Gemalto IDBridge CT30 and pinpad of SCT
   cyberJack go.

 * The speedo build system has been improved.  It is now also possible
   to build a partly working installer for Windows.


Getting the Software


GnuPG 2.1.0-beta751 is available at

 ftp://ftp.gnupg.org/gcrypt/gnupg/unstable/gnupg-2.1.0-beta751.tar.bz2
 ftp://ftp.gnupg.org/gcrypt/gnupg/unstable/gnupg-2.1.0-beta751.tar.bz2.sig

and soon on all mirrors .  A patch
against the last beta is also available.

Please read the README file !


Checking the Integrity
==

In order to check that the version of GnuPG which you are going to
install is an original and unmodified one, you can do it in one of
the following ways:

 * If you already have a trusted version of GnuPG installed, you
   can simply check the supplied signature.  For example to check the
   signature of the file gnupg-2.1.0-beta751.tar.bz2 you would use
   this command:

 gpg --verify gnupg-2.1.0-beta751.tar.bz2.sig

   This checks whether the signature file matches the source file.
   You should see a message indicating that the signature is good and
   made by that signing key.  Make sure that you have the right key,
   either by checking the fingerprint of that key with other sources
   or by checking that the key has been signed by a trustworthy other
   key.  Note, that you can retrieve the signing key using the command

 finger wk ,at' g10code.com

   or using a keyserver like

 gpg --keyserver keys.gnupg.net --recv-key 4F25E3B6

   The distribution key 4F25E3B6 is signed by the well known key
   1E42B367.

   NEVER USE A GNUPG VERSION YOU JUST DOWNLOADED TO CHECK THE
   INTEGRITY OF THE SOURCE - USE AN EXISTING GNUPG INSTALLATION!

 * If you are not able to use an old version of GnuPG, you have to verify
   the SHA-1 checksum.  Assuming you downloaded the file
   gnupg-2.1.0-beta751.tar.bz2, you would run the sha1sum command like this:

 sha1sum gnupg-2.1.0-beta751.tar.bz2

   and check that the output matches this:

3d6dd8a35780626428d98dba80dbbc5c27ac  gnupg-2.1.0-beta751.tar.bz2



Documentation
=

The file gnupg.info has the complete user manual of the system.
Separate man pages are included as well; however they have not all the
details available in the manual.  It is also possible to read the
complete manual online in HTML format at

  https://www.gnupg.org/documentation/manuals/gnupg-devel/

The chapters on gpg-agent, gpg and gpgsm include information on how
to set up the whole thing.  You may also want search the GnuPG mailing
list archives or ask on the gnupg-users mailing lists for advise on
how to solve problems.  Many of the new features are around for
several years and thus enough public knowledge is already available.

Almost all mail clients support GnuPG-2.  Mutt users may want to use
the configure option "--enable-gpgme" during build time and put a "set
use_crypt_gpgme" in ~/.muttrc to enable S/MIME support along with the
reworked OpenPGP support.


Support
===

Please consult the archive of the gnupg-users mailing list before
reporting a bug .
We suggest to send bug reports for a new release to this list in favor
of filing a bug at .  We also have a dedicated
service directory at:

  https://www.gnupg.org/service.html

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

Re: GnuPG 2.1.0-beta442: t-timestuff.c:118: test 17 failed

[Werner Koch]

On Tue, 24 Jun 2014 04:38, ca+gn...@esmtp.org said:

> This patch (hack?) fixes it for me (local timezone is PDT).

I changed the test to use timegm and only if that is missing I use this
patch.

Thanks,

  Werner

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


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