Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

Is asymmetric encryption ever recommended for long-term storage of data, is it advisable for example to store data in a database such that:

1) A user enters data on a website, it is encrypted using a public key and stored. Neither the webserver nor the database server stores the private key.

2) The data is downloaded by a worker who was the permission to access it.

3) The worker uses the private key stored on his/her local computer to decrypt the data.

Assuming that the worker's computer is free of malware, the seeming advantage would be that if the database server were to be compromised the data would not be accessible.

What would be the problems with doing this?

share|improve this question
    
I find your system pretty secure, although let ear some expert's advices... –  eversor Aug 23 '12 at 8:52
    
What's your definition of long term storage? More than 20ish years? –  CodesInChaos Aug 23 '12 at 15:06
    
@CodesInChaos I mean several months to a year, perhaps medium term would have been a better description, I said long term storage just to be clear I am not talking about data in transit. –  broccoli_soup Aug 23 '12 at 17:56
add comment

4 Answers

up vote 1 down vote accepted

Yes, this is a good scheme for medium term storage, as long as it's implemented properly.

A few things to keep in mind:

  • Common asymmetric algorithms use semiprime factoring as their basis. As such, you can only encrypt data as long as the key, e.g. 4096 bits. This isn't very practical, so normally you would encrypt a symmetric key with your private (or, in this case, public) key and encrypt the data using a symmetric algorithm. So you'd use AES to encrypt the data, and RSA to encrypt the AES key.
  • Asymmetric key lengths have had to grow at a much faster rate than symmetric keys. It's generally considered that RSA 1024-bit is secure for now, but 2048-bit is more appropriate for anything you're going to need to remain secure for more than a couple of years. If you're looking at storing data for longer than 5 years or so, you're going to need 4096-bit or 8192-bit keys. That's not exactly performance-friendly, but it's a requirement. In contrast, it's thought that a 256-bit key couldn't ever be cracked with conventional methods, even with every ounce of energy on the planet, before the heat death of the universe.
  • Quantum computers, whilst a long way off, might allow for semiprimes to be factored into their constituent primes in polynomial time, which would break such asymmetric schemes. If you're planning on storing the data for more than 20 years, keep this in consideration.

An alternative would be to have the client encrypt the data with AES-256, then upload it. They can keep their symmetric key on their machine, or derive it from a password using PBKDF2 or bcrypt.

share|improve this answer
1  
Much faster rate is a bit of an overstatement. Assuming classical computers the difference between ECC and symmetric ciphers is merely a factor 2 i.e. a 256 bit ECC key corresponds to a 128 bit symmetric key. A key-exchange using 256 bit ECC costs less then 100μs. QC on the other hand might be an issue in the long term. –  CodesInChaos Aug 23 '12 at 11:12
    
@CodesInChaos I hadn't considered ECC, but what I said holds true for "classic" asymmetric keys. –  Polynomial Aug 23 '12 at 11:39
    
QC will solve the factorization, not might, Schors algorithm has been proven and run. Just the computers can't handle that large a numbers yet. –  ewanm89 Aug 23 '12 at 11:40
1  
@ewanm89 It will if QC gets to a useful state within the lifetime of the data. Hence might. –  Polynomial Aug 23 '12 at 11:43
    
Chose the asymmetric keys with some security margin and treat "public" pairs as sensitive secrets on the server. Replace the asymmetric keys when needed, re-encrypting the actually used symmetric keys, and destroy the old counterparts. This scheme is anyway advisable since you must consider key compromise. Obviously you also need backups of those private keys. A secret sharing scheme can be used here, so that e.g., 3 out of the 5 top managers/chiefs must collude to restore your private key. Given this construction, the weakest link will be the symmetric key temporarily stored on your desktop. –  pepe Aug 23 '12 at 12:14
show 1 more comment

It's a very good scheme in many ways, most of all that a server compromise cannot expose the data. There is one huge problem with it that is unavoidable, and that is availability. You aren't accounting for the human factor. You are expecting over years, perhaps decades, that people will be able to keep their private keys safe and available, and that's simply not going to happen!

The scenario is this: Bob creates an public/private key pair which he uses to encrypt the data on the server. 5 years later Bob gets massively drunk and leaves his laptop in the gutter he passed out in. Bob later realizes that he didn't include the directory where his key pair was stored in his automatic backup utility. Data lost forever with no hope of recovery.

I'd use client-side symmetric encryption instead, that way a server compromise cannot expose the data and it's up to the customer to store their password securely. Of course they could still lose the password, but it's easier to keep a password long-term than a private key. Better still you could offer an extra service that would store their passwords for them long-term, make some extra cash.

share|improve this answer
add comment

You have basically described how encrypted emails work, with either S/MIME or OpenPGP. With emails, the data transfer and storage servers cannot access the email contents; in your description, you are just using Web-based protocols (i.e. HTTP) for the particulars, instead of the email transfer protocols (SMTP, IMAP...).

The details of encryption (which algorithms to use, how to glue them together...) are known to be hard to get right, so you should stick to studied standards for that (i.e. OpenPGP or CMS -- CMS is the format which is at the core of S/MIME).

Note that this is called "asymmetric" for a reason: asymmetric cryptography makes sense only if the people who encrypt are distinct from those who decrypt the data. If the same user pushes the data for storage and then later on retrieves and decrypts it, then symmetric cryptography is sufficient, and easier to manage.

share|improve this answer
    
1) With SSH I use asymmetric encryption even though I own both the ends of the connection. 2) with S/MIME and PGP technically the message is symmetrically encrypted asymmetric encryption is used on the symmetric encryption key and for the signing. Remember all asymmetric encryption is slow. –  ewanm89 Aug 23 '12 at 11:37
add comment

Tom, Greg and Polynomial have covered most of the answer to this - however nobody has mentioned Forward Security (often optimistically refered to as 'Perfect' forward security) which is intended to protect the data even if the key is disclosed.

A caveat is that even standard asymmetric algorithms are relatively expensive in terms of processing and storage - the available range of forward secure algirothms even more so.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.