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?

  • 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. en.wikipedia.org/wiki/Forward_secrecy
    – paj28
    Nov 11, 2013 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? Nov 11, 2013 at 13:41
  • I'm going to ask this in a new question. Nov 11, 2013 at 14:00
  • 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 ;) ! Nov 11, 2013 at 18:34
  • 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, 2013 at 20:56

1 Answer 1


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.

  • 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. Nov 11, 2013 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, 2013 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, 2013 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: security.stackexchange.com/questions/45277/… Nov 11, 2013 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, 2013 at 14:58

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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