I want to be able to store some data on disk after being downloaded from a server that will be fairly resistant to hacking!
What I was going to do was encrypt the data with a private key on the server and decrypt it with the public key in the client, but the data is going to be arbitrary length and will be larger then a RSA private key.
My thinking was doing it this way would mean that if a hacker managed to decompile the code and get the encryption key they would be able to decrypt it but they wouldn't actually be able to modify the data as they would still need to the private key to encrypt it again after modification for the client to load!
So i thought of a combination of asymmetric encryption with symmetric encryption to store the data. So a symmetric encryption key would be asymmetrically encoded by the server and stored along side the symmetrically encrypted data then the client would decrypt the symmetric encryption key with its public key then decrypt the data!
But then I realised a hacker would just need to decompile the code, get the public key, decrypt the symmetric decryption key, decrypt the data, modify it then re-encrypt with the symmetric decryption key and he has hacked the system.
My question is does anyone have a suggestion in how I could go about storing this data on the client without it being hackable without knowing the private key! The data needs to be decrypt-able offline without any connection to a server required! So this rules out getting the data/keys from the server all the time!
There is no secure way to store data on the client. When data is on the client, a dedicated mind has all the tools and all the time in the universe to crack the best encryption that you can come up with.
There are two solutions:
Trust your client.
Stream the data.
Comments: If your client is also your enemy, then there is no way you can make business with them. The movie industry learned this, the music industry learned this, the book industry is learning it and the games industry is following. These people spent billions in clever DRM technologies and they all failed.
You want the customer's money? Then treat them accordingly.
Streaming is about the only workaround that balances trust and security. Streaming means that at any time, only a small fraction of the data is on the client at any time and combining the fragments into a whole data set is complex.
Related
I have searched for HOURS on how this works and I just can't get how this can be. The only given definitions are that public keyed encrypted message can only be decrypted by private key. To me, that's just nonsense and I will explain.
A website needs to be downloaded by your browser which also means that Javascript scripts and all the other stuff are accessible to anyone that catches your website if he wishes too. This also means that now, this person knows how you calculate your stuff with your public key making it possible WITHOUT the private key to decrypt it.
I'm just trying to figure out how this works and to me it does not make sens that you CANNOT decrypt an ecrypted text from a public key when you have access to all the calculations made from the side it encrypted.
I mean, when you send a password for example, first, on YOUR end, the browser's end, it encrypts the data to be recieved by the server. By encrypting the data from the browser's end, anyone that took a look on your source code can know how you encrypted it which now can be used to decrypt it. I am creating a new encryption system for our website where the server randomly creates a session key that can only be used by the user with the corresponding session. So only the 2 computers can talk to each other with the same key so if you use the same key on another computer, it just won't work as each key is stored for each session which the key dies after a set amount of time. With what I read, this seams to be called a symetric key system. I want to try and program my own assymetric key system but in all cases when I read, I can only figure out that no matter what happens as an encryption on the client's side, if a malicious person intercepts just before sending the information, he has access to how the encryption worked and therefor, does not need the private key on the server side as he just needs to reverse the process knowing how it was done on the client's side.
I'm starting to think myself as stupid thinking that way.
I'll add a little more information as I think we don't quite catch what I mean. When sending a password, say my name "David" and let's name our user WebUser. We will name our maleficient user BadGuy. So BadGuy hapopens to integrate himself in between WebUser and his browser. BadGuy also recieves ALL javascripts of the webpage permitting him to see how the calculations work before it is sent. WebUser enters his password "David" which is submitted to the javascript encryption system. Right off the bat, BadGuy does not need to decrypot anything as he already caught the password. BUT when the website responds, BadGuy has all the calculations and can use the receieved encrypted data and decrypt it using the decryption calculations he can see in the recieved web pages code.
So the only thing I can understand is that Assymetric keys are used for encryption which technically is decryptable using public known numbers. But in cas of RSA, these 2 numbers are so large that it would take years to figure out the known decryptor. As I can also undersnat is that it is pretty much easier to create the 2 numbers from the private number. But in any case, the encryption process usually ends up with a shared temporary intimate key between the two parties for for faster commuinication and that noone can ever prevent a BagGuy between User and Browser but with todays technocolgies, the real threat is more MiTM attacks where one will sniff the network. In all cases, there is no definate way to communicate 100% of the data in a undecryptable way as at least 50% of it is decryptable i/e data coming from one side or data going to the other side.
Assymetric encryption has two keys, a public and a private key, as you correctly described, so don't feel stupid. Both keys can be used for encryption and decryption, however, if data encrypted by the public key can only be decrypted by the private key and data encrypted by the private key can only be decrypted by the public key.
As a result, in order to be successfully involved in a communication using assymetric encryption you will need to have both a public and a private key.
You share your public key with others, that is, whatever data you receive, it will be encrypted with the public key. You will subsequently be able to decrypt it using your private key, which is your secret. When you send data to the other side of the communication, you encrypt it using your private key and the other side, which has your public key will be able to decrypt it.
Consider the example of versioning. You are involved in a project with some team members. When you pull the commits of others, it is encrypted with your public key, so once it is downloaded at your end, you will be able to decrypt it via your private key. As you work and do your commits, you will push the changes into the repository, encrypted using your private key. The other side of the communication already has your public key and will be able to decrypt it. It is important that you do not share your private key with anyone, so your team-mates will not be able to impersonate you, committing malicious code in your name. You can share your public key with anyone, but it is recommended to share it only with trusted people, like your team-mates, so no one else will be able to decrypt anything encrypted by your private key.
Essentially your public key is a ridiculously large number, which is the result by multiplying two primes (private key). The two primes could be found out by prime factorization, but since the public key is a very very large number, doing the prime factorization would take such a looong time that no one will sit and wait for the time (centuries) while the factorization is being executed and the results are found out.
A session id is a value which identifies a session. If there is a single such value, then it is not an assymetric encryption, as there is no public and private key involved and once someone steals the session ID, as you correctly pointed out, the malicious third person/system can impersonate the actual user and do nasty things. So the problem you have identified actually exists, but this is not a new problem and solutions were implemented. The solution you are looking for is HTTPS. Once your site gets a proper certificate, you will be able to use assymetric encryption safe and sound. Under the hood the server will have the public key of the user's session, while the user will use the private key to encrypt/decrypt and if a middle man intercepts the public key of the session (which is not a session id), the malicious third person will not be able to impersonate the actual user. Read more here:
https://en.wikipedia.org/wiki/Transport_Layer_Security
extending the previous answer
I'm just wandering how an attacker positionned between the user and his browser cannot intercept the connection details when they are clear texte to beggin with and to end with.
The magic here is called DH key exchange.
The symmetric encryption key is derived using Diffie–Hellman key exchange, where the common encryption key is exchanged.
Any "listening" party (your BadGuy) woudn't be able to derive the session key even by sniffing out the whole communications. The server will use its certificate and private key to make sure the client communicates with the legitimate target. This prevents an active "man in the middle" to pose as a false server.
it does not make sens that you CANNOT decrypt an ecrypted text from a public key when you have access to all the calculations made from the side it encrypted.
Asymmetric cryptography is based on so called "trapdoor" funtions. It means it is easy to calculate the function one way (e.g. encrypt data), but very difficult (not feasible) to od it opposite way without some secret value (private key). Indeed sometimes it is difficult to understand it and there are a lot of constraints under the asymmetric encryption is really secure. That's why you would always use some trusted library than do it yourself.
By encrypting the data from the browser's end, anyone that took a look on your source code can know how you encrypted it which now can be used to decrypt it.
Not without the random secret key, which is derived between the client and server during the key exchange (see the first paragraph).
I am creating a new encryption system for our website where the server randomly creates a session key that can only be used by the user with the corresponding session.
It's one of the rules in the field of cryptography - do not design your own crypto!
That's usually a bad idea. Please note the currently used secure channels (SSL, TLS, .. based on RSA, ECC) are designed, reviewed and used by a lot of smart people who know what they are doing, how to mitigate different attack vectors. And IMHO it is still not perfect, but it's the best we have.
I'm going to re-phrase my question completely so it makes more general sense (and correct my blunder with AES/RSA).
Alice has a large block of data to send to Bob via a local mailbox that isn't secure. To keep her data from prying eyes, she does this:
She generates a random 256-bit key
She uses AES-256 encryption to encrypt the data using the key
She uses Bob's public key to encrypt the key she's used
She puts the encrypted data and the encrypted key in the mailbox addressed to Bob
Mike the mailman picks up the mail from the mailbox. However, he doesn't want to lug the data all the way across the internet to Bob's place if bob isn't going to be able to decrypt it.
The question is, how can Mike ascertain whether the key has actually been encrypted using Bob's public key?
In my application I need to transport sensitive data to a data centre. To achieve this, I have an upload process that accepts files (that have already been AES-encrypted with a key, then the key is encrypted with the recipient's public key) and sends them to the data centre. The corresponding private key is held at the data centre and used to decrypt the files on receipt. This is currently in the design stage so there is some flexibility on the public/private key technology to be used but it's likely to be a C# application that's doing the work.
I would like to protect against uploading files that have NOT been encrypted using the public key (because I may waste significant bandwidth and the receiving application at the datacentre will fail to decrypt them).
So, what I want to know is how can I tell at the sending end whether a file has been encrypted using a given public key?
In a nutshell, I have an encrypted file and a public key. Has the file been encrypted with that key?
Thanks in advance etc.!
I want to create an application, where multiple people should be able to communicate with each other securely (think of a decentral group chat) - sounds easy, but here is my problem:
As far as I understood, with asymmetrical encryption you have a public key and a private key. Everyone who wants to send a message to someone has to encrypt it with the public key and the recipient can decrypt it with the private key.
But if there are more than two people that should be able to read all messages, I don´t know how this should work...
Either everyone has the public and the private key - which I think is a bad idea - or everyone has to have everybodys public key and has to send a seperate message to each recipient.
Also, I want to make a 100% sure, that the one who sends a message really is who he pretends to be. (so nobody is able to "fake" messages)
Is there an encryption algorithm that solves my problem?
Controlling the extend of the recipient group
In a comment to Richard Schwartz' good answer, you ask
Is it possible with this algorithm to ensure that only one is able to invite others? As far as I understood, everybody could distribute the decrypted session key.
When applying the protocol in a group chat scenario, don't let the term "session key" mislead you. Rather, think of the key for symmetric encryption as a "message key": Each time someone sends a message to the group, they should generate a new random symmetric key, encrypt it with every legit receiver's public key separately and prepend all these cryptograms to the symmetrically encrypted message. This way, each sender decides independently whom they consider a part of the legit recipients group of their own sent messages.
This will give the protocol some more transmission overhead, but this probably won't matter in practice. What could matter is the 'cost' of getting larger amounts of 'good' randomness (entropy) to generate sufficiently unpredictable message keys. So an acceptable optimization might be that, if the group of legit recipients has remained the same, a sender might re-use the session key of their own previously sent message. Never though should they re-purpose a sessions key received from another group member for sending messages of their own.
Off course, even if each sender decides independently whom they consider a legit recipient of their message, you can't keep any legit recipient from compromising messages they received: They can simply forward the messages unencrypted (or encrypted for someone not in the original recipient group) to whomever they want.
Ensuring authenticity
In an edit to your original question, you added
Also, I want to make a 100% sure, that the one who sends a message really is who he pretends to be. (so nobody is able to "fake" messages)
Encryption can't do that, but cryptography has another way to make sure that
the message actually comes from whom claimed to have sent it
the message hasn't been tampered with since
And the way of ensuring these things is signatures, which also are something that public-private-key cryptography enables. Let senders sign their messages with their private key. (Which usually means 'encrypting' a cryptographically secure hash of the message with the private key.) And let receivers verify the signatures (by 'decrypting' the signature with the sender's public key and comparing the result with a hash of the message they computed themselves.)
Don't roll your own anything (except when you should)
Richard's answers advices you to not roll your own (pseudo) random number generator. For anything you plan to use in production, I'd extend this to anything encryption:
Don't invent your own protocols
Don't invent your own cyphers, signatures or hash functions
Don't invent your own way of gathering entropy
Don't roll your own implementations of any of the above, even if invented by others
Instead, use well-established cryptography libraries. These are written and reviewed by experts in both cryptographic theory and in the practices of writing secure software. And while even these libraries are often enough found to have (sometimes embarrassing) security issues, nothing you'll come up with yourself will be nearly as secure as them.
Though, for learning, implementing any or all of the listed stuff (including pseudo random number generators) is great exercise and helps you understand at least some aspects of the underlying cryptography. And this understanding is important, as it's often difficult enough to correctly and securely use the well-established libraries, even when you do have some knowledge of the concepts they reveal through their interfaces.
And of course for innovating within cryptography, inventing new stuff (and getting it scrutinizingly reviewed by the community of experts in the field) is necessary, too. That new stuff just shouldn't be used for anything serious before it has passed that review successfully.
I assume you mean asymmetric encryption, not asynchronous encryption.
In most cases, we don't actually use an asymmetric cipher to encrypt the content of messages. That's because messages can be large, and asymmetric ciphers are slow in comparison to symmetric ciphers. It's also because of the issue you are contending with here: in a multi-party commmunicaiton, you'd like to be able to just send the message once and have everybody be able to read it. So the trick is that we combine asymmetric and symmetric techniques into a protocol that solves the problem.
First, we generate a random symmetric key which we can call the "session key". We're going to distribute this session key to all recipients, but we need to do this securely. Here's where we're actually going to use asymmetric encryption. We encrypt the session key once for each recipient using each of their public keys and an asymmetric cipher (such as RSA), and we send the encrypted session key to each recipeint. We can send it to each recipient separately, or we can just build a structure that looks like this:
"recip1|recip1EncryptedSessionKey|recip2|recip2EncryptesSessionKey..."
and send the whole thing out to all recipients, each of whom will be able to parse it and decrypt their own encrypted copy of the session key. (This is generally how it's done in encrypted email: the list of all encrypted versions of the session key for all recipients is enclosed with the message, and everyone gets the exact same email.)
Once we've securely distributed the session key to all recipients, we can use the session key to encrypt each message just once with a symmetric cipher (such as AES), and send the same encrypted message to all recipients. Since they all have received a copy of the session key, they can all read it and act on it.
Note that as in all things having to do with encryption, it is crucial that the session key is really random. Don't just rely on a plain vanilla random number generator for it, and for heavens sake don't roll your own. Make sure that you use a cryptographically secure pseudorandom number generator.
A real chat system would likely be quite a bit more complicated, probably with a mechanism for re-establishing a new session key periodically, and the details of a secure protocol can be quite intricate. I.e., consider how you would protect against a bad-guy stepping in and fooling everyone into using a session key of his choosing! But the basics are as above.
We're designing a database system to store encrypted strings of information, with encryption and decryption performed client side using public-key cryptography.
If the key was ever changed though, this would necessitate reencrypting all the records client side, which is very impractical.
Is there any way this could be performed server side without exposing either the original (old) decryption key, or the message text?
I guess what I'm after is an associative cipher, something like this:
T( Eo(m) ) = En( Do(Eo(m) ))
where Eo(m) is the cipher text, Eo/Do the old pub/priv key pair, En the new pub key, m the message text and T the magical reencryption function.
Edit: T is calculated clientside and then sent to the server to be used.
You can't retroactively disable the old key anyway. Anyone who has access to the old data and the old key can decrypt the data no matter what you do.
I would suggest simply keeping a ring of keys. Add the new key to the ring and mark it active. Mark the old key expired. Code the client so that if it finds any data that's encrypted with an expired key, it re-encrypts it with the active key. (Or don't. What's needed depends on details of your implementation requirements.)
If desired, after a period of time, you can sweep for any data still encrypted with the old key and re-encrypt it.
You can't eliminate the exposure of the old key anyway, ever -- anyone who can find a backup or copy of data encrypted with the old key can decrypt it if they have the old key. Encryption keys must be protected forever or you get the fiasco that released the Wikileaks diplomatic cables to the public with the names of informants intact.
Think about your security perimeters. If you're worried about the server being compromised, consider building a harder-to-break subsystem which carried out the transcryption. You could do this with a non-network-attached server which was contacted only over a very tightly verified link protocol (over, say, a serial line), or a dedicated hardware security module. However, if you do something like this, you must think about how your keys are protected; if an attacker could steal the transient plaintext from your server, could they also steal the keys protecting it?
A few years ago, when first being introduced to ASP.net and the .NET Framework, I built a very simple online file storage system.
This system used Rijndael encryption for storing the files encrypted on the server's hard drive, and an HttpHandler to decrypt and send those files to the client.
Being one of my first project with ASP.net and databases, not understanding much about how the whole thing works (as well as falling to the same trap described by Jeff Atwood on this subject), I decided to store freshly generated keys and IVs together with each file entry in the database.
To make things a bit clearer, encryption was only to protect files from direct access to the server, and keys were not generated by user-entered passwords.
My question is, assuming I don't want to keep one key for all files, how should I store encryption keys for best security? What is considered best practice? (i.e: On a different server, on a plain-text file, encrypted).
Also, what is the initialization vector used for in this type of encryption algorithm? Should it be constant in a system?
Keys should be protected and kept secret, simple as that. The implementation is not. Key Management Systems get sold for large amounts of money by trusted vendors because solving the problem is hard.
You certainly don't want to use the same key for each user, the more a key is used the "easier" it comes to break it, or at least have some information leaks. AES is a block cipher, it splits the data into blocks and feeds the results of the last block encryption into the next block. An initialization vector is the initial feed into the algorithm, because at the starting point there is nothing to start with. Using random IVs with the same key lowers the risk of information leaks - it should be different for every single piece of data encrypted.
How you store the keys depends on how your system is architected. I've just finished a KMS where the keys are kept away from the main system and functions to encrypt and decrypt are exposed via WCF. You send in plain text and get a reference to a key and the ciphered text back - that way the KMS is responsible for all cryptography in the system. This may be overkill in your case. If the user enters a password into your system then you could use that to generate a key pair. This keypair could then be used to encrypt a key store for that user - XML, SQL, whatever, and used to decrypt each key which is used to protect data.
Without knowing more about how your system is configured, or it's purpose it's hard to recommend anything other than "Keys must be protected, keys and IVs must not be reused."
There's a very good article on this one at http://web.archive.org/web/20121017062956/http://www.di-mgt.com.au/cryptoCreditcard.html which covers the both the IV and salting issues and the problems with ECB referred to above.
It still doesn't quite cover "where do I store the key", admittedly, but after reading and digesting it, it won't be a huge leap to a solution hopefully....
As a pretty good soltution, you could store your Key/IV pair in a table:
ID Key IV
skjsh-38798-1298-hjj FHDJK398720== HFkjdf87923==
When you save an encrypted value, save the ID and a random Salt value along with it.
Then, when you need to decrypt the value, lookup the key/iv pair using the id and the salt stored with the data.
You'd want to make sure you have a good security model around the key storage. If you went with SQL server, don't grant SELECT rights to the user that accesses the database from the application. You wouldn't want to give someone access to the whole table.
What if, you simply just generated a key for each user, then encrypted it with a "master key"? Then, make sure to have random ivs and as long as you keep the master key secret, no one should be able to make much use of any amount of keys. Of course, the encryption and decryption functions would have to be server-side, as well as the master key not being exposed at all, not even to the rest of the server. This would be a decent way to go about it, but obviously, there are some issues, namely, if you have stored your master key unsafely, well there goes your security. Of course, you could encrypt the master key, but then your just kicking the can down the road. Maybe, you could have an AES key, encrypted with a RSA key, and the RSA key is then secured by a secret passprase. This would mitigate the problem, as if you have a decent sized RSA key, you should be good, and then you could expose the encryption functions to the client (though still probably shouldn't) and since the key encryption uses a public key, you can have that taken. For added security, you could cycle the RSA key every few months or even weeks if need be. These are just a few ideas, and I know that it isn't bulletproof, but is more secure than just stuffing it in a sql database.