Whishlist for next-gen card

[NdK]

Hello all.

What I'd like to see addressed in future card specifications:
1 - support for more keys (expired ENC keys, multiple signature keys)
2 - different PINs for different keys
3 - separate key for NFC auth (with its own optional PIN)
4 - HOTP PINs for signature/certification keys
5 - possibility to export private keys to user-certified devices
6 - support for out-of-band authorization (HW)
7 - support for more informative signing (requires a small display: HW)

3 to 6 should be under a "policy" object connected to the main key to
make it public and let relying parties evaluate how much trust to give.

Since smartcards have evolved (slowly...) and nowadays we have other
much-less-constrained alternatives (GnuK), I feel that many limitations
are just an heavy heritage that's becoming nonsensical.

The reasons behind my list, point by point:
1 - I'd like to roll the key used for reading mail every year, but
currently that would mean I'd have to use a new card every year or have
old keys on-disk, defeating the purpose of using a smartcard/token (from
my tests on actual smartcards, it's not hard to have room for 14 to 20
keys on an 80k smartcard, more than 30 on a 144k one, WAY more are
possible on GnuK)
2 - If I have to use my card to login on a possibly untrusted computer,
I don't want it to steal my PIN and sign/certify without me knowing it
3 - Since NFC readers often have no pinpad (or could have easily been
tampered with) I don't want to expose my main PIN nor the same key I use
for "wired" auth
4 - since HOTP changes at every use, it makes keyloggers nearly useless
and gives a third factor to the auth process (might be combined by
simple means -like digit-by-digit addition modulo 10- to the PIN)
5 - I know, it's debatable and many see it as dangerous... but is it
more dangerous than keeping an on-disk (or on-paper) copy of the key?
Key export should be protected by a "certificate" (policy object defines
an "allowed KeyID for export" and the private key is exported only
encrypted to that KeyID); might even set a "fuse" to mark the fact that
the key have been exported
6 - like in Yubikey NEO, a physical button to authorize some operations
can be useful (certification, signature, NFC PIN-less auth)
7 - malaware currently can replace the hash of the object being signed
and the user can't know it till it's late... a small display could be
used to report some metadata (file name type and size for signature,
keyID and owner data for certification, peer ID for auth...) to give the
user more feedback

What do you think? Complete BS or could something be considered for
inclusion?

PS: 1 is the main reason I'm not yet using GPG much, even if I started
using it since DOS & FIDO-BBSs era...

BYtE,
 Diego.

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

Re: Whishlist for next-gen card

[NdK]

Il 20/02/2015 11:36, Jonathan Schleifer ha scritto:

>> 1 - support for more keys (expired ENC keys, multiple signature keys)
> And maybe for storing a certification key with a different PIN.
Wasn't it covered by
2 - different PINs for different keys
? :)

>> 5 - possibility to export private keys to user-certified devices
> That pretty much defeats the point of using a smart card in the first place.
That's not "uncontrolled export", and in fact such a feature is
implemented in HSMs to avoid unsafe key generation (outside the HSM
itself) *and* the risk of key loss.
The idea is that *before* creating/importing the master key, you set the
policy, including the key ID (or IDs) that can ask for key export. Once
the master key gets created, you no longer can alter the policy. The
policy should be exported together with the key and override the
existing one while importing a key (so that you "can't" alter -actually
it's just "really hard", but doing that should invalidate signatures on
your master key!- the policy by exporting from a device and importing on
another).

>> 6 - like in Yubikey NEO, a physical button to authorize some operations
>> can be useful (certification, signature, NFC PIN-less auth)
> That would be a pretty useful thing, but require you to trust the card
> reader. This, however, would really make sense on the Gnuk and I guess
> you could even do that without changing the spec.
Nope. it's possible to have (at least I've seen one: my father does have
it!) smartcards with small displays, keyboards (1-2 keys could be
enough, but a full 4x3 keypad would be awesome!) and even
batteries/solar panels! The form factor is not the real problem. The
problem is that it's quite a close and secretive market, heavily relying
on security by obscurity (when I asked Yubikey how to access the "user
presence" key from a Java appled, they answered I'd have had to contact
NXP and sign an NDA!
So no need to trust the card reader :)

BYtE,
 Diego.


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

Re: Whishlist for next-gen card

[NdK]

Il 20/02/2015 16:07, Ville Määttä ha scritto:

 5 - possibility to export private keys to user-certified devices
 That pretty much defeats the point of using a smart card in the first 
 place.
>> That's not "uncontrolled export", and in fact…
>> …(snip)…
>> while importing a key (so that you "can't" alter -actually
>> it's just "really hard", but doing that should invalidate signatures on
>> your master key!- the policy by exporting from a device and importing on
>> another).
> There in lies the problem. It's really hard -> it's doable.
Yes, by someone who controls the trusted export key. On the other hand,
current method to generate on a "secure" system and move to card makes
it easy to lose control of the key.

> What is the use case that absolutely needs exportable master keys?
Safe key recovery in case sc gets damaged. With the current system you
have to always generate new keys on the "secure system" and store the
backup in a safe place that is *not* a smartcard.

BYtE,
 Diego.

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

Re: Help need to use truecryt + openpgp applet.

[NdK]

Il 21/02/2015 03:01, Matthias-Christian Ott ha scritto:

[...]
> it finds PKCS #11 objects on the card). That said, I doubt using the
> private DOs for PKCS #11 objects and associated metadata will be
> generally accepted (other people could be storing other data in these
> data objects), so you would probably have to add a compile-time option
> or maintain a fork.
Then maybe, a simple (disabled) SIM card from an old phone contract (I
usually have about a dozen around) could be better suited for the job,
since there's no on-card crypto involved. Just store the secret in an
SMS, with the "sender" set to the ID of the protected storage :)

Ok, end of OT.

BYtE,
 Diego

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

Re: Help need to use truecryt + openpgp applet.

[NdK]

Il 21/02/2015 12:26, Peter Lebbing ha scritto:

>> Or use a plain USB stick.
> Hehe :). I think what Diego means, is that a SIM card can still be protected 
> by
> a PIN. You would need to enter the PIN before you had access to the SMS,
> similarly as the private DO's on the OpenPGP card.
Exactly. Moreover, it's often "free" since you don't have to buy a new
card just for that use, just recycle an unused one.

BYtE,
 Diego

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

Re: Whishlist for next-gen card

[NdK]

Il 21/02/2015 12:51, Peter Lebbing ha scritto:

>> 1 - support for more keys (expired ENC keys, multiple signature keys)
> Yes! This would be a great feature to keep expired encryption keys on a card. 
> I
> personally would have no use for more than 1 signature and 1 authentication 
> key,
> but I don't see a reason why you wouldn't just have a whole bunch of generic 
> key
> slots and only indicate its intended usage on creation/upload so people can do
> that as well.[1]
Yup. But if those are too generic, then it could be way cheaper to just
use a generic PKCS#15 card (I've had some experiences with Aventra ones:
they've got space for many keys and 14 PINs... and are quite cheap!).

> If ECC were supported by the card, you'd need quite a lot less storage to keep
> all these keys.
Yup. But on a device like GnuK space is really not the limiting factor.

>> 2 - different PINs for different keys
> This would partly amount to resurrecting an old feature. IIRC, there were 2 
> user
> PINs in the v1.1 spec, but the v2 spec pretty much retired the second PIN. 
> Don't
> take my word for it, though, check the spec.
I remember seeing an unused PIN object.

[...]
> However, I think the primary key/subkey feature is already covered pretty well
> by simply having two smartcards (it's what I do).
Twice the cost, twice the risk of losing one, twice the management burden...

>> 3 - separate key for NFC auth (with its own optional PIN)
> Sounds like an interesting concept. I don't know how much work it would be to
> have the ISO 7816 parts needed by the OpenPGP card really working for NFC. Do
> you just exchange the lower few communication layers (physical, data, ...) and
> is everything above the same for the subset of ISO 7816 you need? I haven't
> looked at NFC yet.
I started implementing it on MyPGPid. From JavaCards it's quite easy to
differentiate between wired and wireless, since the applet receives the
protocol used to transmit the APDU.

> What I'm hinting at: NFC and cards with contacts are different enough that it
> might warrant handling NFC separately from the rest and hence doesn't need to 
> be
> "integrated into" the process for determining the next cards-with-contacts
> standard and implementation.
There are dual-interface cards, and I think they're not so disjoint,
once you're using secure messaging.

> But NFC authentication through asymmetric crypto sounds interesting.
Way more than EM4100 tags or MIFARE cards.

>> 4 - HOTP PINs for signature/certification keys
> What generates the HOTP then? Do you type a PIN on the HOTP device to get the 
> HOTP?
No need. Just an applet on the phone could do. At least if you aren't
using the same phone to do the crypto.

> What I'm guessing you might mean, is that the HOTP device might be more 
> trusted
> than the pinpad of the card reader: the card reader is connected to the PC. 
> The
> HOTP device is simply a standalone device; is air-gapped. So even if the PC is
> compromised, it will not be able to learn your PIN, which you entered on the
> HOTP device.
As I said, no need for a PIN on the HOTP device. The only important
thing is that it's a *different* device, better if air-gapped.

> Is this what you're getting at?
> I don't really see the use. Smartcards protect extraction of the private key;
> they're not equipped to prevent usage of the key material through a 
> compromised
> PC. So what they can't learn your PIN; they'll just get you to enter it for
> them. I don' see this adding something beyond your point 6, which I'll treat 
> there.
You're authorizing a *single* operation. As you noticed, malaware could
be smart enough to fool the user for decryption (where using HOTP would
be foolish: you'd have to continuously generate new codes just to scan
the mail), but signature is another beast. HOTP could be seen as a
stronger 'alwaysauthenticate' flag.

>> 5 - possibility to export private keys to user-certified devices
> I'm not terribly interested in that. Firstly, you would still need a backup of
> the key the data is encrypted to; the chain has to start somewhere. Secondly,
> provided you can have a trusted system for the generation of the keys, you 
> could
> simply generate them on that trusted system, encrypt them to the key you wish 
> to
> encrypt it to, and then store the encrypted data as you see fit.
Unless you're doing something like SmartcardHSM, where each card gets
initialized with a device attestation key (generated on-card) and its
certificate, so you can choose to trust other cards as long as they're
certified. A more user-centric approach would require a "temporary" CA
(no need for long-term storage of its secret key) that the user uses to
certify keys generated on his own cards. Once the cards have been
certified, the CA key can be deleted. In the worst case, the user won't
be able to transfer his keys to other (newer) devices.

> On-card generation is putting a lot of trust in the on-card RNG as well; I put
> more trust in Linux's PRNG o

Re: Whishlist for next-gen card

[NdK]

Il 21/02/2015 17:54, Daniel Kahn Gillmor ha scritto:

> If the malware is keeping the session keys around, it can just keep the
> session keys for everything you ever decrypt, and use them anyway to
> access your encrypted documents, independent of your button-presses.
Or just sniff the PIN.

> You're right in the abstract: the bandwidth of the "canary button" (one
> bit of LED output "secret key action requested", one bit of input "ok to
> use secret key") is too limited to protect against the sophisticated
> attack you describe, and increasing the bandwidth of the channel
> (e.g. on-device display screen, keypad) makes the UI/UX even more
> infeasibile.  At some point, you just have a second computer attached to
> your computer, and now there is room for that second computer to be
> compromised :/
Well, at least that one would be a dedicated computer, with very limited
connection to the outside world.

And if the idea of a display gets implemented, at least the kind of
operation can be confirmed.

BYtE,
 Diego.

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

Re: Whishlist for next-gen card

[NdK]

Il 22/02/2015 01:46, Yuji -UG- Imai ha scritto:

> For token type card, how about appending one more usb port to connect
> keyboard? It's just for inputing PIN/passphrase or out-of-bound auth
> by hitting the Enter key. USB ten keys like V7 KP0N1-7N0P Numeric keypad
> looks suitable for this purpose. Micro USB plug may be prefarable
> for compact board design.
The problem with off-the-shelf keyboards is that they usually radiate a
pattern that's recognizeable from some distance.
The usual scan on a matrix keyboard activates one column at a time in
fixed order, then checks the rows (possibly one at a time). A safer scan
activates all columns at once, senses the rows, then changes columns to
inputs and rows to outputs activating only the one where the pressed key
is and finally determining the corresponding column. This doesn't
generate a recognizeable pattern.

> I don't like wireless features by two reasons.
Uh? Neither do I. I never understood the reasoning behind IR receiver
for FST-01.

> It may introduce complexity for middleware
> of the card. I like KISS. Another is break visibility to check HSM
> composition validness.
Yup. And it's easily snoopable.

> For FST-01 spesific request, I ask gniibe to consider about case
> design with physical hole
> to tightly bind a token with keyring. 
That's good. But I'd avoid plastic in favour of aluminium :)

BYtE,
 Diego.

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

Re: Unattended signing

[NdK]

Il 25/02/2015 00:01, Peter Lebbing ha scritto:
> On 24/02/15 23:16, Daniel Kahn Gillmor wrote:

> If you asked me to /destroy/ the key, I would look through my drawers for all
> backups I have and do a "shred" on them, and think really hard where any 
> further
> copies might have ended up.
Use a smartcard and generate on-card a new key that replaces the expired
one. So an attacker could still abuse the key (it's not protected) but
can not extract it to keep copies around.
I really like SCs for signature and authentication[*] keys since often
even if those keys are lost it's not a big deal as long as they can't be
abused.

[*] for auth, only if there's a centralized repository for the public
key, else updating all instances of the pub key stored in devices could
be a major hassle.

BYtE,
 Diego.

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

Re: Whishlist for next-gen card

[NdK]

Il 27/02/2015 19:43, Peter Lebbing ha scritto:

> I don't understand the practical difference between HOTP and the button
> to confirm an action.
That the HOTP doesn't need HW support so it can be implemented in
standard smartcards.

>> If that info is embedded in the signature packet, it could add something
>> to the signature value (if the receiving party sees that signature is
>> about a txt file and the presented object is a doc, there's something
>> wrong and suspect).
> Are you proposing that the internal hash state after the hashing of the
> document is handed over to the smartcard, after which the smartcard
> computes the hash over the signature subpackets that you want protected
> this way? It's unclear to me how you see such a thing be implemented
> without passing all data to the smartcard.
Well, IIRC there are cards that require you to compute all but the last
round of the hash, then pass the last block of data and the current
state to let them compute the result (and maybe do the padding before
signing). Something similar could be used for this: the last block will
include the shown data just before the file len.

> I've had a quick look in RFC 4252, with public key user authentication
> for SSH2. I don't think there's anything that you can show on a display
> that would help the user decide if it were what they wanted to see.
> After a really quick glance in the RFC, I see just the username and the
> session identifier. The username is hardly unique (I usually use peter),
> and the session identifier is a unique number computed for the SSH
> session. It's the bit that prevents signature replay attacks but is not
> useful to show on a display, since the user can't tell whether it's good
> or not: it's just the output of a hash function.
For auth it should be the hash of the host's pub key, the same SSH shows
you the first time you connect to that host.

> All this is based on a really quick read of documentation I hadn't
> consulted before. It could be glaringly wrong. But when you said "it is
> the fingerprint", I wondered if you misunderstood or that the
> fingerprint is actually part of the challenge. I don't think it is.
Since the challenge have to be encrypted to the host's pub key, you can
display its hash. I'll have another look at the RFC tomorrow morning...

BYtE,
 Diego.

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

Re: Whishlist for next-gen card

[NdK]

Il 01/03/2015 21:54, Peter Lebbing ha scritto:

> No, I'm talking about that as well. And I don't think the fingerprint of
> the host is part of the signed data or the signature. Why do you think the
> fingerprint of the host is part of that?
Because I didn't remember well the SSH protocol...

> By /host/ authentication I mean that you verify that the host your are
> connecting to is in fact the host you wanted to connect to; and /that/ is
> through the public key of the host, of which you can verify the fingerprint.
> Let's call this keypair A.
That gets verified during initial key setup.

> After you've verified the fingerprint, a copy of the hosts' public key, A, is
> stored in ~/.ssh/known_hosts on your client machine.
Ok, just something to help the user avoid a verification step every time.

> But when the host is authenticating that you are in fact the user you are
> claiming to be, you sign a challenge that only you could sign because you have
> the private key, let's call it B. That is /user/ authentication.
Ok.

> The host checks that your public key B is in ~/.ssh/authorized_keys on the
> server machine; if so, you're authenticated.
Ok.
But the signature contains the session identifier (called H in RFC4257
sec 8), that is derived from the initial key exchange (that should then
be partially handled by the card as well). Luckily there's no need to
recalculate it when keys are refreshed (RFC4257, sec 7.2), so it's
one-time penalty.

So the "card" should receive (and handle) the key exchange, prompting
the user to accept the public key the server sent and then allow the
auth key to just sign data where the session id is the one it
calculated. Might be non-banal to handle concurrent ssh sessions with
overlapping key exchanges (card generates a "blob" --might be
symmetrically encrypted with a key only known to the card-- that's
"cached" by ssh and passed back to the card when a new auth signature is
requested for an existing session id?).

BYtE,
 Diego.

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

Re: s2k-cipher-mode default

[NdK]

Il 02/06/2015 20:37, Daniel Kahn Gillmor ha scritto:

> But if we move to AES-256, we remove this attack, which means
> that none of our users get thrown under this particular bus.
What if by changing to AES-256 you end up saving one from the bus by
throwing all users under the train?

IIRC, I read (some years ago...) that AES-256 could be *weaker* than
AES-128 because some mathematical structures express some properties
only with the longer keys. I don't have the paper handy ATM, but I
vaguely remember that shocking conclusion.

BYtE,
 Diego.

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

Re: Hardware Keyring

[NdK]

Il 09/06/2015 10:19, Antoine Michard ha scritto:

> - FST-01 : Can be entropy device
> (NeuG ), can be
> upgraded (need ST-LINK/V2), Only one enclosure with no attach. And Open
> Source Too
That's the one I like most, given my security needs. Remember that it's
not as hardened as a smartcard if the attacker gains unsupervised
physical access to it for a long enough time. But it uses ommodity
hardware you can source where you prefer, so a backdoor is really *much*
less probable!

And the creator reads this list, too! :)

The only thing I really miss is that the trust db is not in the token,
but integrating it would require changes/extensions to the protocol.

BYtE,
 Diego.

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

Re: [Announce] GnuPG 2.1.5 released

[NdK]

Il 12/06/2015 02:34, NIIBE Yutaka ha scritto:

>   http://www.g10code.com/docs/openpgp-card-3.0.pdf
Really interesting!

Especially section 4.1.3: IIUC, that allows for out of band
authorization of the crypto ops.

I'll have to study better the code for GnuK and how to make that little
beast^H^H^H^H^H ARM handle inputs... :) Or maybe a display + buttons via
i2c (as the "display" capability is announced by b8 in sec 4.1.3.2 .

Too bad it seems still limited to the "standard set" of keys. No way to
store old dec keys (to keep using a single card to read all the old
mails, even if generating a new key every year).
A possible workaround would be a "parallel" application on the card that
when called changes the active DEC key together with the card serial no,
corresponding fingerprint in C5 DO and gentime in CD DO).

BYtE,
 Diego.

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

Re: gpg-2.1.6 scdaemon: cannot disable OpenPGP application

[NdK]

Il 09/07/2015 06:56, NIIBE Yutaka ha scritto:

> Currently, in the source code of GnuPG, we have support of following:
>   DINSIG (DIN V 66291-1)
>   German Geldkarte
>   OpenPGP card
>   pkcs#15 card
>   SmartCard-HSM
>   Telesec NKS card
So I could use any pkcs#15-formatted card to keep GnuPG keys?
I searched a bit but saw no docs on what needs to be done...

BYtE,
 Diego

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

Re: Optimal setup for corporate keys

[NdK]

Il 20/07/2015 02:44, F Rafi ha scritto:

> We will have decryption processes on multiple servers. So if one server
> happens to get compromised, I want to avoid the disruption of reaching
> out to 40 partners to exchange keys again. We would only reach out to
> the affected partners with new keys.
If possible, I'd go for the HSM route (openpgp card or FST-01). This
way, if a server gets compromised remotely, the attacker can not get a
copy of the key (but he'll be able to use it as long as his activity on
the server is not detected!).
If the attacker obtains physical access to the server, you're toasted
anyway.

Just my .02 ...

BYtE,
 Diego

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

Re: protecting pub-keys from unwanted signatures

[NdK]

Il 16/08/2015 18:04, Einar Ryeng ha scritto:

> Is there any other problem arising from someone signing your key without
> "permission"?
The only problem I see is that you can easily get associated with the
wrong people. Like what happened here in Italy with Fidobust (about 25
years ago): some pirates' phone lines were being tapped, and since they
connected to Fidonet BBSs, those got tapped too... then their lines were
tapped and the other nodes they connected to became "suspects" and so
on. As a result, a lot of people have had their bedrooms (where they
kept the BBS PC) locked for the YEARS needed by "justice" to do its work.

That's why my skin crawls when Robert J Hansen says
> Except that 99% of people who see that signature will think you have
> an association with white supremacists.
> Should they?  No.
> Will they?  Yes.
Especially if one of those is a judge. When the average person have to
pay for a lawyer, (s)he has already lost.

BYtE,
 Diego

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

Re: Multiple GPG public keys with one private keys

[NdK]

Il 27/08/2015 08:02, Divya Vyas ha scritto:

> I am looking at generating multiple public keys with one private keys.
> As I have multiple identities. I dont want to generate separate keypair.
You can have multiple identities associated with one keypair, eventually
using different subkeys for different purposes.
But this "links" all your identities together, that could be undesirable
in some situations.
The only alternative is to generate different keypairs to keep
identities "unlinked", like if they belong to different people (good
luck having 'em signed by others!).

BYtE,
 Diego

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

Re: gpg agent forwarding (via ssh) totally broken with 2.1 and NFS-mounted $HOME

[NdK]

Il 21/09/2015 15:06, Werner Koch ha scritto:

> You create a plain file ~/.gnupg/S.gpg-agent with this content:
Why isn't the hostname included in file name? This way shared
filesystems would have no problems..

BYtE,
 Diego


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

Re: absolutely nothing to panic over

[NdK]

Il 25/10/2015 08:40, listo factor ha scritto:

[...]
> enough, we now see the cracks in the basement: advances in
> computing technology are corroding the fundamental algorithms,
> one by one...
Unless you move to another family of algorithms based on
information-theoretic limits on what an eavesdropper can know. Some
methods I remember involve neural networks in the form of tree parity
machines with a hidden layer (mutual learning is provably faster than
learn-by-watching), others use noisy channels (say readings from a
distant radio-source in deep space), others put a limit on the amount of
data an attacker could store...

All those have in common is that they require quite large data transfers
(so they're quite impractical) and the success probability of an attack
is mathematically limited (though quite "high" compared to current PK
and SK crypto, but can be made as small as you like by iterating enough
times). *No* advance in computing power can break 'em, unless it makes a
brute-force attack possible.

If the problem is "just" the birth of quantum computers, then there
already are some practical algorithms that address the issue (NTRU and
McEliece, as already pointed out by others).

BYtE,
 Diego.

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

Re: Crowdfunding USB Security Key for Email- and Data-Encryption - Nitrokey Storage

[NdK]

Il 21/11/2015 12:07, Peter Lebbing ha scritto:

> Personally, I don't really see yet why the latter is so important;
> however, gaining the ability to issue OTP's by simply inserting my own
> OpenPGP card with my own PIN seems serious? Do I misunderstand it? Or is
> it not part of the threat model because the attacker is unable to
> extract the key used for OTP generation?
I didn't look at the code (so this could be completely wrong and I'd be
happy!), but if the OTP key is decrypted using a key in the chip after
verifying that the card accepts the PIN, then it's even worse, since
that master key is in cleartext somewhere outside the smartcard. So,
with some efforts and a good lab the OTP keys can be extracted.

> Anyway, thanks for all your work on the Nitrokey series! I think it's
> great you put so much effort into creating these nifty devices.
Nifty, indeed. Too bad PGP-card spec lacks decryption key archiving (so
that you can change your DEC key every year but keep using the same card
year after year).

BYtE,
 Diego

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

Re: Crowdfunding USB Security Key for Email- and Data-Encryption - Nitrokey Storage

[NdK]

Il 22/11/2015 12:55, Peter Lebbing ha scritto:

> My guess is the OTP shared secret is stored in the non-volatile memory
> of the microcontroller (in plaintext). That memory is reasonably well
> protected against reading out (when properly configured). Sure, it's
> possible with a lab, but it's not cheap. If such adversaries are in your
> threat model, my guess (again) is that the OTP feature of this stick is
> not aimed at you.
The whole stick (and the current OpenPGP card spec) is not aimed at me,
since it lacks the "decryption key history" that I'd need :)

What I don't understand is why they did not use one of the private
objects in the card to store the master key: this way, if the card gets
swapped, the master key becomes inaccessible and the attacker can't use
the OTP secret since it's encrypted with an unavailable key. Sure, it's
not perfect (the master key gets loaded in RAM of the micro) but makes
any attack harder.

BYtE,
 Diego

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

Re: Crowdfunding USB Security Key for Email- and Data-Encryption - Nitrokey Storage

[NdK]

Il 23/11/2015 08:56, Jan Suhr ha scritto:

>> I didn't look at the code (so this could be completely wrong and I'd be
>> happy!), but if the OTP key is decrypted using a key in the chip after
>> verifying that the card accepts the PIN, then it's even worse, since
>> that master key is in cleartext somewhere outside the smartcard. So,
>> with some efforts and a good lab the OTP keys can be extracted.
> The key is stored in the card.
Then, replacing the card replaces the OTP key. No?

BYtE,
 Diego

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

Re: Key selection order

[NdK]

Il 14/01/2016 18:04, Andrew Gallagher ha scritto:

> ... which is why you should never use ToFU. There is no known method of
> secure communication that does not involve out of band verification.
I disagree.
TOFU is what many users do anyway: identity persistence is often more
important than "real" identity... And harder to fake by any opponent
(governments would have no problem creating "fake" identity cards,
passports or anything -- after all that's what they usually do for
"real" ones!). On the other hand, if you saw mails from a single address
signed by the same identity for years, chances are that it's the same
person, even if the name on the identity card is different.

BYtE,
 Diego

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

Re: Key selection order

[NdK]

Il 14/01/2016 21:06, Andrew Gallagher ha scritto:

> Tofu does not guarantee identity persistence. Just because your 
> correspondence hasn't been obviously tampered with (yet) does not mean that 
> someone hasn't been MITMing you all along and biding their time.
As usual, it depends on your attack scenario.
If I have 10-years-old mails from someone I've never met, and all use
the same key, I can assume that either 1) that identity belongs to the
same person or 2) that an attacker MITMed *all* my connections (from
every device I've had wherever I was and to every service I used).
Occam's razor and my "exposure profile" make me think it's 1) :)

In other words, *time* can be considered an 'out of band' channel.

For others, very "high profile", it could be possible that such an
attack might be performed, even if it's quite unlikely, unless there's
*a lot* of money involved.

What I learnt from OpenAlarm is that there's always to balance cost and
security: over a certain limit, costs grow exponentially for marginal
gains in security. So the different options have to be weighted
carefully: you'll have to make different choices if you have to protect
a bank instead of a garage.

BYtE,
 Diego

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

Re: Use of --passphrase-file

[NdK]

Il 19/02/2016 15:17, Harman, Michael ha scritto:

> Thanks Brian. I think I tried this but I couldn’t figure out how to
> completely hide the passphrase so no one could get to it. Maybe I was
> using it incorrectly. Since this is an unattended operation that runs
> day and night, I wanted to secure the passphrase so gpg could get to it
> without human intervention, but not let anyone else see or know where it
> was stored.
What about using a smartcard? You supply the PIN only at boot, then it
stays unlocked ad long as the system is working. This way an attacker
couldn't steal the secret key even if successful at breaking in.

BYtE,
 Diego


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

gnupg-pkcs11 status & future

[NdK]

Hello all.

Is gnupg-pkcs11 still maintained? Files on sourceforge are from 2011...

The idea of using a "standard" key container for GPG keys is appealing,
and it could solve my (very personal, I admit, but maybe others feel the
same) "problem" with having only 3 keypairs (for example I can't rotate
encryption key every year unless I'm prepared to have a different card
per year).
With nearly every card I could have a look at, I can keep at least a
dozen keypairs, so that would reduce to one smartcard every 10 years.

BYtE,
 Diego

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

Re: gnupg-pkcs11 status & future

[NdK]

Il 26/02/2016 16:02, Peter Lebbing ha scritto:

>> Rotating does only make sense if you take the old key soon offline.
> Why is this the case? I must admit I'm fairly comfortable not rotating
> my keys (which are on OpenPGP smartcards). But I can think of lines of
> reasoning where it makes sense to rotate, but still keep the old
> decryption key available.
In my case: every year will have its own PIN, different from the one
used for signing, and *really* different from the one for certification.

> Think: "There's a non-zero chance that someone
> got my private key material, but at least they can only decrypt stuff
> encrypted in 2011, all other years use a different key".
Extreme case: a judge orders to hand over the key to a set of messages
('cause they won't trust your decryption). Rotating keys minimizes
exposure of other material.

> Note in this scenario it is nice if I can still easily access my
> 2011 material as well.
Exactly.

> I'm not saying this is a solid line of reasoning. I'm just curious why
> limiting access to the decryption key is the only thing that makes sense.
Well, everybody can have his own perfectly valid reasons... Why limit
keys on smartcards more than technically necessary? Years ago cards had
space only for 3 keys, but a 144K Javacard can handle many more!
And if PKCS#11 was useable, one could use as many keys as needed by his
policy.

Note that I really don't like PKCS#11, but it's the de-facto standard to
access nearly every crypto-capable device.

BYtE,
 Diego

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

Re: How to sign a PDF using a DNIe

[NdK]

Il 28/06/2016 04:16, NIIBE Yutaka ha scritto:

> I think that it is opposite way what we should make it possible.  Let
> a government accept signature which is generated by our own
> smartcard/token with free software.  Or let a governor certify our own
> public key, where the private key is in our own smartcard/token.
That would be great, but I think it's an orthogonal issue.
When you get to use a smartcard, you are already giving up a lot of
control on your key, trusting something you can't control and hoping
certifiers did their work correctly and the units being sold are
completely like the tested ones.

The support for generic cards could be useful for other reasons. Say I
have a smartcard that could host 15 keys. I'd like to use one for web
auth, another for NFC auth, another for signing documents, another as my
primary GPG identity (certification), one for GPG auth, one for GPG
signing and the others for GPG decryption (just not to lose access to
older mails). Currently it's not possible, unless I use quite a lot of
different cards.

IMO the "ideal" solution would be a FIDO-like system, where keys are
kept, encrypted, on disk and uploaded as "blobs" to the card that
decrypts 'em and only then become useable. That would remove the limit
on the number of keys that could be kept on a card. But it's not
feasible with Java cards, I think (at least I couldn't make it work w/o
writing to the flash memory). That would be completely feasible with
FST-01...

BYtE,
 Diego

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

Re: several GPG smartcards connected at the same time

[NdK]

Il 09/08/2016 02:39, NIIBE Yutaka ha scritto:

> Currently, this configuration is not supported by scdaemon.  I don't
> know any portable technical solution (supporting GNU/Linux, Windows,
> and MacOS X, etc.) to handle multiple card readers (and/or cards)
> simultaneously by a single application.
Isn't it what PKCS#11 is for?
If GnuPG supported PKCS#11 it would open a whole new world, like the
ability to use generic cards.
IMVHO "fixing" GnuPG to handle multiple cards and readers would actually
create something really similar to PKCS#11...

BYtE,
 Diego

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

Re: several GPG smartcards connected at the same time

[NdK]

Il 09/08/2016 10:27, Justus Winter ha scritto:

>> If GnuPG supported PKCS#11 it would open a whole new world, like the
>> ability to use generic cards.
> We have such a module: http://scute.org/
That's exactly the opposite: Scute allows a PKCS#11 app to access an
OpenPGP card (but isn't it redundant, since OpenPGP cards are
supported[1] by native opensc driver?).
If GnuPG/scd supported PKCS#11 you could tell it to use a key on any
non-openpgp card as a GnuPG native key (some configuration could be
required).

[1] https://github.com/OpenSC/OpenSC/wiki/OpenPGP-card

BYtE,
 Diego


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

Re: Attacks on encrypted communicxatiopn rising in Europe

[NdK]

Il 24/08/2016 14:11, Francesco Ariis ha scritto:

> @Johan Wevers: you might or might not be aware, but what you describe
> is the "Four Horseman of the Infocalypse" [1].
Instead of stupid backdoors, couldn't legislators simply say that if
encryption is used to try to hide a crime (that still have to be proven
by *other* means!) then it's like having used a gun in a robbery?
That would simpli make something wrong even worst, but allow for
rightful use of crypto.
Sure, it's way easier to outlaw any non-approved crypto, but then
outlaws will use strong crypto nevertheless...

BYtE,
 Diego

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

Re: smartcard reader

[NdK]

Il 19/10/2016 13:06, Werner Koch ha scritto:

> There is no integrated card.  gnuk uses an SM32 MCU which implements the
> OpenPGP card and CCID interface specs.  This has the huge advantage that
> all software (firmware) is free software.  The drawback is that it is
> not tamper resistant - your safe with important woodware documents or
> your gpg key backup isn't tamper resistant either.  I prefer the free
> software solution given that the attack surface is smaller.
Well, actually the situation is a bit better: the keys at rest are
stored encrypted, even if kdf function uses less rounds not to slow down
unlocking too much... So even if an adversary manages to get the token
and retrieve the memory contents, he still have to find the passphrase
to decode the keys. Quite like the situation where he somehow accesses
your privring from a powered down computer.

BYtE,
 Diego


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

Re: PCI DSS compliance

[NdK]

Il 10/11/2016 16:24, helices ha scritto:

> Our company must decrypt ~100 files 7x24 in near real time. How can 
> work - or any reasonable alternative - in such a production environment?
Wouldn't a smartcard solve (at least partially) the issue?
Insert it in a pinpad reader and have the PIN shared between two
administrators. Both are required at system boot to unlock the card. If
the card gets removed, no single admin can unlock it.
Sure, an admin could just use it while connected to the server to
decrypt files (or simply read stored files) but as others said there's
no way to prevent that if the attacker have physical access to the system.

BYtE,
 Diego


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

Re: Specifying entropy source

[NdK]

Il 16/11/2016 15:55, Juergen Christoffel ha scritto:

> Then there are http://www.bitbabbler.org and
> http://ubld.it/products/truerng-hardware-random-number-generator/ as
> hardware random number generators. Both are worth their money IMO.
Why not GnuK, that incorporates a TRNG too?
There's even a version that only includes the TRNG, and it's completely
open.

BYtE,
 Diego


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

Re: Proof for a creation date

[NdK]

Il 06/12/2016 12:30, Roman Zeyde ha scritto:
> You can also use OpenTimestamps service as described here:
> https://petertodd.org/2016/opentimestamps-announcement
Interesting!

To remain on-topic, I'd like to take the "footnote 3":
-8<--
An interesting nuance to this is someone who has stolen a PGP key could
also create a revocation, and they could backdate it to deny access to
previously created signatures; there’s a lot of interesting design
questions about how to deal with this with random beacons and the like
that are beyond the scope of this blog post
-8<--

That could actually reduce trust in any PGP signature, unless there's a
way to timestamp 'something' that says "as of 'now' this key have not
been revoked". Ideally that attestation should be included with the
signature itself.

BYtE,
 Diego

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

Re: Proof for a creation date

[NdK]

Il 06/12/2016 23:14, Andrew Gallagher ha scritto:

>> That could actually reduce trust in any PGP signature, unless there's a
>> way to timestamp 'something' that says "as of 'now' this key have not
>> been revoked". Ideally that attestation should be included with the 
>> signature itself
> So, essentially OCSP?
That's the idea, but in GPG trust model... Is it possible?

BYtE,
 Diego

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

Re: Proof for a creation date

[NdK]

Il 07/12/2016 00:27, Andrew Gallagher ha scritto:

> I don't see any reason why it couldn't be done in principle - anyone who 
> wants could set up an "authority" that produces a regular, signed list of all 
> the certificates it currently trusts at each point in time. The trick is a) 
> making sure that revocations get submitted to the authority in a timely 
> fashion and b) working out whether to trust the authority in the first place. 
> But that's a problem in OCSP too. 
The "stapling" part is the hardest, since with OCSP usually you need to
verify that something is valid "now", while with a GPG signature you
should be able to attest that something will be valid "forever".
The only way to obtain that (I can think of, and assuming no online
verification: online services come & go...) is having at least three
different kind of keys (RSA, EC, PQ) sign at least three different hash
function results *each*, so that even if an algorithm or two gets
cracked the signature remains valid.

> In general, anything you can do in the X509 trust model you can do in PGP - 
> but with a little more effort and a lot fewer default assumptions. 
That's good: this way most "implicit assumptions" must be explicited and
their security impatc must be evaluated.

BYtE,
 Diego

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

Re: Proof for a creation date

[NdK]

Il 07/12/2016 09:53, Andrew Gallagher ha scritto:

> No signature can possibly attest that something is valid *forever*.
Well, "till the heat death of the Universe" can be enough for any
practical purpose :)

> You're right that stapling is absolutely required in a data at rest
> use case, because a real time service only makes sense for ephemeral
> comms. But it's just a form statement by the authority which the
> sender appends to their signed data.
My aim is something that's still secure even if some big leaps happen.
Say QC becomes feasible: current pki methods (RSA and EC) are to be
considered insecure. Hence I included a PQ signature (maybe NewHope?).

> Trying to protect against future compromise of a signature algorithm is
> really hard. And once you open that door, all data at rest signatures
> are questionable.
Well, actually symmetric crypto could be used with a system like the one
used for one-time signatures: you sign both the (hash of the ) plaintext
and the hash of the cyphertext obtained encrypting that plaintext with a
(randomly generated, single use) secret key.
This system allows a single arbitration: you give the judge the secret
key used and he verifies that:
a) the hash on the plaintext matches the signed one (everyone ca do this)
b) the hash on the cyphertext matches the signed one (everyone ca do
this, too)
c) the hash of the plaintext encrypted under the given key matches b)

A timestamping service could easily generate such a key from a "really
secret key" (never disclosed) and the timestamp, maybe using a truncated
hash (to prevent a possible hash inversion attack to determine the
"really secret key") and remain able to disclose it to the judge without
compromising other signatures' security.

An attacker should be able to find another (meaningful!) messages that
hashes to the same value and whose cyphertext under an unknown key would
result in the other hash value.
H(p')==H(p)
H(Ek(p'))==H(Ek(p)) (for every k, since he does not know k)

> Merkle trees protect against this though, as not only do you have to
> forge the signature, but also recreate the entire subsequent merkle
> tree, which should be infeasible.
IIUC, merkle trees remain secure only if they continue to "evolve". If
an attacker does have enough (more than 50%) computing power, he can
control the tree's growth. And possibly rewrite the history (IIRC
something similar happened not long ago, when a single group of miners
had had for some hours the needed "quorum").

> If you embed the OCSP response in the tree with the signed data, then
> it enjoys the same protection. 
I have to think about this a bit more... I'm not completely sure.

To be at least partially in topic, it should be possible to do the
signing (and the encryption) even with the current GnuPG version...

BYtE,
 Diego

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

Re: Strange behaviour

[NdK]

Il 11/12/2016 11:56, Matthias Mansfeld ha scritto:

> Currently I have not the time to go much more in depth and can live 
> with the fact that in that moment much other stuff on this computer 
> tends to hang and the "easiest" way for now is to reboot... It is 
> possible that this behaviour came with one of the last MS 
> patchdays...
I think it could even be realated to some HW issue. Are fans clean? Are
capacitors OK? Electrolytic ones, the tall cylinders, often tend to
"explode": they usually have an 'X' on the top and that should be flat
and clean, else the capacitor is surely bad. Did you run a RAM test? And
a CPU test?

I know, it's just a remote possibility, but given the "randomness" it
could be worth checking.

BYtE,
 Diego


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

Re: ? Comments re key servers? re gpg-encrypted mail? re key servers carry many phony keys?

[NdK]

Il 27/12/2016 22:09, Don Warner Saklad ha scritto:
> What do you kind folks out there make of comments at
> https://stallman.org/gpg.html
>  >"I'm told that key servers carry many phony keys claiming to be
>mine. Here is info about which keys are really mine."
> 
>  >"Of course, to be really sure which key is mine, you need to get my
>key fingerprint from me or follow a chain of signatures. If a phony
>key appears to be signed by someone you trust, you should see what's
>up with that person."
> 
> 
> and 4th sentence from the top at
> https://stallman.org
>  >"If you want to send me GPG-encrypted mail, do not trust key servers!
>Some of them have phony keys under my name and email address, made by
>someone else as a trick. See gpg.html for my real key."
Why do you find it strange?
Keyservers are just public write-only repositories that do not attempt
to verify the keys.
You have to verify the keys via the WoT (web of trust: "follow a chain
of signatures"), or by other means ("see gpg.html for my real key"), and
that's what Stallman says. Better do both: check that the chain
identifies the key given in gpg.html (must be retrieved via https).

BYtE,
 Diego


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

Re: ? Comments re key servers? re gpg-encrypted mail? re key servers carry many phony keys?

[NdK]

Il 28/12/2016 13:28, Miroslav Rovis ha scritto:

>> The fact that Github, since this outgoing year, accept gpg signing only
>> if you post your public key to their servers.
I can't say for sure, but maybe that's so so they can have an
"attestation key" to use for verifying signatures, without expensive WoT
checks. By loading your key, you're certifying it's yours. But it won't
actually give any more assurance than "you is you" than your credentials
(against GitHub): if someone steals your credentials, he can replace
your pub key and sign new commits in your name. They're using GPG just
as a frontend for signatures using self-signed certificates.

BTW nothing prevents you from uploading your key to the keyservers and
participate in the WoT -- that's the only thing that could assure who
clones your repo that *you* signed those commits.
Sometimes just "key persistence" is important (i.o.w. that the key that
signed all the commits has always been the same, and in this case GitHub
loaded key can be enough), other times it could be important to link the
key used for signing a commit to (the reputation of) a real person, and
in this case the WoT is needed.

> Just some quick links in connection, for the less familiar.
> For users (like me):
> https://help.github.com/categories/gpg/
Some reccomendations could be quite questionable (always use RSA 4096,
do not set an expiry on main key, no mention of generating a revocation
certificate...).

BYtE,
 Diego

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

Re: Announcing paperbackup.py to backup keys as QR codes on paper

[NdK]

Il 23/02/2017 11:00, Gerd v. Egidy ha scritto:

> If we are talking centuries, I'd worry about the availability of gnupg as 
> much 
> as qrcodes. Both are publicly available standards, but I don't know if they 
> are still available and understandable by then. I'd recommend going to 
> plaintext on glass etched microfiche if you really want to cover that 
> timespan.
Well, when considering such a timespan there could be other (bigger)
issues... How long a today 'secure' key will remain secure? When will
quantum computers be widely available?
The only "guaranteed" crypto is information-theoretic one (neural
networks mutual learning, distant noisy sources, etc), where adversary's
probability of success is a function of the system parameters. But it's
quite impractical and AFAIK covers only interactive key agreement.

PS: in 100 years surely I won't (be here to) care if someone will be
able to read my mails or not :)

BYtE,
 Diego

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

Re: How U2F works

[NdK]

Il 06/03/2017 16:10, Werner Koch ha scritto:

> An old argument against user certificates was the need to purchase a
> device or a certificates.  Now U2F requires that you purchase a device
> anyway, thus this would void that argument.
IIRC one of the selling points of U2F is that it should have been
"anonymous": an attacker that compromises multiple servers shouldn't be
able to determine if two users (on the two servers) are actually the
same person (or even if two users of the same site share a single token).

The only link would be the attestation certificate, but that should only
be checked during enrollment and not stored anywhere (once the user is
enrolled, the attestation cert is useless since only the site-specific
pubkey is needed).

With X509 (or GPG) certs the user's identity gets linked, for the joy of
nosy orgs.

@NIIBE : the sites don't send "proprietary JS" to the browser to access
the token (needed code is public) but the browser must support U2F API.
That's native in Chrome, but Firefox requires a plugin (and I don't know
what's the status of other browsers).

PS: it's not clear what happens when the attestation cert expires: does
the token become useless for enrollment?

PPS: the "attestation CA" could even be the GPG 'C' or 'S' key, that the
server could check via WoT. That does not require 'C' or 'S' key to be
on the token: the attestation certificate can be generated on an offline
machine.

BYtE,
 Diego.

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

Re: Why trust gpg4win?

[NdK]

Il 10/09/2013 00:29, Pete Stephenson ha scritto:

>> 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 strongly disagree here.
First error: USB is *not* a peer protocol. It's master-slave. FireWire
is a peer protocol.

> 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.
[...]
> Is such a thing even possible?
Possible yes. Useful no.
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.

BYtE,
 Diego.

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

Re: Why trust gpg4win?

[NdK]

Il 10/09/2013 14:19, Werner Koch ha scritto:

>> First error: USB is *not* a peer protocol. It's master-slave. FireWire
>> is a peer protocol.
> However, that is implemented by computers at boths ends and the software
> there may have backdoors or explotable code which coult be used for all
> kind of tricks.  Look only at the trend to use HID as simple driver-less
> way to connect about anything to a computer.  Emulated keyboard which
> sends ANSI control codes to take over your box without you noticing?
Uh? "Whithout you noticing"? For sure you know more than me, but to my
knowledge an USB keyboard only sends key scan-codes (not ANSI sequences,
that's why you need to set the keyboard language). And if you have an
open app chances are that you will see keystrokes there.
Sure, it could send a 'win' keypress+release event, but that wouldn't
work (or at least it wouldn't be "unnoticed") in every other SO.

Probably it's "easier" (or at least more effective and less
user-noticeable) to target the USB stack using non-conformant packets
(where buffer overflows might eist). That would give much more time to
try different vulnerabilities before getting caught.

PS: one of the ideas that could "easily" be implemented on FST-01 is a
TOTP password generator that auto-types the code when you press its button.

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

BYtE,
 Diego.

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

Re: Why trust gpg4win?

[NdK]

Il 11/09/2013 11:48, Pete Stephenson ha scritto:

> 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.
Actually such a module exists, and is used to add flash disk access to
small microcontrollers: it's VDrive2 (VNC1L module) by Vinculum
http://www.ftdichip.com/Documents/DataSheets/Modules/DS_VDRIVE2.pdf

I don't think it adds anything to security, but at least it's doable :)

If you are *so* concerned about key security, it's better to use an HSM.

BYtE,
 Diego.

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

Re: Attacking an offline system

[NdK]

Il 12/09/2013 19:07, Peter Lebbing ha scritto:

> The filesystem is also still there with this USB-via-serial-port thingy. And 
> on
> the CD.
Nope. W/ Vinculum module you send it commands like "open mickey.txt" and
then "read 1024". The filesystem driver is in the module and your
interface only receives expected data.

You really should define your "security perimeter". Start by asking
yourself how much an attacker is willing to spend to access the data
you're handling. Once you have an answer to this question you can choose
how much you are willing to spend to defend your data.
Plain old password protecting a file is usually enough.
FST-01 token could be useful to have your key easily portable and (w/ a
little work) even add a button to confirm signing.
Smartcards are another good alternative if you need some "certification".
An HSM is much less portable but needed if you need both certification
and speed.

And this just to keep your keys safe. Keeping the whole system safe is a
careful compromise between functionality and security. But all depends
on the answer to the first question.

But rubberhose cryptoanalysis is usually *way* more effective :)

BYtE,
 Diego.

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

Re: Why trust gpg4win?

[NdK]

Il 12/09/2013 23:10, Marko Randjelovic ha scritto:

> All the time I read suggestions on using USB sticks and I must say
> people are crazy about USB sticks. It is more convenient to use optical
> media then USB stick because they are read only. Boot from Live CD, not
> from USB stick and use USB stick only for data. In a desktop PC you can
> put two CD devices and boot Live CD from CD1 and write your data to
> CD2. You can use write-once media or rewritable media so you do not
> waste to much plastic.
It's just a matter of trust (and speed). After all, you need to take the
system image from "somewhere". That's probably the weakest link. Or, at
least, it's the easiest to compromise.

PS: I'll tell you a secret: there are USB keys with a "write protect"
switch :)

> If you write your data to CDROM, then it is much more safer to transfer
> data to another PC. It is much more complicated to make a virus that
> will insert itself into a CDROM then into a USB stick. Furthermore,
> such action would be odd and could be blocked by a security software
> like SELinux.
And maybe there's a buffer overflow in the ISO9660 driver that can be
exploited . Hey, we're talking of the most tested codepaths (unless
you use some exotic filesystem)!

Maybe technical solutions for a social problem aren't always the right
answer?
You can *never* be 100% sure. No way. You can be "reasonably sure". You
can be "certifiably sure" (given that you define which kind of attacks
you think you'll be exposed to and find a standard to certify against).

I can be "reasonably sure" nobody will hack my machine just to read my
mail. Obama can be "reasonably sure" that *many* attackers will try. So
my scenario and Obama's one are "a bit" different, and require *greatly*
different solutions. I can't afford the costs and inconveniences of a
solution based on Obama's needs (and I'd be indeed quite stupid to try
to adopt it), and he can't afford the risk of a solution tailored on mine.

PPS: at least here in Italy a *completely offline machine* becomes
illegal after 6 months. Law dictates that every computer where personal
data is handled (and even a name and surname *is* "personal data")
*must* be updated *at least* every 6 months. And attacking your update
medium is probably easier than attacking the USB key.

BYtE,
 Diego.

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

Re: Why trust gpg4win?

[NdK]

Il 13/09/2013 11:33, Jan ha scritto:

> My "security perimeter" should be "equal" to the maximum of the
> "security perimeters" of my usual communication partners. That is so
> because with their private key they protect my mail and with my private
> key I protect their mail. What is "usual" is not always easy to
> determine. Lets say I'm looking for the maximum of security an average
> user can achieve with common hardware. This user is willing to do some
> inconvenient things like reboot, burn CDs or wait.
Then you can't defend it. :) You can't even completely audit it, since
it involves a lot of "things" that aren't under your control.
What happens if one of your correspondents is willing to undergo the
whole procedure and he's an FBI agent? :)
You can be paranoid as much as you want, but you will never be paranoid
enough. If FBI (or, more realistically, your wife) wants access to your
data, there's nearly nothing you can do to avoid it...

> Generally I distrust certain hardware like smartcards or HSMs because
> they are main targets for secret services, who have a lot of money.
You could use a Chinese smart card: quite sure it's not been tampered by
FBI :)

> Recently I red about this intersting (English/German) article on FBI
> backdoors in openBSB and scmartcards:
> http://www.h-online.com/open/news/item/FBI-back-door-in-IPSec-implementation-of-OpenBSD-1153297.html
> http://www.heise.de/newsticker/meldung/FBI-Backdoor-in-IPSec-Implementierung-von-OpenBSD-1153180.html
Well, that's one reason I don't like "random blobs" in crypto (like OAEP
requires): it could be quite easy yo use such a blob as steganographic
covert channel.

But for OpenBSD I'd be more incline to thinking that FBI stopped funding
since they couldn't have their backdoors installed.

> It should be possible to create a rather secure system using "norml
> technoligies" (CDs, offline PCs etc.) which are harder to target by
> secret services.
Never heard of TEMPEST?
You boot from an accurately audited CD, decrypt your top-secret email
and as soon as you display it on the monitor it gets aired to that van
in front of your house :)

> If you manage to have a rather secure file transfer
> between an online and an offline PC, the only security relevant
> technology you need to focus on is gnuPG itself.
No. Side-channels are everywhere. You can't ignore 'em. If you want to
certify that your security perimeter is secure, you first have to
accurately define where it is and the threat model. And even then you
can only certify it's secure against the attacks you could think of.

> Some people read the
> source code to check its integrity but are there people who focus on its
> output? To me this is a very important point. I'm not sure how this
> could be done in practice, but I was thinking about someone who knows
> the theory of RSA etc. and who "manually" encrypted a text and would
> compare that with the output of gnuPG to see whether the two results
> match.
Take OAEP signature as an example. *IF* the random bytes are really
random the signature is secure. But since they should be  random, you
can't say if they are truly random or just the output of a cypher that,
given the right password, is transferring your secret key
chunk-by-chunk. And against that, even manually encoding is useless: the
RSA encryption is done correctly, the key is the right one, the protocol
is followed, but soon someone else will have your key and will be able
to decrypt all your messages.
IVs are another potential channel, but they're needed to make many
encryption schemes secure.

> Some other approach might be to compare the output of several
> versions of gnuPG, PGP etc.. This way you could check whether the
> information was secretly decrypted with a second "FBI key". This is even
> possible for someone how is no programer. Do you think checking the
> output in that way is useful?
No. You can only check if the protocol is followed accurately.
How can you check there isn't a weakness in RNG, for example? In other
terms, how can you tell apart a TRNG from a good cypher?

BYtE,
 Diego.

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

Re: Why trust gpg4win?

[NdK]

Il 13/09/2013 21:12, Jan ha scritto:

>> How can you check there isn't a weakness in RNG, for exampel [...]
> There are statistical test with which you can test whether a random
> number generator produces for instance uniformly distributed numbers.
> This in connection with the above procedure might make a good output
> oriented check of gnuPG.
A good encryption algorithm should generate an output that you can't
tell is not purely random. That's why you have to compress the data
BEFORE encrypting it.
Then the output is usually "decorated" with data structures to make it
recognizeable and not attempt decrypting it the wrong way.

BYtE,
 Diego.

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

Re: How to find and verify a trust path?

[NdK]

Il 17/09/2013 22:01, Philip Jägenstedt ha scritto:

> That's fine, I'm just trying to figure out what others do to convince
> themselves that (e.g.) the GnuPG dist sig key is trustworthy-ish and
> if there are any tools to help with the boring bits.
I think "stability" is what most newbies (and probably experienced users
too) use.

If the same "identity" keeps using the same key while relating with
different users, it's "trustworthy". So if I have CDs from some years
ago and OpenPGP is signed with the same key used today, I can be "sure
enough" it's not been tampered with and the new file is trustworthy.

And often it's more important stability over "impossible" verifications
of "real life identity".

BYtE,
 Diego.

___
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

[NdK]

Il 21/09/2013 23:06, Aleksandar Lazic ha scritto:

> What solution is available for public Web mail providers like gmail,
> gmx, hotmail,  .?
Firefox+GreaseMonkey+script to interface to card?

BYtE,
 Diego

___
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

[NdK]

Il 22/09/2013 20:43, Aleksandar Lazic ha scritto:

>> Firefox+GreaseMonkey+script to interface to card?
> Your solution implies that you need to install all this components on
> all devices.
Sure. Unless you want to trust someone else to handle your keys. But
then don't be surprised if who have something sensitive to tell, *not*
to tell it to you...

> I'm not sure that this is always possible.
Then that user won't be able to use encryption. At least not on that device.

> Do you see any other solution for the users to use safely the private key?
"I want to surf the web but I can't install a browser. How can I do it?"

BYtE,
 Diego.


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

Re: standardized security levels

[NdK]

Il 11/10/2013 07:24, Hauke Laging ha scritto:

> My OpenPGP specific aim is that such a standardized list would be implemented 
> in OpenPGP applications, probably as a signature notation. The typical user 
> would have several keys (for the same address) at different security levels. 
> Thus the sender could select the security need of the data to be sent and the 
> system could automatically select the most suitable key (or fail if none such 
> is available).
What I still couldn't understand is how I can sign a key saying "I'm
really sure of the owner's identity, but I don't really trust him
properly handling other signatures" (the typical example is "parents" :)
, but the same applies to a signing party... ).
IIUC your proposal doesn't address that aspect.

BYtE,
 Diego.

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

[NdK]

Il 15/10/2013 11:41, Pete Stephenson ha scritto:
> 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
I'm 'more or less' (no time ATM :( ) working on extending standard GPG
card protocol to support user-controlled export of keys and ability to
keep 'n' old enc keys on the same card.

> Is this a hardware limitation, or could it be increased in the future?
Try to find a Java card that supports longer keys...

> Also, are there any smartcards out there that would support DSA/ELG
> keys? All the cards I've seen and used support RSA only.
I've only seen RSA (up to 2048bit) and ECC (some "small" fields only)
support in Java cards. Some BasicCards should support up to 4096bit (and
they're the ones used by offical GPG card, IIUC).

BYtE,
 Diego.

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

Re: Does anyone use an NXP JCOP J3A smart card?

[NdK]

Il 14/11/2013 17:42, Ruslan Sagitov ha scritto:

> I’m looking for a combo of a SCM SCR3500 card reader and a NXP JCOP J3A
> smart card. I want to know whether this combo works with GnuPG or not.
You have to load an OpenPGP-compatible applet to the card.
It's not too hard, since that card supports JC222 and GP211.
One such app is MyPGPID (available on GitHub) that (till I find some
time to develop it further) is mostly a basic OpenPGPCard applet.
Make sure the seller gives you the keys needed for loading the applet!

BYtE,
 Diego.

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

Re: Smart card reader security

[NdK]

Il 27/11/2013 08:36, Werner Koch ha scritto:

>>> smart cards readers are fun to play with.  IIRC, there have been
>>> demonstrations turning the doctors health card terminals and PIN+chip
>>> terminals into space invaders consoles.
>> Do you have a source for that? I'd love to see some video or so :)
> Sorry, I have not the time to dig into this.  A good starting point will
> be http://www.cl.cam.ac.uk/research/security/banking/.
Found:

http://www.lightbluetouchpaper.org/2006/12/24/chip-pin-terminal-playing-tetris/

BYtE,
 Diego.

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

Re: Any future for the Crypto Stick?

[NdK]

Il 01/12/2013 20:09, Tristan Santore ha scritto:

> You might want to check out the Yubikey guys. They make a yubikey with
> an openpgp applet.
> https://www.yubico.com/2012/12/yubikey-neo-openpgp/
Yubikeys would be interesting, if only it would be possible to develop
personal applets to load on 'em. Too bad some needed libraries (like the
one to access the button for OOB consent) are only available under NDA
from NXP (quite uncollaborative with hobbyists).
Moreover, their applet doesn't allow key import, only on-card generation!

> Some people should peer review this stuff though. At least the code is FOSS.
Quite useless to review something you won't be able to compile and load
yourself, don't you think?

> I would still prefer a openpgp card though mainly because I trust a
> German company more, than a business that also might be harassed by the
> US Government.
Another alternative is getting a SIM-cut Java card and a reader for it,
then load one of the OpenPGP Java applets you can find around.
You'll then be able to load code you compiled (and audited) yourself and
can import your 'old' keys if you like.

> All depends on the legal situation and the willingness of companies to
> abuse their position, because they are being lobbied by governments.
Who can you really trust? If you don't trust NXP, then you can't use any
of their JCOP chips... What would stop 'em from adding an undocumented
command to the card manager that dumps the whole memory?

PS: too bad all the Java cards I could get are limited to 2048 bit
keys... Only BasicCard supports longer keys, but I'm not using Basic
since Commodore-64 era :)

BYtE,
 Diego.

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

Re: Any future for the Crypto Stick?

[NdK]

Il 03/12/2013 15:30, Mark H. Wood ha scritto:

> I wonder how feasible that really is.  The system surrounding the card
> is not under control of the card's manufacturer or anyone who might
> have corrupted him.  All it takes is one knowledgable person watching
> the data stream for interesting anomalies, and you have given the game
> away.  The cost, as we've recently seen, could be considerable.
Unless the exploit could be categorised as "bug". Like the power glitch
that allows clearing fuses in some PICs (advertised as secure chips, at
the time... now they're saying it's secure unless operated outside
nominal values) w/o wiping the rest of the memory.

This way you'd have to use a non-standard reader to introduce a specific
error. Or, maybe, a protection layer that fails if frozen before
exposing it to oxygen, allowing the attacker to succesfully decap the
chip before it self-erases.

There are simply too many attack vectors to say the evaluation considers
'em all. It needs to stop somewhere saying "this chip is secure against
these attacks" since it can't say "it's secure against any attack you
could think of". And/or it places a budget limit on the attack: if it
costs more than that, the attack is worthless.

I've seen this tradeoff while studying openalarm, a (wannabe, still in
its early stages) burglar alarm system scalable from garage to bank: as
long as you can trust a producer and an installer, it's quite easy and
anything will do (if you need to protect your personal mail from your
nosy boss, FST-01 is more than enough). If you can't, you need
exponentially more resources to be able to pinpoint the black hat, be it
the producer of a node, of one of the management systems or the
installer trying to slip a backdoor in.

If you don't/can't trust a single smartcard manufacturer, you'd need to
use at least four (if you need to be able to say who is the misbehaving
one -- byzantine generals problem in case of 3 with one misbehaving agent).

So, for the vast majority of uses, the solution might be non-technical:
use a certified Common Criteria card and make sure to have evidence that
if the key is leaked then that certification is bogus. Quite unlikely
the NSA will reveal having a backdoor just to arrest *you* :)

BYtE,
 Diego.

___
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?)

[NdK]

Il 08/12/2013 14:15, Mark Schneider ha scritto:

> A little security is not real security. There always can be backdoors in
> the firmware (BIOS, closed source drivers etc).
Why is everyone thinking 'BIOS' as backdoorable piece of sw? Why not the
hard disk?
http://spritesmods.com/?art=hddhack

Just another piece to think of when building a secure system...

BYtE,
 Diego.

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

Android and E2E security

[NdK]

Hi all.

Seems someone is actively working on securing phones in an
user-effortless way...

http://www.techthefuture.com/technology/cyanogenmod-brings-system-wide-secure-messaging-to-android-phones

I've only had a quick look at it and something yet doesn't "sound
right", but might be just an impression...

BYtE,
 Diego.

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

Re: Revocation certificate for sub key?

[NdK]

Il 13/12/2013 23:56, adrelanos ha scritto:

> Is it possible to create a revocation certificate just for sub keys and
> not the master key?
I can't see how it can be useful...

> This would be useful for offline master keys. Trusted persons could be
> given the revocation certificate for sub keys and send it to key servers
> when they suspect compromise. But should the sub key revocation
> certificate get into the wrong hands due to compromise, the damage would
> be limited.
Since you still have your secure offline main key, you can revoke
subkeys yourself... Or am I missing something?

BYtE,
 Diego.

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

Re: Possible to combine smartcard PIN with key password?

[NdK]

Il 22/12/2013 04:13, adrelanos ha scritto:

> Or in other words, is it possible to store an already encrypted
> (password protected) gpg private keys on a smartcard? So the smartcard
> never gets to see the plain key?
That would be really useless: smartcardneeds the key to *do* crypto ops!
It's not a limited USB stick!
Since the smartcard is a really controlled execution environment, "we"
can say it's a "trusted environment".

> I've learned the hard way (by buying the equipment even with external
> PIN pad), that when "keytocard" has been used, that only the PIN has to
> be entered. No password. Unfortunately.
Luckily. Smartcards are used to avoid exposing key material to an
untrusted environment, like a PC.

> The smartcard has been bought by me to improve security. Not to
> substitute one security mechanism with another. I believe gpg's software
> encryption is more trustworthy than a card I got by snail mail. I
> haven't heard that any cards have been compromised yet, but how do I
> know if I really received an original (untampered) card in the first place.
You have to trust the supplier. If you ordered 'em in significant
quantities, you could ask to have 'em with special keys so that every
step can be checked.
Or. more easily, you can buy blank java cards from diffetent
manufacturers, then compile an upload your carefully checked applet.

> In my opinion both attempts, password protection and smartcards, on
> security are worthwhile. When using smartcards I am trusting hardware, a
> small group of card designers, producers, post office... And when using
> gpg's software key encryption, I am trusting the software producers and
> the programmers actually looking at the code.
You can do many checks yourself: there are various OpenPGP Java
implementations around.

> The idea was to take my chances. If smartcards work, that's great. The
> key can be abused when a malware infection happened, but at least the
> key can not be extracted. On the other hand, if I loose my smartcard and
> smartcards don't do what they promise (i.e. someone ever comes up with
> some exploit to extract the key), I fall back to gpg's software key
> encryption.
And how do you think the card could perform crypto ops on encrypted
keys? If you lose your card, it could be way easier to revoke the keys
on card. And that's why many people keep their master key offline, using
cards/tokens just to safely transport their keys.

> I am ignorant about the technical details. Maybe there is a technical
> reason why it's not worthwhile to combine these things? Or are
> smartcards just too limited at this stage of development to support that?
No. It's simply impossible to do what you're asking. Unless you replace
the secret key with a *masked* version, leaving the unmasking key on the
PC, encrypted by PGP. But that would prevent checking on-card various
possible attacks, actually weakening the whole system.

BYtE,
 Diego.

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

Re: Possible to combine smartcard PIN with key password?

[NdK]

Il 23/12/2013 19:29, adrelanos ha scritto:

> This would be lucky, if one could enter the PIN using an external keypad
> (possible) AND a password using the keyboard (not possible).
I'd like it was possible, but for other reasons: that would mean you
could instantiate an object in card's RAM, havina actually a
limitless-memory card: you'd simply have to send the encrypted key blob,
the password and the PIN. Too bad in all cards I know key objects can
only be stored in EEPROM/Flash, that have a quite limited number of
writes :(
But, as Peter pointed, that wouldn't bring you more security.

> Checking the applet is difficult. Only few people are skilled to do.
Try reading code of an applet. You can learn the basis of SC devel in an
afternoon, and that would be enough to understand how a well-written app
works. Then throw away what you learnt and ask if some expert already
looked at that code :)

> I am a user of gnupg. I can't be auditor-like type of person for all
> projects I am using.
If you want to be paranoid enough, you need to. That, or pay a lot of
money -- and who guarantees you that the staff is not paid by a TLA
agency? ]:)

> And let's say the applet is fine as is. It will be
> much more difficult to find out if the smartcard really wipes the key as
> soon someone is trying to dismantle the card to directly read its
> memory. It is my understanding, that understanding such hardware design
> is even harder than understanding the applet. And knowing/searching for
> vulnerabilities in the hardware design is an art in itself.
Sure. Look at works by Ross Anderson, just for naming one expert in that
field. Maybe you want to hire him.

>> You can do many checks yourself: there are various OpenPGP Java
>> implementations around.
> Also the hardware design?
How much do you want to pay for that level of security?
Maybe, you should start reading the applicable certification procedures
(what does CC-EAL5 mean exactly?), to see what's already considered and
which level of examination each card mask have undergone. Then, if
that's not enough, you should contact a manufacturer and take steps to
have a custom-made mask examined by your enginering staff, then buy
enough cards. Or, simpler, ask the supplier to sign a contract where the
considered attacks are detailed.

> One could do it manually already. First encrypt a message using the
> smartcard and the encrypt the encrypted message again using a
> password-protected/encrypted key. And you could tell contacts, "my
> signature is only valid if it is signed by both signing keys".
Naive and error-prone.

> Manually doing so just seems to inconvenient to get it right. Technical
> challenges should only be implementing that feature but not conceptual
> limitations?
Then you should use the (really heavy) shared RSA signature: to have a
valid signature, all N chunks from N parties are needed. Key generation
is a collaborative effort, too, so no single party can know the whole
secret key. That could be a good idea for a Ph. D thesis (probably a
hard one). I fear that current crypto support in JavaCards wouldn't be
entirely useable :(

BYtE,
 Diego.


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

Re: Possible to combine smartcard PIN with key password?

[NdK]

Il 24/12/2013 02:41, adrelanos ha scritto:

> Adversary capabilities:
> - Can physically steal the smartcard.
> - Capable of dismantling a smartcard to extract the key its holing.
> [Maybe not now, but maybe in a few years the tool required to so so will
> be available. Only making up the scenario here.]
> - Not capable of breaking gpg's key encryption/password protection.
> - Not capable of rubber-hose cryptanalysis.
> - Not capable of installing a miniature camera and/or hardware keylogger.
You're saying that he can lockpick your security door but can't break
the glass of the window nearby...

Just IMVHO...

BYtE,
 Diego.

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

Re: Printing PGP Businesscard

[NdK]

Il 24/12/2013 10:18, Ralph J.Mayer ha scritto:

> is there an easy way to print your PGP-key on a piece of paper in a
> nice way?
Maybe using QR code? At least for the fingerprint, or a reference URL.

BYtE,
 Diego.


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

Re: Possible to combine smartcard PIN with key password?

[NdK]

Il 27/12/2013 01:42, adrelanos ha scritto:

[...]
>> You're saying that he can lockpick your security door but can't break
>> the glass of the window nearby...
> I don't understand how you get to that conclusion.
You're assuming that breaking into a smartcard is something easy, while
it's the most expensive of the cited actions (except breaking encrypted
keys on file). It requires great skills and devices that aren't exactly
cheap (see Anderson's page at http://www.cl.cam.ac.uk/~rja14/ and read
some of his papers about reliability of security systems). Hire someone
that plants a keylogger in your PC is probably cheaper than 2K$ (maybe
it's even free, if he can rob something while at it). You could even
find someone who does rubberhose "analysis" for fun... How much effort
is it, compared to breaking into a smartcard, that requires a
specialized lab?

BYtE,
 Diego.

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

Re: deleting secret key not implemented

[NdK]

Il 31/12/2013 14:49, Kristian Fiskerstrand ha scritto:

>> But how do I go about deleting it if I can't do it through gpg2?
>> Can I do it manually somehow?
> Get the keygrip as gpg2.1 --with-keygrip -K uid and delete the
> corresponding file(s) in $GPGHOME/private-keys-v1.d. The form should
> be .key.
Maybe I'm missing something... What happens if keys are kept on smartcard?

BYtE,
 Diego.

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

Re: ePGP extension for mobile

[NdK]

Il 31/12/2013 17:11, ved...@nym.hush.com ha scritto:

> As phones are increasing in memory and processing power,
> maybe an app could be developed to use a smart card usb reader on a phone.
Since many phones already have NFC, why not use an RFID-capable Javacard
w/ openpgp applet? No extra reader to carry: just keep the card near the
rear of the phone while doing crypto ops.

BYtE,
 Diego.

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

Re: sign encrypted emails

[NdK]

Il 03/01/2014 11:28, Hauke Laging ha scritto:

> But I do not suggest to make my configuration the default. I just want 
> to be able to use it. Sometimes it's best to send a signed cleartext 
> message, sometimes to send an unsingned encrypted message, sometimes a 
> first signed then encrypted message and I want to stress that sometimes 
> it's best to send a first encrypted then signed (or signed-encrypted-
> signed) message.
I can't come up with a situation where sign, encrypt, sign again w/
*same* key used in the first signature gives more security than first
encrypt then sign. So two layers are enough.

I (partially) get your point: receiving an encrypted message could
mislead an uneducated user... But I doubt someone w/ access to top
secret material falls in that category :)

BYtE,
 Diego.

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

Re: USB key form-factor smart-card readers with pinpads?

[NdK]

Il 06/01/2014 10:34, Werner Koch ha scritto:

> To make use of the decryption key the smartcard first requires that a
> VERIFY command is send to the card.  This is what asks for the PIN.
> After a successful verification of the PIN the card allows the use of
> the PSO Decrypt command until a power down or a reset operation.  Thus
> an attacking malware only needs to trick you info decrypt an arbitrary
> message and is then free to use the smartcard without having the reader
> ask you again for a PIN.
Is it just convenience or enforcing it (e.g. adding a "forcedecauth"
flag) would lead to usability issues (maybe because sometimes decryption
is called many times in sequence)? That would be the case for auth key,
I think: using it to auth against a web page would ask auth for every
sub-request of objects on the page.

BYtE,
 Diego.

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

Re: using an OpenPGP card with Java (keytool and jarsigner)

[NdK]

Il 07/01/2014 04:01, Hans-Christoph Steiner ha scritto:

> Does anyone know if there is any chance of using an OpenPGP smart card for
> Java?  I know that GnuPG doesn't support PKCS#11, but I was wondering if
> things work the otherway around: java using the OpenPGP card.  It would be
> super useful to be able to use the same smartcard for both Android APK signing
> and OpenPGP signing.
IIRC there is an OpenSC "driver" for OpenPGP cards, that makes 'em
accessible throught PKCS#11.

https://www.mail-archive.com/opensc-devel@lists.opensc-project.org/msg06206.html

Seems it's quite old... Maybe if you want to take over developement...

BYtE,
 Diego.

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

Re: Setting up shared access to gpg on a UNIX server

[NdK]

Il 30/01/2014 02:14, DUELL, BOB ha scritto:

> I will appreciate any and all comments.  If there is a "better way" to do 
> this, I'd love to learn.
Every user in the group could "leak" the secret key. At least put it
into a smartcard/token connected to the server: they'll just be able to
*use* it.

BYtE,
 Diego.

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

Re: MUA "automatically signs keys"?

[NdK]

Il 31/01/2014 10:24, Steve Jones ha scritto:

> Well the conventions of use, for example the key signing party
> protocol, requires photographic id. If I publicly sign a key it has to
> be in line with how I expect others to interpret it. Policies and
> notations on signatures go some way to alleviate that but only if the
> tools support it.
I tried looking around for some tutorials about notations, but could
only find minimal information ("it's a string in 'tag@domain=value'
format").

IIUC in *my* policy I could specify that when signing a key I use
"ndk@mydomain=X" notation and that X=0 means "just checked the person
can access the given mailbox", X=1 means "at least 2 other persons have
confirmed that the same user used that email address for the last year"
and so on.

Is my understanding right? When I sign a key and use a notation, am I
actually signing *all* the identities associated with that key? Or just one?

BYtE,
 Diego.

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

Re: Setting up shared access to gpg on a UNIX server

[NdK]

Il 31/01/2014 01:29, DUELL, BOB ha scritto:

> A couple folks (Diego and Johannes) mentioned using a smartcard or a
> token.  I think a smartcard refers to a piece of hardware, but I
> don't know what a "token" means.  Our server is in a datacenter and
> I'm sure I cannot attach any sort of hardware.
A token is a bundle of a smartcard and a reader, and usually looks like
an USB stick.
If you have a dedicated (non virtual) server, usually you can ask to
have a token plugged in. If you're using a virtual server, then it's
harder and there are other possible attacks against your key material,
as previously discussed on-list.

> I might be able to use a software only solution; I've heard something
> about "agents", but don't really understand any details.  Can such an
> agent be used, one that I can start and load the key with passphrase
> at system startup?
I don't know if such an agent exists.

BYtE,
 Diego.

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

Re: Subject: openpgp card and basiccard RNG

[NdK]

Il 13/02/2014 21:29, Peter Lebbing ha scritto:

> Although I think there's a trend towards more openness, and I learned a while
> ago that you can get crypto-capable JavaCards these days without requiring an 
> NDA.
I've been able to work on JavaCards w/o having to sign anything (except
the transactions to various online stores :) ).

I'd have been interested in developing for Yubikey, too, but that
required an NDA with NXP for their SDK, or I couldn't access the button
(and access to the button was the only reason I was interested in
Yubikey in the first place!).

BYtE,
 Diego.


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

Re: Subject: openpgp card and basiccard RNG

[NdK]

Il 13/02/2014 23:20, Werner Koch ha scritto:

[JavaCards]
> I am not interested in those small applications on the smartcard as long
> as I can't scrutinize the real code, i.e. the OS.  Whether those
> applications are written for a p-code system (JavaCard, BasicCard) or
> for the native CPU doesn't change anything in the equation.
Then where would you stop analyzing?
If you look at the OS code, there could be a backdoor in the CPU
microcode. Or in the chip firmware uploader (is there an HV programming
mode available? was it disabled or physically removed from the die?).

And these are just the most obvious. The best we can do is trust the
manufacturer and read the fine print on the datasheets. It will be more
secure than a sw only implementation that runs on a connected PC.

ByTE,
 Diego

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

Re: Signature without policy meaningless? (was Re: UI terminology for calculated validities)

[NdK]

Il 02/05/2014 17:12, Peter Lebbing ha scritto:

> I don't quite understand. If I know someone, I can talk with them about how 
> they
> verify ownership before they sign. Then I can judge whether I agree and assign
> ownertrust accordingly.
Too bad (IIUC) you can't say "I certify that this person is *really* the
one given in this UID, but I absolutely don't trust his identity
validations"...

BYtE,
 Diego.

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

Re: Signature without policy meaningless? (was Re: UI terminology for calculated validities)

[NdK]

Il 03/05/2014 01:10, Daniel Kahn Gillmor ha scritto:

> Having such an assertion cryptographically bound to the OpenPGP
> certificate in parseable form implies in some sense that you think a
> mechanical process (e.g. WoT calculated validity) should be able to make
> use of it.  But how would that work?
Making WoT calculator avoid looking for keys signed by that user if
reached throught my certification.

>  It sounds like you'd want to ask
> an OpenPGP to introduce an additional concept on top of the notions of
> validity and ownertrust (which are already confusing):
They work: I'm *really* confused. :)

> some sort of meta-ownertrust: instead of ownertrust's question of:
> "how much am i willing to rely on NdK's identity assertions",
Well, if ownertrust answers that, it's what I need: a way to say "I am
sure this key belongs to X, but I don't want it to be used to introduce
more keys in the WoT".

> meta-onwertrust would ask
> "how much am i willing to believe NdK's assessments of certification
> practice quality?"  Who is going to understand this question?  What kind
> of UI would you suggest for it?
No, it's not what I meant.

BYtE,
 Diego.

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

Re: Signature without policy meaningless? (was Re: UI terminology for calculated validities)

[NdK]

Il 03/05/2014 10:50, Nicholas Cole ha scritto:

>> Well, if ownertrust answers that, it's what I need: a way to say "I am
>> sure this key belongs to X, but I don't want it to be used to introduce
>> more keys in the WoT".
> But it doesn't work like that anyway.  Unless you are using Trust
> signatures (and few people do) then a signature on a key does not
> encourage a 3rd party to trust signatures made by that key.
Ah, OK. Now it makes more sense.

Tks for the clarification.

> Even if a key is recognised as authenticated/validated/certified for
> association with a particular email address, the signatures made by
> that key will not be trusted by anyone who has not made an active
> decision to make a particular key a trusted introducer.
IIUC, *unless* I tsig it.
But if I use tsig I'm doing both an "identity" signature and a trust
signature. I see no way I can publicly say "I don't really know
real-world identity of this subject, but I trust him as an introducer"
(yep, might sound strange [*], but often a pseudonym is more meaningful
than RL name, but pseudonyms aren't "good" in WoT): if I tsig his key,
I'm cerifying his pseudonym -- that I shouldn't do since it's not on any
document.

[*] well, not too strange in many cases, when it's "healtier" that a
pseudonym is *not* easily correlated to a RL identity.

> In fact, this is a reason (though one of many) why the web of trust
> has never quite lived up to its promise.  No UI that I am aware of
> sets even marginal trust by default on newly imported keys.  Most
> users (I suspect) will only ever end up trusting keys that they
> themselves have signed.  That is the default position.
Understandable/safer, but harder to bootstrap :)

BYtE,
 Diego.

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

Re: Managing Subkeys for Professional and Personal UIDs

[NdK]

Il 03/05/2014 05:01, Robert J. Hansen ha scritto:

> And regardless of whether it's a good practice or a bad one, I've worked
> in businesses that have done exactly this -- so it's a real-world
> example that demonstrates the occasional need for a third party to
> possess signing keys.
That practice is the same as asking you to sign blank sheets of paper so
they can later write on them what they like.
IMVHO it's an *illegal* practice, and actually I vaguely remember news
about a case where a female worker had to sign a blank sheet, that was
later used for her "resignation" when she asked for maternity leave.
IIRC she won the cause.

Signing cards, at least here in Italy, are bound to a person. If
multiple persons can sign the same kind of document (or if a "vice" is
needed), then there are more cards, each controlled by a different
person. That's why it's called "qualified signature" and it's (legally)
stronger than a plain one.

As already pointed out it could be different for encryption-only keys,
that could be escrowed under some circumstances.

BYtE,
 Diego.

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

Re: Managing Subkeys for Professional and Personal UIDs

[NdK]

Il 04/05/2014 14:43, Robert J. Hansen ha scritto:

> Because the law says the document must bear the President's signature,
> not that of a functionary acting on the President's direction.
Just 'cause the law lays *way* behind technology: when it was created,
they couldn't think of "autosign" machines, figure digital signatures!

> Deception?  In politics?  Surely you jest.  That could /never/ happen...
ROFLASTC :)

BYtE,
 Diego.


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

[NdK]

Il 25/05/2014 20:57, tux.tsn...@free.fr ha scritto:

> 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
You could use gnuk (includes 'quite' secure openpgp card), or only its
TRNG NeUg:

http://www.fsij.org/gnuk/neug_version1_0

Readily available on seeedstudio (pre-programmed with gnuk, if you only
want NeUg you need to flash it yourself).

Hope it helps.

BYtE,
 Diego.

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

Re: Why create offline main key without encryption capabilities

[NdK]

Il 01/06/2014 16:17, Hauke Laging ha scritto:

> There are certain risks using the same RSA key for encryption and 
> signing. If you make a blind signature over data someone supplied then 
> you unintentionally decrypt the data (and send it back).
Then you're using RSA the wrong way.
You should *never* apply RSA directly. Padding is important and *must*
be checked during process. Decryption and signature are the same RSA op,
but use a different padding so you can tell which op got applied.

> 2) If a signature key has expired then you may delete the private part. 
> You should usually never throw away a decryption key, though, as it can 
> happen that you have to decrypt data long after the public part has 
> expired.
And that poses a big problem for everyone that would like to use a
smartcard for decryption...

BYtE,
 Diego.


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

Re: Key distribution via NFC

[NdK]

Il 04/07/2014 05:54, Robert J. Hansen ha scritto:

> 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.
Just place in the tag the URL where to retrieve your key.

> 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.
Or, as suggested, use the whole phone as a smart tag, placing it in
"device mode" with a suitable applet that sends your whole key w/o the
limit of 400 bytes.

Too bad it's quite easy to reprogram the tags, IIUC, so the applet
method should be preferred. IMOP, such an applet should be able to use
bluetooth, too, to allow sending the key to non-nfc enabled phones (but
maybe a simple file manager could be enough for this? Maybe some file
managers already allow to send via NFC too)...

BYtE,
 Diego.

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

Re: using different encryption key in evolution

[NdK]

Il 10/07/2014 21:44, Richard Ulrich ha scritto:

> Is there a way in evolution to explicitly state which encryption keys to
> use?
> Judging from the gpg manpage, it could be done on the commandline, but
> that would be difficult to then send as a regular email, I guess.
Try putting the individual addresses in cc. While there's no key for the
main address, it should find others' keys and use 'em so that they all
can read it.

Just guessing, since I don't use evolution.

BYtE,
 Diego.

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

Re: OpenPGP card feature request: as many encryption-capable keys as technically possible

[NdK]

Il 15/08/2014 02:18, Peter Lebbing ha scritto:

> The problem is expiring a encryption-capable subkey on an OpenPGP
> smartcard, replacing it with a new one.
> Currently, the OpenPGP smartcard only allows a single
> en-/decryption-capable key.
That's exactly why I started MyPGPid project. Too bad I've had no time
to develop it further :(
Hope I'll be able to return on it soon... Unless another (paid) project
steps in...

> Suppose after some time I decide an old key has seen it's useful
> lifetime. I'd like to create a new encryption-capable key. However, I
> definitely need to keep the old key, or I won't be able to see anything
> encrypted to me in the past.
Currently you have to generate your encryption key on the PC and copy it
to the card. So you have a copy to reuse.
Or just use multiple cards 

> The current OpenPGP smart card restricts me to a single key for
> encryption, a single key for signatures, and a single key for
> authentication. If it were possible to tell the card, on uploading the
> key, what that key's usage will be, I would be able to have a separate
> smartcard that decrypted the 3 OpenPGP subkeys I used for encryption
> previously. This instead of being forced to use 3 separate smartcards. I
> get the impression this is a relatively small change to the firmware of
> the smartcard, but a larger change to the software running on the PC.
On a 144K javacard, IIRC, I've been able to store 13 RSA-2048 encryption
keys. Plus master, signature and two auth keys (one reserved for
contactless auth).

BYtE,
 Diego

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

Re: OpenPGP card feature request: as many encryption-capable keys as technically possible

[NdK]

Il 15/08/2014 12:31, Peter Lebbing ha scritto:

> So if you had a smartcard with a lot of storage, you could copy the key
> material of your old keys, taken from your secure backup, to the card
> and keep on using a card to work with the keys.
That's what I was doing with MyPGPid: a 144k Javacard can host the
applet and many keys.
The "trick" is that it accepts the standard OpenPGPCard commands, plus
some extended commands to handle extra keys (like selecting current
enc/dec key, or safely export keys only towards user-certified devices).
This way you only need the standard GnuPG plus an helper program (can be
a simple script using opensc) if/when you need the extra functions.

BYtE,
 Diego.

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

Re: auto refresh for expired certificates

[NdK]

Il 25/10/2014 20:09, Hauke Laging ha scritto:

> I would like to suggest a new option for GnuPG (mainly intended for the 
> config file) which would automatically try to import an update for the 
> certificate if it has expired (both from the standard key server and 
> from the preferred one if set).
IIRC a tool exists to do that, in a way that makes it hard for keyserver
owners to extract "social" metadata (like "these keys are on a single
keyring"). Too bad I can't recall its name :(

BYtE,
 Diego


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

Re: Why the software is crap

[NdK]

Il 14/11/2014 12:41, da...@gbenet.com ha scritto:

I usually just lurk, but that's too much...


I even tried exporting my private and public key from the command line and then 
tried
importing. The same error message as before. I have checked on the internet - 
most of the
suggestions are crap - the authors have never ever tried to do what they 
suggest others to
do. If they had done so then they would have known just how crappy their 
supposed expertise was.
I have even looked through https://www.gnupg.org/faq/GnuPG-FAQ.html  and found 
this to be a
useless pile of crap also.
Surely you're doing it wrong, overlooking some passage. So don't blame 
others for something *you* are doing wrong.



I am faced with two options:
(1) Create yet another set of keys
(2) Give up using gnupg after some 20 years
(3) Do it the right way as everyone else and admit you were doing 
something wrong.



I think I will unsubscribe from this list and give up on gnupg as a pile of 
crap.

And that will be better for the whole community.

BYtE,
 Diego.

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

Re: Why the software is crap

[NdK]

Il 14/11/2014 13:24, da...@gbenet.com ha scritto:


I have cooled. You can export your private key - you can export your public 
key. You can
import your private key you can import your public key. In 20 years I have 
always had the
same problem - the same error message and have each time created a new set of 
keys. I have
done this 4 times.
If all four times you did the same wrong thing, then it's obvious that 
you got the same wrong result.


Just to prove it's your error, I copied my .gnupg from one system 
(str957-142) to another (str957-004), with the most basic method I ould 
think of. I'm not an expert (probably I transferred more than what was 
needed!), but as you can see I succeeded at the first try!


diego@str957-142:~$ gpg --list-secret-keys
/home/diego/.gnupg/secring.gpg

sec   2048R/F9B9D307 2014-11-14
uid  Diego 
ssb   2048R/3A4AD1C0 2014-11-14

diego@str957-142:~$ tar cvfz GnuPG-backup.tar.gz --exclude random_seed 
.gnupg

diego@str957-142:~$ gpg --clearsign GnuPG-backup.tar.gz

È necessaria una passphrase per sbloccare la chiave segreta
dell'utente: "Diego "
2048-bit chiave RSA, ID F9B9D307, creata 2014-11-14

diego@str957-142:~$ ls GnuPG-backup.tar.gz*
GnuPG-backup.tar.gz  GnuPG-backup.tar.gz.asc
diego@str957-142:~$ scp GnuPG-backup.tar.gz diego@str957-004:/home/diego

Then on the other PC:

diego@str957-004:~$ tar xvfz GnuPG-backup.tar.gz
.gnupg/
.gnupg/gpg-agent-info
.gnupg/pubring.kbx
.gnupg/gpg.conf
.gnupg/private-keys-v1.d/
.gnupg/reader_0.status
.gnupg/pubring.gpg~
.gnupg/secring.gpg
.gnupg/scdaemon.conf
.gnupg/gpa.conf
.gnupg/trustdb.gpg
.gnupg/pubring.gpg
diego@str957-004:~$ gpg --clearsign GnuPG-backup.tar.gz

È necessaria una passphrase per sbloccare la chiave segreta
dell'utente: "Diego "
2048-bit chiave RSA, ID F9B9D307, creata 2014-11-14

diego@str957-004:~$ gpg --verify GnuPG-backup.tar.gz.asc
gpg: Firma eseguita in data ven 14 nov 2014 14:07:57 CET usando RSA, ID 
chiave F9B9D307

gpg: Firma valida da "Diego "


I notice that no one on this list - for all the talk of "oh I've done it" can 
offer no
practical information has to HOW. No one. No one. No one knows how to do this 
simple task.
In all my 20 years I have never found out how. Perhaps things are different 
under a Windows
O/S but on Linux there is NO SOLUTION.

Done just now in Ubuntu. So there's an error on your side.

BYtE,
 Diego.

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

Re: Why the software is crap

[NdK]

Il 14/11/2014 18:24, da...@gbenet.com ha scritto:

> I have a clean install of 64 bit LXD - all programmes are working 100 per 
> cent. My keys get
> imported perfectly - every programme including Enigmail knows they are there. 
> But when I try
> to sign or sign and encrypt I get the error referred too. No amount of 
> copying no amount of
> backups no amount of anything will change that fact.
Then do what we've already done to try to help you: open a terminal on
the source machine, type the commands and cut&paste to the list.
Unless you do that, showing *exactly* what you've done, I doubt anybody
can help you: all our crystal balls are broken...

And I'm *not* going to try to help you again unless I see that
cut&paste. Wasted time.

BYtE,
 Diego.

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

Re: Encryption on Mailing lists sensless?

[NdK]

Il 18/11/2014 19:15, Mirimir ha scritto:

> What distinguishes a mail list from email with bcc? Software? Size?
That you're sending to a *single* address that hides the others.

> As long as messages were separately encrypted to each recipient, no
> third parties would be involved.
But:
1) you should disclose the whole list of subscribed addresses (that's
really valuable metadata -- not to say a dream for spammers!)
2) you make mail headers and message size "explode"

Not good, IMVHO...

BYtE,
 Diego.

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

Re: Backup of encrypted private key on uncontrolled disks

[NdK]

Il 20/11/2014 18:33, Dave English ha scritto:

> Hint: do you always wear a hood over your head and the keyboard when entering 
> your passphrase?
Could simply use different passphrases for regular use and backups...

BYtE,
 Diego.

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

Re: Pros and cons of PGP/MIME for outgoing e-mail?

[NdK]

Il 26/11/2014 15:30, Bjarni Runar Einarsson ha scritto:

> And if we further factor in viruses and phishing and
> exploits and spam, then widely deployed PGP/MIME might make the real
> world less secure, not more. :-P
Maybe including a mandatory proof-of-work that includes addressee
identity might mitigate at least the spam?

BYtE,
 Diego.

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

Re: digest-algo SHA256, SHA-1 attacks

[NdK]

Il 26/11/2014 20:15, Peter Lebbing ha scritto:

> Has something like randomized hashing[2] been considered by the OpenPGP
> standardization people?
Well, IIUC with rhash you're giving the attacker another mean to tamper
with your message. Unless 'r' is chosen deterministically. But then it
can be predicted and could be accounted for... Maybe it could be more
effective to use two different hash functions, one to generate 'r' and
the other on the result?

BYtE,
 Diego

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

Re: digest-algo SHA256, SHA-1 attacks

[NdK]

Il 26/11/2014 20:39, Peter Lebbing ha scritto:
> On 26/11/14 20:31, NdK wrote:
>> Well, IIUC with rhash you're giving the attacker another mean to tamper
>> with your message. Unless 'r' is chosen deterministically.
> 'r' is randomly generated for each signature by the /signing/ party. So the
> attacker loses control over the input to the hashing algorithm, and they no
> longer can use collision attacks because they don't know the exact input to 
> the
> hashing algorithm.
Sorry, I've been too concise.
I see two problems with randomizing crypto:
1) who guarantees that the 'r' seen by the receiving party is the same
generated by the signer? Since it's usually trivially combined with
source text, I feel it's a huge attack vector
2) it could be a side-channel for leakage (say a smartcard under some
control by some TLA that encrypts the used secret key and some really
random bytes and uses the result as 'r')

BYtE,
 Diego.

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

Re: Randomized hashing

[NdK]

Il 27/11/2014 11:28, Peter Lebbing ha scritto:

[Resending to list]

> Perhaps I should add that it takes real research and formal proof to show that
> this randomized hashing doesn't add attack vectors, and I have been glossing
> over that. But that is because at a glance it looks like such research has 
> been
> done. That doesn't mean it's a fact that there are no significant attack
> vectors, but it does give the scheme credibility.
Well, I'm no expert, but it gives me the feeling of being potentially
dangerous, since once the attacker have your signature for a document
  s=E(Prk, H(RMX(M,r))) , r
(note that r is not signed, as the rhash scheme suggests and the paper
confirms!) he *might* be able to calculate r' so that RMX(M',r') ==
RMX(M,r) then 'recycle' your signature for M'. Remember that RMX is
proposed to be a simple block-xor! For very short (less than a single
hash block) messages it's trivial, if I'm not badly mislead by the
graphic description in the site:
RMX(0, 1) == RMX(1, 0)

Citing from the paper: "RMX can be used with any hash-then-sign scheme
by replacing the digest H(m) in the original signature scheme with H(RM
X(r, m)). In this case, the salt r is generated for each signature by
the signer and transmitted to the verifier together with the message and
signature[1]" and the footnote [1] is "In contrast to a previous
proposal by the same authors, the salt r does not need to be included
under the signature." . I haven't yet found out why he changed his mind.
At a first glance, it would be safer to have r *inside* the signature.
This way the attacker couldn't change it. But maybe that exposes other
problems.

To me it appears that *any* encryption of the message before hashing
would lead to analogue security properties. Say you generate 'r' and use
it as 'session key' to block-encrypt M then sign the hash of encrypted M
(IMVHO it's better if the signature includes r too). Maybe it's just a
performance issue?

BTW, some smartcards want you to feed 'em the hash state and the last
block of data so they can calculate the last hashing step by themselves.
And IMVHO it's better if the padding is generated by the card, depending
on the operation being performed: while the op is anyway 'RSA encrypt',
the padding should be different if you're signing an hash or exchanging
a session key. Failing to let the card do the padding could lead to
exposure of the private key, IIRC.

BYtE,
 Diego.

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

Re: Randomized hashing

[NdK]

Il 27/11/2014 14:45, Peter Lebbing ha scritto:

On 27/11/14 13:04, NdK wrote:

(note that r is not signed, as the rhash scheme suggests and the paper
confirms!)



"In contrast to a previous proposal by the same authors, the salt r does not
  need to be included under the signature."


I read this quite differently. I read it as that 'r' is not included in the
signature, that is, what is signed is still just the hash. It seems profoundly
silly to not include it in the signed data, for the reasons you mention. Can you
give a quote that actually says 'r' is not included in the signed data?
When it says that 'r' have to be sent separately. It's 'included' only 
indirectly in the hash calculation.



At a first glance, it would be safer to have r *inside* the signature.

Oh, I agree, I already thought that might close any 'r'-swapping security
issues, if there would be any; just like you can include the hash
algorithm in the signature to prevent swapping it out for a weaker one. But when
swapping 'r''s does not actually create any security issues, it just makes
things needlessly complicated.

I don't understand you.
I said that if you have a short message (less than hash len) it's 
trivial for an attacker to fix a new M' and calculate a new r' value 
that satisfies r xor M == r' xor M' . It gets harder with longer messages.



To use your smartcard example: the smartcard only
accepts a specifically formatted message. If you change that message to now
include a new value, you would need a new smartcard. Furthermore, the size of
'r' might pose a problem; it's a significant addition to the data structure that
is signed.

Depends on how strict the checking is.
E.g., if the smartcard only uses the raw buffer you pass it (just adding 
the needed padding before signing) and is able to accept SHA-512, then 
you could just use SHA-256 and append 256bits of 'r' w/o having to 
change the smartcard: it sees 512bits and pads 'em like in SHA-512. 
That's one of the reasons I like the cards that do the last hash round more.



Maybe it's just a performance issue?

I suppose also simplicity, verifiability, implementation cost...

Probably.


The rest seems unrelated to randomized hashing except for what I already
mentioned: that including 'r' in the signature would mean you can't use an
existing OpenPGP card. But I'll answer anyway.

I didn't study OpenPGP card protocol enough.


while the op is anyway 'RSA encrypt', the padding should be different if
you're signing an hash or exchanging a session key. Failing to let the card
do the padding could lead to exposure of the private key, IIRC.

I think you mean "RSA decrypt", for signing you use the "RSA decrypt" primitive,
just as you use to decrypt a session key.
Yup. Terminology slip. The RSA op involving the private key, so 
sign/decrypt.



But this is all already done in the OpenPGP card. It checks the data to be
signed conforms to PKCS#1; it is optional to check the DigestInfo, but the rest
of the data structure already differentiates it from an encrypted session key.
It will only let you sign with the "Signing" and "Authentication" keys.
Likewise, it checks that the output of decrypting with the "Decryption" key
conforms to the PKCS#1 format, so you can't fool it into a signing operation 
either.

Ok.

BYtE,
 Diego

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