4

This design is for transport security between a client and a server. I'm planning on using it for a cloud storage system. I would like it to be secure against you-know-who.

I'm trying to prevent the anyone (like the NSA) from forcing me to hand over my keys to the data, so the goal is for even me not to be able to access it.

Here's how it works:

There are two layers. On the outside there is a layer of RSA-4096 encryption with a permanent encryption/decryption key pair. On the inside there is another layer of RSA-4096 encryption, but it uses a temporary key pair which is not saved anywhere, and can not be turned over. It uses the outside layer to verify the identity of the server, and the inside layer to secure the connection.

Are there any possible holes in this schematic I'm not seeing, besides the fact that if I was forced to turn over the permanent private key, impersonation of the server would be possible, and the temporary keys would be useless? Also, how can I resolve this?

atk
  • 2,156
  • 14
  • 15
Phoenix Logan
  • 502
  • 2
  • 13
  • The basic idea you have here is forward secrecy. It is supported in SSL using Diffie-Hellman ephemeral modes. There's not much you can do about "you know who" capturing the keys and impersonating the server. http://en.wikipedia.org/wiki/Forward_secrecy – paj28 Nov 11 '13 at 13:32
  • What if I did this... Forget the forward secrecy, have no SSL-type encryption layer. Instead, have the files being sent over be encrypted with AES-256, and the key is derived by hashing the password 1,048,576 (2^20) times to prevent brute force. The server has no knowledge of the key. How could I verify the password without exposing it to the server in any way? I was wondering if I could somehow use the password to digitally sign a test message somehow. Is this possible? – Phoenix Logan Nov 11 '13 at 13:41
  • I'm going to ask this in a new question. – Phoenix Logan Nov 11 '13 at 14:00
  • Based on the comment that you're simply trying to avoid having data to hand over to someone, why bother with a whole new communication protocol? Why not just (a) delete all cached data that you receive/send, and (b) generate an ephemeral key per transaction (like TLS does - in fact, just use TLS) and (c) secure delete the key when you're done with it? – atk Nov 11 '13 at 15:48
  • Bear in mind that maintaining encrypted data that you deliberately don't have access to - especially if you've said it's to keep the NSA out - can be deemed conspiracy, contempt of court, or destroying of evidence in some countries. – Owen Nov 11 '13 at 16:38
  • 1
    @PhoenixLogan: You said "sent over be encrypted with AES-256": well, I see you use precisely _the_ algorithm recommended by the NSA, the NSA must certainly thank you for your confidence ;) ! – WhiteWinterWolf Nov 11 '13 at 18:34
  • Any alternatives to AES? – Phoenix Logan Nov 11 '13 at 18:46
  • @Owen: Do you have any references for where that happened or laws that define such? I'm very interested to see more info on that... – atk Nov 11 '13 at 18:59
  • 1
    "goal is for even me not to be able to access it" Well, that's easy enough: delete it. What you've not specified is who _can_ access it, under what circumstances, and where they store the necessary key. Multiple hashing of passwords doesn't necessarily buy you more security, for complex reasons. – pjc50 Nov 11 '13 at 20:56
  • @atk Nothing to hand, but I'll try to find something. There was an excellent talk on the issues of it at Defcon a couple of years back, 2011 I think, and that referenced times that people had been held for refusing to give decryption passwords, or prosecuted for destroying hard drives etc. – Owen Nov 12 '13 at 11:08

1 Answers1

20

Yes. The first problem is that you are writing your own crypto protocol. Please don't do that. Use TLS or SSH instead.

Second, there are many books written about writing secure protocols, and even common problems in protocols. Your algorithm has them.

Third, you do nothing about out of order traffic, modified messages (you mention encryption but you don't mention integrity checks), your mode of encryption is not defined (and may have problems), your initialization vector is not described (and may have problems), you don't mention compression, you don't do anything about removed messages, you don't track messages from a previous conversation with the same key inserted in this conversation, you don't define how temporary your temporary key is.

Fourth, you are using public key crypto, which is slow.

Fifth, you have no threat model. Your post originally had no definition of what you're actually trying to achieve (though you've added that in a comment).

And since I'm not really a crypto expert and see all these flaws at a glance, imagine how many flaws there really are that experts would see.

Please don't create a new, flawed protocol. Use one that already exists for what you want.

atk
  • 2,156
  • 14
  • 15
  • I'm only using existing algorithms, but trying to use them in a more secure way. For the third issue, all of those were implied. I know how to implement compression and etc. Also the fifth issue is I'm trying to prevent the NSA from forcing me to hand over my keys to the data, so the goal is for even me not to be able to access it. – Phoenix Logan Nov 11 '13 at 13:53
  • 5
    @PhoenixLogan although you are using standard algorithms, you are talking about creating your own protocol. This is also a bad idea, for all the reasons atk outlines – paj28 Nov 11 '13 at 14:29
  • @PhoenixLogan Encrypt (securely!) on the client-side with a key which is generated (securely!) on the machine of the user and never leaves it. Then the users don't have to trust you or their ISP, because without their key, their data is useless to anyone. – Philipp Nov 11 '13 at 14:46
  • The problem is authenticating the user to prevent people randomly uploading files, corrupting them, or deleting them. I just posted a new question here: http://security.stackexchange.com/questions/45277/is-it-possible-to-digitally-sign-information-with-a-password – Phoenix Logan Nov 11 '13 at 14:49
  • @PhoenixLogan: corrected last sentence. As paj28 says, creating your own protocol is a bad idea. You're trying to use existing algorithms in a "more secure" way, but you are in fact using them in a *less* secure way. – atk Nov 11 '13 at 14:58
  • @PhoenixLogan: Implied means you want the reader to read your mind. I haven't learned telepathy yet. Now that you've decided to use compression, if you decide to incorporate symmetric key crypto, to you have to consider preventign the BREACH/CRIME/BEAST style attack. – atk Nov 11 '13 at 15:00