
Bruce Schneier has changed his PGP key to 4096 bits - oktypok
He decided to change his 16-years old 2048-bit key on the same day he let the world know he was working on Snowden files. Possible reasons:<p>- he forgot his password<p>- he lost his private key<p>- he knows more than he can tell us<p>http:&#x2F;&#x2F;pgp.mit.edu:11371&#x2F;pks&#x2F;lookup?search=schneier&amp;op=index<p>http:&#x2F;&#x2F;www.theguardian.com&#x2F;world&#x2F;2013&#x2F;sep&#x2F;05&#x2F;nsa-how-to-remain-secure-surveillance
======
tptacek
Or:

\- he really doesn't use his PGP key all that often, had the same one for 16
years on god knows how many computers, and decided that if he's going to
generate a new one, he might as well send a message with it.

~~~
knowtheory
Normally i'd let it go, but i actually would like some clarity on your intent
here. Are you implying that Schneier doesn't use encrypted communications on a
regular basis, that PGP is impractical, or both?

(and to be clear, my intent is not to bait, i'm actually curious)

~~~
tptacek
Most people don't use PGP on a regular basis. I'm use PGP a lot, more than I
think most HN readers, but most of the people I talk to (even in my own field,
which is full of secrets and adversaries) don't have PGP keys.

~~~
miloshadzic
Does the reason for that ever come up in a conversation? I thought that
everyone working in security used PGP a lot.

~~~
betterunix
In fact, it is unusual to see people even _sign_ emails in the (academic)
cryptography community, let alone encrypt messages (at least in my
experience). It is surprisingly rare to see academic crypto researchers
actually _use_ the systems they design, even for basic things like signing and
encryption.

~~~
Torgo
Strategically, you are probably better off not signing a message unless you
want the message to be verifiable.

~~~
reeses
There's also the paranoia of non-repudiability with signed messages. In
general, there is minimal benefit just signing a document. I don't care if
someone I work with is spoofed because it will become obvious very quickly.

It's only in a very few cases where there's an advantage in signing a
document, and it's usually more in the verifiability of content (so that you
can verify that nothing is lost/changed in transit) than in the verification
of identity.

Given the lack of adoption of PGP/GnuPG in email clients vs. S/MIME, if I'm
signing my emails without encrypting them, chances are the recipient would
still be able to read my emails and, knowing my writing style and given the
context, be able to suss out that I was in fact the author.

I use the word "paranoia" intentionally because there's a lack of meaningful
legal precedent establishing that a gpg-signed message is enough to establish
authorship. In a civil case, sure, it looks bad, but you could easily
say,"oops, I stored my public key on [vps or cloud service], which was a well-
known victim of a hack."

------
elliotanderson
Bruce's article on staying secure from the NSA[1] talks about using an air
gapped computer to avoid being compromised via the network. If he hadn't been
keeping his keys on such a machine previously - recent disclosures may have
changed his mind and forced him to regenerate his keys.

[1] [http://www.theguardian.com/world/2013/sep/05/nsa-how-to-
rema...](http://www.theguardian.com/world/2013/sep/05/nsa-how-to-remain-
secure-surveillance)

~~~
jamesrom
I think this is the most likely reason.

------
IgorPartola
So I have a GPG key. I used it a couple of times. Currently, it's most useful
to me to sign my own Debian package repository. However, I can't seem to
figure out how to get into the whole Web of Trust thing. Nobody I know has
their own GPG/PGP key that they use and have signed by others and tools like
BigLumber and other places where I looked for key signing parties have not
turned up any results. I not spending all my free time looking for GPG users,
but I have spent what I feel is more than a casual amount of time looking for
people to exchange key signatures with. What do y'all do for this? Any advice?

Edit: I am located in the North Eastern part of the US.

Edit 2: perhaps we need a geolocation aware social network a la Square but
just for notifying you of other nearby PGP users...

~~~
leot
Webmail services could have jump-started WoT a decade ago, much like Hotmail
jumpstarted popular email usage. [1] Had they "turned on" PGP for all their
users, and then made it easy to tell when messages were being sent securely
and when they weren't, it would have completely (and for the better) changed
how we interact online (e.g., no need to "sign up" for web services, or "sign
in" to every single site we visit; a lot less spam; and incredible other
potential besides).

I think we can now surmise one big reason why they didn't.

(tptacek will say that web-based PGP is the wrong way to go because it's too
insecure: fact is it's still way more secure than sending cleartext emails,
and in any case the point of it is to bootstrap adoption and hopefully trigger
an email "arms race")

[1] Gmail even began with some support for PGP signature verification
[http://googlesystem.blogspot.com/2009/02/gmail-tests-pgp-
sig...](http://googlesystem.blogspot.com/2009/02/gmail-tests-pgp-signature-
verification.html) ... and then stopped. Anyone on the inside know why?

~~~
IgorPartola
Webmail + PGP really is insecure. The only way to do it properly would be with
some OSS plugin + completely separate process for actually reading/writing
emails.

However, I think we could use a better way to associate emails with PGP keys.
For example, my email uses a domain I own. I have HTTPS on my domain, so I can
deliver my public key to you securely over the Web. Alternatively, Google
could have a service where you securely ask it "what is the key for
example@gmail.com" and it responds with the key. Bootstrapping a full WoT is
hard, but often times the requirements are much less strict. Most times I just
want to know that if I email you that you are the only one that can read the
email. I might not even care if you are truly the person you claim to be, as I
know you by your email handle more than by your real name (as in emailing
Satoshi Nakamoto). Of course having a webmail provider tell others what your
public key is means you have to trust your webmail provider not to lie. You
also have to trust their delivery mechanism (HTTPS) and the people that issue
them their SSL certificates (as we know this can be circumvented by motivated
governments).

I understand why GMail wouldn't want to support PGP. They read your emails to
target ads at you. Without that there would be no GMail. If you encrypt
everything you send/receive and GMail cannot read it, then they have no way to
monetize it.

~~~
leot
There are two concerns:

1) Security of email messages in transit, assurance that you're receiving
emails from the person who claims to be sending them, etc.

2) Preventing your email service provider (and any MITM) from reading your
emails.

These concerns are relatively independent of each other. While if you're a
die-hard PGP advocate you'll want both 1 and 2, PGP-in-Gmail gives us 1, and
that's a pretty great start.

Right now we have neither, and we're all much poorer for it.

PGP-in-Gmail instantly gives it to _everyone_ that has an @gmail account (and
anyone else who has signed up to a WoT). It would probably insist that you use
two-key authentication. And it would work like this

0) Every message you send is automatically signed by you by default. 1) type
in >=1 email addresses in To: bar 2) If all of the email addresses you sign
have public keys associated with them that Gmail can locate, they all look
"Green" (or whatever) and the [Send] button becomes [Send securely]. 3) If
_any_ of the addresses doesn't have a public key associated with it, then
nothing is encrypted (i.e., exactly the behavior we have now).

If you don't trust Gmail, you shouldn't trust it any _less_ if/when they
deploy PGP for it. And no one is saying you _have_ to use it. All I'm saying
is that Gmail, Hotmail, etc. seem to be the best equipped to trigger the
widespread adoption of PGP.

~~~
Natanael
> If you don't trust Gmail, you shouldn't trust it any less if/when they
> deploy PGP for it.

The problem here might be that people (including Google, I guess) don't want
users to trust anything MORE THAN THEY SHOULD, which is a major risk in a case
like this. Sometimes security features can be counterproductive since they can
lead to the users making bad assumptions and therefore bad decisions that they
otherwise wouldn't have made. PGP in webmail implemented just in JS is likely
one of these things that could make things worse due to how users treat them.

~~~
leot
I'm actually suggesting that if we're going to trust Gmail completely _anyway_
, we might as trust them to encrypt-and-decrypt everything server side. No
need for any fancy PGP in JS. Gmail still gets to read your emails and
generate ads (though it might not be able to do offline analytics to your
emails). The point is that with PGP-in-Gmail we can at least trust that the
email _in transit_ is much more secure, and furthermore we can verify the
identity of anyone sending us messages, too.

------
farktronix
It's curious that he didn't sign his new key with his old key. Does anyone
have a good explanation for why he wouldn't want to do that?

~~~
stcredzero
If someone can crack his key old as of 2020, then they can start distributing
a fake Bruce Scheneier 4096 bit key at that time. He might think it's better
for him as something of a security celebrity to just publish a new key.

~~~
emillon
If the old key is revoked, and is the only trust path to the new one, it's a
worthless key.

------
michiel3
In the post he also describes that he now uses a new process which involves a
computer that has never been connected to the internet and its sole purpose is
encrypting and decrypting files. Why not use it to encrypt and decrypt emails
as well? That'd also potentially involve generating a new key pair.

> 3) Assume that while your computer can be compromised, it would take work
> and risk on the part of the NSA – so it probably isn't. If you have
> something really important, use an air gap. Since I started working with the
> Snowden documents, I bought a new computer that has never been connected to
> the internet. If I want to transfer a file, I encrypt the file on the secure
> computer and walk it over to my internet computer, using a USB stick. To
> decrypt something, I reverse the process. This might not be bulletproof, but
> it's pretty good.

~~~
malandrew
With linux, is there any way to compromise the USB stick used for the air gap?
AFAIK the Stuxnet virus was originally spread via USB stick, however I reckon
that it involved Windows machines that are known to execute files on USB
sticks.

~~~
pndmnm
Years ago, a classmate of mine built a rig out of a receipt printer and one of
those old handheld scanners to provide an "air gap", though it never really
worked (sort of an art project at the time). Might be time to revive the
idea...

~~~
phunge
How about 2 serial ports, connecting only TxD, RxD and GND? 3-wire RS-232
basically has no attack surface, there's no protocol to speak of. [edit:
shabble already suggested this]

~~~
reeses
Something very similar to this has been used in the military to "bridge"
network barriers at differing security levels. The US Navy uses "SDR" (Secure
Data Replication) to transfer content under control.

You could get all stuxnet and exploit the various applications (such as the
components that inspect zipped content), but the transport itself is a simple
file copy over a bitstream. You could do the same thing with kermit and
uuencode a bit more easily.

------
vabmit
An interesting thing to note about 4096bit RSA openPGP keys, that's what
Snowden was using. His PGP Key was a 4096bit RSA signing key with a 4096bit
RSA encryption subkey.

~~~
reeses
I suspect that it's because 4096 is the largest permitted RSA key on most
software right now. There is no 11 on that dial.

~~~
Natanael
Some allow larger keys. I once generated an 8192 bit key. It took a loooong
time. Never used it. I guess that piece of software would have allowed 16k
keys too.

------
autodidakto
Anyone know of a good tutorial for revoking and recreating your key as
painlessly as possibly?

~~~
Karunamon
I'd imagine the process works something like this:

    
    
       * Generate the new key
       * Sign the new key with the old key
       * Generate the revocation cert for the old key
       * Push the revocation publicly with a reason of "Superseded by (fingerprint of new key)" or similar
       * Push the new key
       * Try to get your new key signed by everyone that signed your old key for authenticity's sake
    

I'm not too sure how the community of GPG users out there sees key revocation
socially, so you may or may not want to bother with that bit. Perhaps hold off
on pushing the revocation until the new key has been in use for a while?

~~~
betterunix
One issue I have noticed is that people do not frequently update their keys
from the key servers. Key revocation is not all that useful if you are not
periodically checking for published revocations...

~~~
reeses
And 90% of the time, people want to revoke their old keys because they had a
pressing one-time need to have a PGP key (vendor exchange, whatever) and lost
the private key without generating and saving a revocation certificate.

This is a place where solid infrastructure support at the OS-level would
really help. Instead, it's nerds and the paranoid who bother, and they'll
steal the software or insist on open source anyway. :-)

------
tomrod
I know I'm still a cryptographic neophyte, but why doesn't he use four times
the bits?

~~~
steveklabnik
Sometimes longer keys are worse. I am also a newbie so I forget what that kind
of attack is called.

~~~
a--b
If you find anything could you please let me know?

------
rdl
I wish there were a decent hardware PGP key token available now -- something
which could support 4096 RSA and communicated via (ideally) BT but also
acceptable USB to a host. The GPF stick is out of stock.

~~~
Torgo
I don't even know if common linux distributions even support the right
combination of drivers and gnupg to even support 4096-bit RSA keys. I tried
this a couple of times over the last two years or so, and there was always
some bug, or it was fixed in a later version not in the repos yet.

~~~
rdl
I'm on OSX, and macports gpg does 4096 fine (gpg (GnuPG) 1.4.13). Also works
fine on Ubuntu (gpg (GnuPG) 1.4.11)

What no one seems to support is ECC, but until I get more confirmation, I'm
inclined to follow Schneier and stick to 4096 RSA in preference to ECC, at
least where possible.

I really don't want my key to be on my general-purpose machine. I have fully
airgapped machines for code signing and such, but for regular communications,
I want a key which can be used from my laptops (mac, ubuntu) and ideally from
iOS/Android (via bluetooth), without being exposed to compromise on the host.
You can force me to sign or decrypt arbitrary stuff while my key is paired,
but can't steal my key.

Ideally v2 would have some kind of log of all transactions on the secure
token, so I can at least see if I'm being trolled for signatures/decrypts by
malware on the host, and in v3, some kind of secure UI on the device.

I figure I could make a device like this, in a fully open/auditable design,
for <$250/unit. Ideally something which looks like the Blackberry CAC reader,
but uses bt 4.0 le to talk to a paired host, rather than power-hungry
bluetooth.

~~~
Torgo
The bug in question was the interaction between the GPF cryptostick and
4096-bit RSA keys. You could create them, put them on the stick, but trying to
verify signatures had a bug. I believe it's fixed

I can confirm the German Privacy Foundation PGP stick does NOT support ECC.

You might talk to the GPF, they are currently working on their next version of
their cryptostick, and it's supposed to have encrypted USB storage and the
ability to support applets.

------
a--b
I've been using 16,384 for my SSH key sizes for the past year and am
considering using 32,768 a soon as my two year rotation period is up - would
there be any problems with my key sizes?

~~~
Qantourisc
Long key generation, longer login time, possible lack of a proper entropy in
the key, if the entropy source is not good.

~~~
a--b
I'm okay with waiting, but the lack of entropy worries me a tad. Would that be
super common with keys of that length? Thanks for the reply!

------
Qantourisc
1024 should have been save, but modern PC's can easily do 4096... So all my
certificates are 4096 at the least. No reason to take a change, while there is
no significant downside. So why take the risk with 1024? Maybe it's to weak,
and maybe, this means we can keep our data secure for longer.

Te only reason NOT to use them: mobile end-clients, and busy server who would
die from the extra CPU burden. But other then that, WHY NOT ?

------
rbchv
I know the fundamental idea behind PGP and related technologies. My question
is, if bumping his key from 2048 to 4096 bits will keep him safe until around
the year 2020 (as stated by a previous reader, and from keylength.com), why
not just use a 8192 bit key, or 16384 bit key and be safe for virtually your
lifetime?

Does the computing cost to encrypt/decrypt make this impractical?

~~~
joeyh
4096 is the largest key size gpg offers today. It was the largest key size gpg
offered in 2009, which is why that's the key size I'm using now. In 1996 the
largest key size pgp supported was probably 768 , which is why my first pgp
key is that size. I know for sure that in 1999, the largest key I could manage
to make was 2048. Looking back at those older keys, I would prefer if I could
have chosen larger key sizes for them. So I suspect that in 10 years I will
wish I could have used a 8196 or larger key today..

I suspect that gpg partly doesn't offer insanely large key sizes because then
people like me will naively use them even if we don't need them. And perhaps
partly because dealing with the math for such large numbers is harder to
implement. I'd rather it offered much larger keys even if they came with
warnings that it might make operations slow.

~~~
joeyh
Seems that if you're really paranoid, gpg --gen-key --batch with an
approptiate batch file can make 8192 or larger keys. Currently trying to
generate a 81920 bit key, for general giggles and to increase my NSA rating.

~~~
moep
Could you provide a sample batch file for this purpose? That’d be really
helpful.

------
mrjj
Is he really afraid of 2^n/2 brute power of quantum computers or this is just
overkilling of overkill?

~~~
vabmit
There's no need for a quantum computer. Everyone should be using at least
4096bit RSA.

1024bit RSA keys can be factored with conventional non-specialized hardware
(read: CPU's, not even GPU's) with GNFS.

IMHO, 2048bit RSA keys can be factored by custom hardware that the NSA has
developed. I posted my reasoning for this hypothesis in other hackernews
threads. A very quick/terse run down of the main key points - 1) NSA is known
to use customer hardware (they have their own chip fabs. You can extrapolate
performance gain from things like GPUs, FGPAs, and Deepcrack 2. Al Qaeda uses
2048bit RSA for internal communications 3. Most corps, diplomats, criminals,
and normal people use 2048bit RSA either directly (SSH keys, Website Certs,
VPNs) or indirectly (CA's still use 2048bit RSA certs valid until 2020)

~~~
SwellJoe
"2\. Al Qaeda uses 2048bit RSA for internal communications

3\. Most corps, diplomats, criminals, and normal people use 2048bit RSA either
directly (SSH keys, Website Certs, VPNs) or indirectly (CA's still use 2048bit
RSA certs valid until 2020)"

I don't see how this is evidence that NSA _has_ the ability to compromise 2048
bit keys, at will. Only that they very likely _desire_ that ability. Math
doesn't respond to desire.

That's not to say I believe they don't. Just that I can't accept two of your
three premises for why one should believe they do.

~~~
drdaeman
> normal people use 2048bit RSA either directly (SSH keys, Website Certs,
> VPNs)

Any reason for that?

[Almost] all of my SSH and TLS (be it HTTPS or OpenVPN) keys are 4096 bits
long.

I wasn't woried about TLAs with supercomputers snooping on my wires, just
heard that 4096 bit RSA keys are considered more secure than 2048 while not
sacrificing performance much, so I just didn't have the reason to specify
lower size.

~~~
reeses
When a lot of these tools were first implemented, to get enough entropy, you
would have to type and move your mouse for a long time to generate a 1024-bit
key. I remember really, really hating that process.

Now, you kids these days with your entropy pools and PRNGs in your CPUs
because you had an empty spot on the tape-out...get off my lawn!

------
crystaln
Or... he's playing it safe, since he doesn't know what he doesn't know.

------
Sami_Lehtinen
Yet he prefers aes-256 over twofish-256 or camellia-256.

~~~
baiitsu
Source? And even if he does, how is that a problem? AES-256 has been
independently tested and reviewed. Whether or not the NSA forced the NIST [1]
to adopt it as a symmetric encryption standard is irrelevant.

[1]: [http://blog.cryptographyengineering.com/2013/09/on-
nsa.html](http://blog.cryptographyengineering.com/2013/09/on-nsa.html)

------
hannibal5
There is nothing suspicious with that.

He has worked previously in mostly corporate and private context, so 2048 is
just fine. Now he works with people and data NSA wants their hands on and he
wants the data to be secure also in the future. It's just reasonable to move
to 4096 key sizes.

[http://www.pgp.net/pgpnet/pgp-faq/pgp-faq-keys.html#key-
size](http://www.pgp.net/pgpnet/pgp-faq/pgp-faq-keys.html#key-size)

>Dr Lenstra and Dr Verheul offer their recommendations for keylengths. In
their calculation, a 2048 bit key should keep your secrets safe at least until
2020 against very highly funded and knowledgeable adversaries (i.e. you have
the NSA working against you). Against lesser adversaries such as mere
multinationals your secret should be safe against bruteforce cryptoanalysis
much longer, even with 1024 bit keys.

See also: [http://www.keylength.com](http://www.keylength.com)

~~~
tptacek
Your secrets are not safe against multinational corporations with 1024 bit
keys. The likely cost of the capability to break a 1024 bit key is probably
(for a private entity) in the low tens of millions. You wouldn't even be safe
from the operators of HN with that margin of security.

~~~
hannibal5
that's why we are talking 2048 vs. 4096.

~~~
mpyne
I think he's referring to the trailing sentence that you quoted which
mentioned 1024-bit keys being safe against multinationals.

------
antocv
Read the guardian article.

He is using Windows.

------
betaclass
Well mine is 4097 bits. Checkmate, Sir.

~~~
SimHacker
Your goes to 0x1001.

