Re: Promoting the usage of OpenPGP (was: Re: Renewing expiring key - done correctly?)

2013-12-05 Thread Hauke Laging 
Am Do 05.12.2013, 21:38:50 schrieb Ingo Klöcker:
> On Thursday 05 December 2013 19:47:57 Hauke Laging wrote:
> > BTW, OT: May I point you at this?
> > https://bugs.kde.org/show_bug.cgi?id=318005
> > https://bugs.kde.org/show_bug.cgi?id=326476
> > https://bugs.kde.org/show_bug.cgi?id=326477
> 
> I'm sometimes pondering a different approach.

That's OK but I think its obvious that in the current situation (i.e. some 
public attention for the subject but still ridiculously small numbers of new 
users with no prospect of real change) we have to at least try *everything* 
that seems to make sense and can be done at nearly no effort. The resources 
are VERY limited. The "let someone else do that" attitude simply does not work 
here.

This is the archive of the international Cryptoparty mailinglist:
http://cryptoparty.is/pipermail/global/

Does that look like a lot is going to happen beyond small groups who organize 
events? Not to me. I am extremely – the diplomatic wording would be: – 
disappointed about it how many people and organizations (quite related to the 
subject) do not even give the support which they could deliver at nearly no 
effort. I guess we need both a public hall of fame and a hall of shame which 
the media can be pointed at every time they call.

It seems like a joke to me that I get hardly any feedback from the IT and 
political community (let alone positive feedback; thus even though that wasn't 
a positive response it already made you a positive exception) but good 
feedback and support from the cultural community. WTF?


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

Promoting the usage of OpenPGP (was: Re: Renewing expiring key - done correctly?)

2013-12-05 Thread Ingo Klöcker 
On Thursday 05 December 2013 19:47:57 Hauke Laging wrote:
> BTW, OT: May I point you at this?
> https://bugs.kde.org/show_bug.cgi?id=318005
> https://bugs.kde.org/show_bug.cgi?id=326476
> https://bugs.kde.org/show_bug.cgi?id=326477

I'm sometimes pondering a different approach. I'm quite pessimistic 
about being able to educate the general population about OpenPGP. 
Therefore, I'm wondering whether it wouldn't be better if we, the 
developers of Free Software mail clients, made the usage of OpenPGP (or 
S/MIME) for email as transparent to the users as possible. Ideally, the 
users wouldn't even have to notice that they are communicating via 
encrypted email.

Unfortunately, I think email is a lost cause because there are so many 
different mail clients that will never support encryption. I think we 
have a much better chance to replace email with something new that has 
end-to-end encryption (and probably also authentication) built in than 
we have to fix email.


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: Is there a chance smartcards have a backdoor? (was Re: Any future for the Crypto Stick?)

2013-12-05 Thread Kristian Fiskerstrand 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 12/05/2013 08:08 PM, Peter Lebbing wrote:
> On 05/12/13 13:20, Paul R. Ramer wrote:
>> On that note, why assume that the manufacturer would not do the
>> opposite: feign helping the spy agency by giving them a
>> compromised ROM and then substituting a secure one on the real
>> product. In either case, we are assuming the company would try to
>> supply different bodies with different ROMs.
> 
> We're debating the risk that a card is backdoored. If there is such
> a risk, that risk still exists if we allow for the possibility that
> manufacturers try to do what you say. They're not mutually
> exclusive; how come you infer that I assume that the manufacturer
> would not do the opposite?
> 

The smartcard having a bad RNG as seen in [0] springs to mind.

References:
[0]
http://sites.miis.edu/cysec/2013/10/10/taiwans-citizen-smart-card-plan-compromised-by-bad-rngs/


- -- 
- 
Kristian Fiskerstrand
Blog: http://blog.sumptuouscapital.com
Twitter: @krifisk
- 
Public PGP key 0xE3EDFAE3 at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3
- 
"Great things are not accomplished by those who yield to trends and
fads and popular opinion."
(Jack Kerouac)
-BEGIN PGP SIGNATURE-

iQIcBAEBCgAGBQJSoNKKAAoJEAt/i2Dj7frjgacQAKftpqC3shsP1p4oF1Ksdd25
bjS1lX/SsGUKe5ynKr6elY7NxAea6L7QH5yP9uinBYDGpZnUV9JcNAyYtwUwYlDS
MwPoYXcOdoYVe/cSIJflARDBzDDdaLw/51O/4ZReeYUjOQlz5Lr+JqO0O/02FcwJ
E3jKHkQo44CbpYEqF3LAIl7qua2eMwNV99hxvuUQxrj3k3FJAZaPrAP9duJkA9BA
Ssvq4iBWVgikPw8jrefBrzhIpSTjSYSslXEJzgBnYsQ6zbPtWnX/15cVz8n4GWiI
o06A7Obx1siIzOL/S+nJK1jv8as3JU/Q5Xh5OfvmiXhjljhjQr0lKo4DMEaQ4z6B
IPJODsL8Pe6u44kC+qyZ0JABFxUlDPh4RD8xpFeJBizZPajoYfJWBEyNuW0swB5J
L2WZqRITYiz/epQROp6SLPY06O2ym78twwjM/ldtH1dgVqygze15aNB0onHeSZd7
8LDvm4Dnn4F259nuPyJ0ejjtvupOu/DkHE8UShynEELuFIrxenEEULplISRJ8To9
d+bwEaX0nfPMSbj6j8cBsMa1YyxI2NHqmgPweqc9UB+FUi6Mc6/W9HfRH5XgAW+J
sSZDWJvOBLWMAf6qOnCIK6WmhhlPY0YYiFQByiBF3idmVIj4iAokbr7kHvPepIMj
6tzH0YpBaNF9wSLh7tMh
=fTni
-END PGP SIGNATURE-

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

Re: Renewing expiring key - done correctly?

2013-12-05 Thread Ingo Klöcker 
On Thursday 05 December 2013 19:47:57 Hauke Laging wrote:
> Am Do 05.12.2013, 19:30:07 schrieb Ingo Klöcker:
> > your assertion is correct.
> > 
> > 
> > In the first scenario
> > 
> > > > a) the key has been compromised and revoked and you don't know
> > > > that
> > > > (because your last certificate update was before the revocation
> > > > publishing)
> > 
> > it is incorrect because the attacker cannot extend the validity of
> > the revoked key.
> 
> You misunderstand the attack.

No. I don't. :-) The attack involving control over the system time came 
up later in the thread.

For every countermeasure there is an attack that circumvents this 
countermeasure, bribery and torture probably being the most effective 
attacks. But this doesn't mean that your argument for using key 
expiration, i.e. to "force" the users of the key to update the key 
regularly, is wrong. It just means that your argument doesn't work if 
your adversary can control your system clock. OTOH, your argument works 
if the key has been compromised by an adversary like me and you, e.g. by 
a colleague of the key owner (who does not happen to work for a three 
letter organization).


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: Any future for the Crypto Stick?

2013-12-05 Thread Einar Ryeng 
On Sun, Dec 01, 2013 at 01:21:56PM +0100, arne renkema-padmos wrote:
> On 12/01/2013 12:45 PM, Einar Ryeng wrote:
> >
> >Any news on the crypto stick (or similar initiatives) would be appreciated.
> 
> An OpenPGP card with something like a Gemalto SIM usb adapter would
> seem to fit the bill.

Thanks for the replies.

I've got some Crypto Sticks, so for my own use I'm covered for the time being,
but I was wondering what to recommend to friends who have been trying to buy
crypto sticks without luck for some time now.

Gemalto SIM USB adapter seems to be sort of the same thing as the Crypto Stick.
However, it is a bit more hassle to get a USB adapter and a smart card, cut the
card to fit etc.

The yubikey solution mentioned in the thread seems simpler in that regard, and
depening on your use, you may or may not be worried that NSA or some other
service has wrangled some kind of backdoor into it (which I doubt, except if
they've done it by compromising security standards). None the less I'd probably
opt for open solutions for my personal use just due to ethical/political
reasons, but would have no worries about using Yubico stuff at work.

Cheers,

-- 
Einar Ryeng


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

Re: Any future for the Crypto Stick?

2013-12-05 Thread Robert Holtzman 
On Thu, Dec 05, 2013 at 04:20:42AM -0800, Paul R. Ramer wrote:
> Peter Lebbing  wrote:
> >On 02/12/13 20:37, Andreas Schwier (ML) wrote:
> >> Wait a second - you can not simply hide a backdoor in a Common
> >Criteria
> >> evaluated operating system. There are too many entities that would
> >need
> >> to be involved in the process
> >
> >Why couldn't the manufacturer simply put a different, backdoored
> >firmware in the
> >card ROM than the one they showed to the other entities? Are those
> >other
> >entities physically examining the ROM mask of the final product or
> >somehow
> >bypassing the code protection and reading out the flash ROM?
> 
> On that note, why assume that the manufacturer would not do the opposite: 
> feign helping the spy agency by giving them a compromised ROM and then 
> substituting a secure one on the real product. In either case, we are 
> assuming the company would try to supply different bodies with different ROMs.

Probably because the company might be open to criminal charges. I
understand that the NSA has used this threat in the past.

-- 
Bob Holtzman
Your mail is being read by tight lipped 
NSA agents who fail to see humor in Doctor 
Strangelove 
Key ID 8D549279


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

Is there a chance smartcards have a backdoor? (was Re: Any future for the Crypto Stick?)

2013-12-05 Thread Peter Lebbing 
On 05/12/13 13:20, Paul R. Ramer wrote:
> On that note, why assume that the manufacturer would not do the opposite: 
> feign helping the spy agency

By the way, there's a big difference. In the scenario that they install a
backdoor but don't show it to the certification entities and such, they do that
because they're forced to do so by the NSA (the NSA wouldn't want their backdoor
certified :). If they feign helping the NSA, they aren't forced to do that, it
would be their choice.

> In either case, we are assuming the company would try to supply different
> bodies with different ROMs.

But they are completely different circumstances: force versus own choice.

Peter.

-- 
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at 

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

Is there a chance smartcards have a backdoor? (was Re: Any future for the Crypto Stick?)

2013-12-05 Thread Peter Lebbing 
On 05/12/13 13:20, Paul R. Ramer wrote:
> On that note, why assume that the manufacturer would not do the opposite:
> feign helping the spy agency by giving them a compromised ROM and then
> substituting a secure one on the real product. In either case, we are
> assuming the company would try to supply different bodies with different
> ROMs.

We're debating the risk that a card is backdoored. If there is such a risk, that
risk still exists if we allow for the possibility that manufacturers try to do
what you say. They're not mutually exclusive; how come you infer that I assume
that the manufacturer would not do the opposite?

But anyway:

So the NSA simply buys a card from a shop, and notices that it doesn't respond
to the backdoor command. Or they want to use the backdoor to get a suspect's
private key, and again, the card does not respond. How is the manufacturer going
to talk its way out of that?

However, if you're up against specific investigation by the NSA (not the dragnet
method), I think pretty much anybody will lose, backdoor or not. If they can't
extract your private key, they'll simply hack your computer and batch up
decryption requests to be bundled with your own next access of the card, or
something similar, or something really smart I didn't think of. So it's really a
question if it matters whether the NSA has a backdoor or not :).

Peter.

PS: the new subject line is very verbose because I wanted to avoid the risk that
people interpret "Chance smartcard backdoored" as a statement rather than a
question.

-- 
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at 

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

Re: Renewing expiring key - done correctly?

2013-12-05 Thread Hauke Laging 
Am Do 05.12.2013, 19:30:07 schrieb Ingo Klöcker:

> your assertion is correct.
> 
> 
> In the first scenario
> 
> > > a) the key has been compromised and revoked and you don't know that
> > > (because your last certificate update was before the revocation
> > > publishing)
> 
> it is incorrect because the attacker cannot extend the validity of the
> revoked key.

You misunderstand the attack. If you completely control the system time (which 
is not realistic for big discrepancies, of course) then you can prevent the 
certificate from becoming invalid: You never reach the expiration date.

BTW, OT: May I point you at this?
https://bugs.kde.org/show_bug.cgi?id=318005
https://bugs.kde.org/show_bug.cgi?id=326476
https://bugs.kde.org/show_bug.cgi?id=326477


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

Re: Renewing expiring key - done correctly?

2013-12-05 Thread Ingo Klöcker 
On Tuesday 03 December 2013 19:03:13 Robert J. Hansen wrote:
> On 12/3/2013 6:20 PM, Hauke Laging wrote:
> > Imagine a certificate which is always prolonged for just one day. If
> > this gets compromised then it will not be prolonged any more (at
> > least not by its owner but we all love our highly secure offline
> > mainkeys, don't we?) so everyone will notice that within hours.
> 
> 1.  The attacker can just extend the validity himself.  He's
> successfully compromised the key, after all.
> 
> 2.  As a consequence of #1, no one will notice.

In your quotation you've snipped away too much of Hauke's message. Hauke 
gave two scenarios. In the second scenario

> > b) the key has been compromised and cannot be revoked (because the
> > owner has lost access to the secret mainkey and has neither a
> > revocation certificate nor a (usable) designated revoker)

your assertion is correct.


In the first scenario

> > a) the key has been compromised and revoked and you don't know that
> > (because your last certificate update was before the revocation
> > publishing)

it is incorrect because the attacker cannot extend the validity of the 
revoked key.


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: Any future for the Crypto Stick?

2013-12-05 Thread Paul R. Ramer 
Peter Lebbing  wrote:
>On 02/12/13 20:37, Andreas Schwier (ML) wrote:
>> Wait a second - you can not simply hide a backdoor in a Common
>Criteria
>> evaluated operating system. There are too many entities that would
>need
>> to be involved in the process
>
>Why couldn't the manufacturer simply put a different, backdoored
>firmware in the
>card ROM than the one they showed to the other entities? Are those
>other
>entities physically examining the ROM mask of the final product or
>somehow
>bypassing the code protection and reading out the flash ROM?

On that note, why assume that the manufacturer would not do the opposite: feign 
helping the spy agency by giving them a compromised ROM and then substituting a 
secure one on the real product. In either case, we are assuming the company 
would try to supply different bodies with different ROMs.

It is not that the mentioned scenario is impossible. It is that it just seems 
like too much effort to be made by a company that has no benefit in such 
duplicity.

Cheers,

--Paul


--
PGP: 3DB6D884

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

Re: Much slower than other block cipher implementations?

2013-12-05 Thread Will Bryant 
Hi Kosuke,

On 5/12/2013, at 15:41 , Kosuke Kaizuka  wrote:
> Which version of GnuPG (ligcrypt) and OS are you using?

We're using 1.4.11 on Ubuntu 12.04, on x86-64.  The libgcrypt11 package is 
1.5.0.

> 3. GnuPG 2.0.x on x86-64
> Ligcrypt 1.5 branch does not support AES-NI yet on x86-64 environments.
> Support of AES-NI on x86-64 has been implemented to ligcrypt master[1], but 
> not
> backported to current 1.5 branch[2].

Ah, thanks - that sounds good, I look forward to it.

I was wondering how much difference the AES-NI instructions make so today I 
went back to an older server running the same OS, architecture, and GnuPG 
version.  On this server GnuPG encrypts at around 11 MB/s but OpenSSL encrypts 
at well over 100 MB/s (which surprised me).

So the difference seems to be mostly due to other factors.

I think Werner's email explains much of the remaining differences though.

Thanks both,
Will___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Much slower than other block cipher implementations?

2013-12-05 Thread Werner Koch 
On Thu,  5 Dec 2013 03:41, cai.0...@gmail.com said:

> As far as I know, only GnuPG 2.0.x on x86 environments supports AES-NI.

Right.  I addition you can't compare it with a simple block cipher as
implemented by OpenSSL.  OpenPGP does a lot more: It hashes the text to
create a signature (which most uses do).  A kind of MAC is computed to
detected manipulations of the ciphertext.  The data is compressed.  The
data is split up into parts so that you do not have an optimal
alignment.  GnuPG may decide to use the slow 3DES algorithm (unlikely
these days) and in general it has never been optimized for highest speed.


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