
An NFC PGP SmartCard for Android - mike-cardwell
https://grepular.com/An_NFC_PGP_SmartCard_For_Android
======
darklajid
That looks quite nice. I do have the same Yubikey and use my subkeys like that
- but via USB/on laptop and desktop.

For Android: I'd like to see support for this in Boxer. While I do prefer open
software, K-9 has been quite unstable for me and has a terrible UX (ever
noticed how server-side search is supposed to be used? Or the lack of any
error messages at all?). Looking at a bacon/OnePlus One running 12s here the
new client looks like a great improvement - but this is one feature I haven't
found (or rather, that doesn't seem to exist).

~~~
mike-cardwell
After I installed 12s on my OnePlus One the other day, first thing I did was
try Boxer against
[https://emailprivacytester.com/](https://emailprivacytester.com/) \- It
failed on the link prefetch test. I reported it and they said they'd look into
it. I've heard that the iOS version of Boxer fails quite badly but I've not
tested that myself.

[edit] The main problem with K-9 Mail IMO, is that it only supports inline
PGP. I.e, it doesn't have PGP/MIME support. It's open source, and there is a
~$1000 bug bounty for this functionality at
[https://www.bountysource.com/issues/815255-pgp-
mime](https://www.bountysource.com/issues/815255-pgp-mime) if anyone wants an
Android project.

~~~
darklajid
Thanks for the link to that test site - I didn't know about that.

As for K-9: Apart from doing calls I really just use my phone for mails and
K-9 isn't the right choice for me, sadly. I would really love to use an open
client, but while I can compromise on quite a bit (trying to migrate to a CM
without any GApps is next on the list), a decent mail client is mandatory.

(Incidentally that's the reason why I can't use Fx OS so far, the situation is
worse over there)

Interesting enough: Testing K-9 and Boxer on that site I get one violation in
each. Boxer with a 'Link Prefetch' as you said, K-9 with a 'Meta refresh'

------
an6n
This setup also works with the ZX2C4 password store for android. It's superb
:)

[https://github.com/zeapo/Android-Password-
Store](https://github.com/zeapo/Android-Password-Store)

------
jamessantiago
This was the main reason I picked up the yubikey, but I simply could not get
GPG to recognize the yubikey to import my keys. I'm sure I simply missed some
important step, but I couldn't figure it out with either GPG for windows or
GPG in a linux VM.

I wish there more smart card devices available for use with PGP that were as
widely purchasable as the yubikey.

~~~
ochang
The hardest part about getting the Yubikey to work, at least under Ubuntu, is
dealing with the marriage to gnome-keyring. Uninstalling it and the associated
autostart gpg-agent files (see [http://www.bootc.net/archives/2013/06/09/my-
perfect-gnupg-ss...](http://www.bootc.net/archives/2013/06/09/my-perfect-
gnupg-ssh-agent-setup/)) seems to do the trick. The documentation for doing
this is _horrendous_

------
baconhigh
2048 key limit kind of sucks though..

~~~
garrettr_
Even if the Yubikey supported larger RSA keys (3072 or 4096-bit), you might
not want to use them. Decryption is quite slow with a 4096-bit key on a
smartcard (for example, it takes ~5 seconds to decrypt with a 4096-bit key
using a g10code smartcard), which seriously hampers usability. Increasing RSA
key size also has diminishing security returns [0], so in an ideal world you'd
be using ECC instead, to get a strong 256-bit security level with good
performance. Unfortunately, both the OpenPGP smartcard spec and smartcard
hardware need to be updated to add support for ECC (and who knows how long
that might take).

It's worth noting that, while many people refer to the NIST guidelines that
say that RSA 2048-bit keys are acceptable until 2030, NSA's Suite B doesn't
include RSA _at all_ and only recommends ECC. The problem is that the state of
the art in open source cryptography software and hardware has not caught up to
NSA in the 10 years since Suite B was published.

If you really want to use your Yubikey, a reasonable compromise might be to
generate a 4096-bit RSA _master key_ (stored offline), and put 2048-bit
_subkeys_ on your Yubikey, which you would want to rotate periodically. This
gives you the benefits of a strong key for establishing your identity in the
Web of Trust and the better performance characteristics of 2048-bit keys on
smartcards. The downside is a higher upfront setup cost, and periodic
maintenance cost on both your part and on the part of the people you
communicate with, since you will want to rotate your subkeys and they will
need to refresh their copy of your key whenever you do that.

Given what we know from the Snowden documents, spy agencies seem to attack
endpoint security often and don't seem to be able to crack commonly used
encryption schemes, including RSA (although they can almost certainly factor
1024-bit keys, given current estimates for the costs of such an operation).
Therefore, the improved endpoint security afforded by using a GPG smartcard
might make using a smaller key size a worthwhile tradeoff.

On the other hand, GPG does not provide forward secrecy, so while it's
important to rotate keys and delete old messages as much as possible as part
of OPSEC for your local machine, if NSA is capturing your GPG messages from
the wire for later decryption, you'd probably want to prefer using the
strongest keys possible. This is an area where increased StartTLS deployment
(especially with forward secure ciphersuites) can help.

Finally, it's important to note that when you argue in favor of 4096-bit keys
over 2048-bits keys, you are saying "I believe my adversary can factor a
2048-bit RSA key, but not a 4096-bit RSA key". If your adversary can factor a
2048-bit RSA key, and they really want to read the email that's been encrypted
with your 4096-bit key, I would argue there are a lot of options available to
them, such as:

1\. MITM a software update for your mail client or operating system. It
depends on the specifics of your system, but many systems today use 2048-bit
(or weaker) keys for authenticating software updates.

2\. MITM any website you visit (most CA's have 2048-bit roots, so it doesn't
even matter if all the sites you visit have 4096-bit keys) and use a browser
exploit to deliver some malware that exfiltrates your email when you decrypt
it.

[0]: [https://www.yubico.com/2015/02/comparing-asymmetric-
encrypti...](https://www.yubico.com/2015/02/comparing-asymmetric-encryption-
algorithms/)

~~~
madez
The final part of your post is fundamentally flawed. You are saying that if
one part of your trust chain is limited to a certain security level, then it
makes no sense to make any part stronger. Following this practice would make
security a lot worse. One example result of your reasoning is "As long as
there are 1024-bit root CA's I don't encrypt anything because I could be MITM
anyway".

~~~
garrettr_
> You are saying that if one part of your trust chain is limited to a certain
> security level, then it makes no sense to make any part stronger.

Security is only as strong as the weakest link. My argument is that if your
adversary is powerful enough to factor an RSA-2048 bit key (but cannot factor
an RSA-4096 bit key), then it is likely they would also be powerful enough to
compromise your data via one of the "weaker links" that I described, rendering
the stronger key worthless.

I am not saying that it makes no sense to make any part stronger, just
reminding you that crypto is not magic security dust and bigger keys don't
necessarily make you safer in the context of an exploitable endpoint
environment.

The goal of this final part was to reinforce my argument that the security
benefits of using a smartcard outweigh the benefits of using larger RSA keys,
and so I am encouraging the use of a Yubikey as a GPG smartcard despite the
limitation of only allowing up to 2048-bit keys. Hopefully they will support
larger keys and/or ECC in the future and we can all switch to that when it is
available.

------
beagle3
Does anyone know of a reasonably priced (or unreasonably priced, for that
matter) smartcard that can do ECC of any kind? ECC25519?

------
zobzu
doesnt seem to work for ed25519 keys :(

~~~
madez
As far as I know the blocker is that ed25519 is not in the openpgp standard.
If that's wrong, please provide source.

~~~
AlyssaRowan
That's the big blocker - but, without wishing to be _too_ mean to NXP (sorry
Joppe!), the A700x MX51 microcontroller used in the YubiKey Neo is pretty old.
Really, most crypto chips are at their core: they almost always just make them
out of old ones with new bits glued on to (reasonably) try to reduce (high)
NIST/etc certification costs. (Seriously, it's still carting a hardware DES
implementation around.)

I believe it has a 2048-bit multiplier with a particular (patented?) form of
blinding to protect against side-channel attacks. That's used for RSA; it
can't do 3072/4096 bit RSA keys without tricks as it stands unfortunately.

The existing NXP ECC implementation is also not in JCOP's applets by default,
I think? From what I saw, it (ab)uses the RSA multiplier. That can go up to
320 bit curves _in theory_ without running out of scratch space, and is a
generic implementation of prime fields over GF(p), so you'd think it'd be able
to do some operations on Curve25519 fine in principle.

And it can, but in my testing it did what I thought it'd do, and leaked side-
channels when used with the NIST curves and djb's curves, because the blinding
on the RSA multiplier was simply not designed to cope with the regular
structure of the special prime fields that most elliptic curves use. And the
performance of random prime fields (like Brainpool) in software is awful, so
no-one else wants to use those.

You've also got the problem that the existing implementation there can only do
ECDSA (not the EdDSA used by Ed25519) and doesn't have SHA-512 around, too.

A pure software implementation that avoids using the RSA multiplier would be
much safer, and I think in principle would be able to do the other CFRG
favourite, Ed448-Goldilocks, as well. That is what some HSM vendors are doing.
It'd be a very tight fit on the NXP A700x, however. I'll leave that to NXP, if
they want to.

I myself want an _open_ crypto chip, not one that still needs blobs in 2015.
And I've seen a few movements in that direction.

~~~
kfreds
> I myself want an open crypto chip, not one that still needs blobs in 2015.
> And I've seen a few movements in that direction.

Who's working on this? Anyone else than the team behind cryptech.is?

~~~
qrmn
A good, open, microcontroller design with no caches, USB (or something), a
TRNG, an onboard voltage/clock regulator, registers/RAM which zeroises on
faults/parity/intrusion sensors, a fresh approach to avoiding SPA/DPA attacks,
some EEPROM (also with parity & zeroisation traps), and ideally a way for a
host to automatically read (/audit) all the software running on it (Harvard
arch?) would do the trick. It doesn't have to be fast, but it does have to be
safe.

I gave it a try, but it really needs someone with actual ASIC design
experience instead, I think! I'd love to see one of the vendors do something
like that - as you can see there are plenty of waiting customers, but I'm not
holding my breath.

Cryptech are probably the strongest contenders for now?

