Would you store your GPG private key in the cloud?

[he...@softcom.net]

From the PGP manual:

"...Always keep physical control of your secret key, and don't risk
exposing it by storing it on a remote timesharing computer. Keep it
on your own personal computer."

But it seems to men that if the private key is protected by a strong password it would be OK. I'm specifically referring to GnuPG. Comments?

[tom st denis]

The whole point of public key crypto is I don't have to hand you a
private key encrypted or otherwise.

So no, I wouldn't store my private key "in the cloud" [oh how I hate
that fucking term].

Tom

[Gordon Burditt]

No, it's *NOT* ok if you ever intend to get the password to the
private key anywhere near the remote computer ("cloud"). If you
don't intend to get the password to the private key anywhere near
the remote computer, what's the point of storing the private key
there? (Let's define "anywhere near" as "within ten miles of an
Internet connection", which pretty much covers the land area of
Earth, and most of the oceans, too, although possibly not most of
the bottom of the oceans.)

If you must do this, be sure that your password (in words) is at
least 100 times longer than the key (in bits). And if you can
remember all that, why not just remember the key? It's much shorter.

If you fetch your private key from the cloud every time you use it,
that by itself will provide governments with the ability to track
you, even if they never attempt to decrypt the key.

You can pretty much figure that 50% of governments (this would
include not just the NSA (USA), CIA (USA), and MI5 (UK) but also
the Benbrook School District and Iraq) already have standing search
warrants for any PGP key served on cloud providers.

[Peter Fairbrother]

[As do I. Apart from anything else, "the" cloud does not exist - there
are several clouds, run by different companies, not one cloud (to rule
them all..).]

On reason not to store a private key in a cloud is the problem of secure
deletion (or indeed storing any data in a cloud which is in any way, now
or in the future, at all possibly private or confidential - once it's
stored in a cloud there is no going back and changing your mind).

At some future time you may wish to delete the private key, or some
other data, and be sure it is deleted.

If you store data in a cloud you can never be sure that there isn't a
copy of that data lying around somewhere.

Yes, you can secure the data or key with a strong passphrase, but how
many people choose secure passphrases? Or use one strong passphrase for
each item of data, essential [1] if you want to be able to do detailed
secure deletion?


So no, don't store a private key in a cloud. Or any other private or
confidential data either.

-- Peter Fairbrother


[1] there are ways round this, but they are the subject of a paper (on
observable steganographic filing systems) I am working on so I won't go
into them here and now.

[Andrew Swallow]

Do not forget the French. They are big SIGINTers and tip off civil
servants buying from foreigners.

Andrew Swallow

[John H Meyers]

On 9/17/2012 4:25 PM, Gordon Burditt wrote:


> No, it's *NOT* ok if you ever intend to get the password to the
> private key anywhere near the remote computer ("cloud"). If you
> don't intend to get the password to the private key anywhere near
> the remote computer, what's the point of storing the private key
> there?

So you won't lose it if your computer and your house burns down,
floods, or your entire town is blown apart by a tornado?

So that you can also protect a set of public keys already "revoked"
in case you want to revoke them in the future,
but have similarly lost your local possessions?

> If you must do this, be sure that your password (in words) is at
> least 100 times longer than the key (in bits). And if you can
> remember all that, why not just remember the key? It's much shorter.

Do you have a private key short enough to remember?

Do you mean remembering the passphrase for the private key,
rather than remembering the private key itself?

I've stored AES-256 encrypted public and private keyrings
(without passphrases), plus separate pre-"revoked" keys,
in attachments saved in web accounts, which I think to be overkill
for the very little use I make of PGP/GPG, anyway.

Being neither involved in national security
nor criminal activities, my few private messages
(or encrypted files) and occasional need to "sign"
something to convince a reader that I actually authored it
(or that I didn't author something else), is not, to me,
worth buying a safe deposit box in Fort Knox to protect,
but the higher the value of what's to be protected,
the more protective one needs to be of one's keys.

By the way, wouldn't any personal computer "cloud backup"
(e.g. Carbonite, Acronis True Image 2013)
happen to include all private keyrings anyway?

Any other form of backup is also inevitably still lying around,
somewhere, physically, and even when we store backups in a vault,
we're transporting new and old backup media to and fro,
necessarily leaving it not far from the computer at times,
where someone might break in and snatch it, no?

It's even unsafe to memorize anything, given how much easier it is
to crack the human than to crack well encrypted storage, and it would
then seem that the only absolutely safe way to protect the
memorized info is to die or to suffer other loss of brain function.

So in general discussion of these sorts of questions,
shouldn't it all be in perspective of the relative value
of what's to be secured, vs. risks and costs of loss,
and the risks and costs (including effort)
associated with various strategies for protection?

--

[John H Meyers]

On 9/17/2012 11:41 AM, he...@softcom.net wrote:

> From the PGP manual:
>
> "...Always keep physical control of your secret key, and don't risk
> exposing it by storing it on a remote timesharing computer. Keep it
> on your own personal computer."

This seems to be a direct quote from a very old document
("timesharing" being a somewhat out of date word),
the complete text of which is indeed available at links below,
where it's identified as "the original documentation
for MIT's PGP 2.6.2, included here in unmodified version...
by Philip Zimmermann, Revised 11 October 94"

<http://www.pa.msu.edu/reference/pgpdoc1.html>

<ftp://ftp.pgpi.org/pub/pgp/2.x/doc/pgpdoc1.txt>

All the same, the principles have not changed;
I just thought to identify the original complete context,
as that document no longer comes with my PGP Desktop
for Windows, from its current vendor Symantec
(who continue to honor the free distribution for personal,
non-commercial use, the basic features never expiring
from the free trial that one may download,
so I ceased to bother also installing GPG).

>
> But it seems to me that if the private key

> is protected by a strong password it would be OK.
> I'm specifically referring to GnuPG. Comments?

Are you asking whether you can keep backups as files
on remote storage (or as attachments to remotely stored emails),
to that you can recover them if your home suffers some disaster?

Despite the horrors that the recognized experts express,
I (not an expert, but also I think not an idiot -- perhaps
approximately the geometric mean between these two extremes :)
store AES-encrypted zip files of my keyrings (public & private)
as mailed to more than one "webmail" provider in attachments,
for this purpose, without including any passphrases.

It seems to me that any popular whole computer backup based on
vendor-supplied servers (e.g. Carbonite, Acronis True Image 2013)
will also contain your keyrings, resulting in pretty much the
equivalent of your mailing just the encrypted keyrings to yourself,
or of storing them on "remote drives" of any sort.

The fact that my emailed zip files contain keyrings
is evident from the non-encrypted names of the encrypted files
in the encrypted zip file, but this could be completely hidden
by changing the zip file's name and then re-encrypting the renamed zip file,
thus also encrypting the "directory" of file names in the original zip file,
as well as the fact that what was encrypted was even another zip file.

For my convenience,
I also include a set of keyrings in which my public keys are "revoked,"
since revoking a key is also difficult without the private key,
but easy if you have a revoked key ready for instant upload
(revocation offers no protection from using a revoked private key
to decrypt anything, but it calls any future use for signing into question,
in case that's of any importance).

Just avoid accidentally revoking your keys on the keyrings
that you normally use and intend to keep using,
without having made separate backup keyrings :)

I'll check back for any expert comments on my non-expert remarks, thanks.

--

[he...@softcom.net]

Thanks all, for your insightful responses. You've certainly given me something to think about. Now I have a new question:
Given a piece of randomly-obtained ciphertext that was encoded by a public key, is it feasible to find the public key that encoded it assuming that the public key is on a key-server somewhere? In other words, is the identity of the public key encoded with, and a part of, the encoded message?

[Christopher Head]

On Sun, 23 Sep 2012 07:37:38 -0700 (PDT)
he...@softcom.net wrote:

> Thanks all, for your insightful responses. You've certainly given me
> something to think about. Now I have a new question: Given a piece of
> randomly-obtained ciphertext that was encoded by a public key, is it
> feasible to find the public key that encoded it assuming that the
> public key is on a key-server somewhere? In other words, is the
> identity of the public key encoded with, and a part of, the encoded
> message?

First off, if you’re talking about GPG/PGP per se, then in most
ciphertext packets the recipient key ID is embedded (in the clear) so a
recipient who has multiple private keys can save time. To disable this,
see --hidden-recipient and --throw-keyids (one or the other will do
what you want).

The man page states that anyone who can decrypt the message can
apparently find out the identities of the other recipients. This makes
sense if the same plaintext block (symmetric key plus padding) is
encrypted to each recipient (someone decrypting the message can do
trial encryptions of the symmetric key plus padding using suspect
public keys). I don’t see how it could be done if the key were
encrypted with different padding for each recipient.

There may be some mathematical property someone is aware of that could
identify the encrypting public key of a ciphertext, but I’m not enough
of a mathematician to see that.

Chris