March 17th, 2013, 11:41 PM
What will be the best way if a key-exchange server is either not available or down?
Originally Posted by mah$us
Yea....that's one of the things that I am starting to realize now too.
And I'm still trying to get my head wrapped around the difference between say the dgst function in openssl vs. the passwd function vs. RSA.
Somewhat surprisingly, the ciphers are not too difficult to understand. But like you said - the key is really the million-dollar question.
And I'm also still trying to get my head wrapped around all the different methods so that it can be consistent.
Would it be better to send the key (securely, of course) or let the receiver calculate what the key is or should be based on whatever the input that the sender used?
I've heard/read that that's how passwords (to websites for example) work - in that you create it, it hashes it, and stores the hash. Then when you log in, it hashes it again and compare it against the stored hash.
What happens if that stored hash isn't available or that storage (function/step - if you will) isn't done at all? So somehow, you still need to be able to figure out whether it's the correct one or not based on the end result hash, but you have to get the hash right.
And if a key-server goes down, does that mean that you're hosed or is there a way to be able to recreate the keys if you know the necessary pieces of information that was used to create said keys in the first place?
March 18th, 2013, 01:46 AM
How would the receiver calculate what the key is? What would prevent an attacker from performing the same calculations? This is not a rhetorical question; for example, you could share a database of pre-generated keys via an offline method and then in your message you could transmit an ID for the key rather than the key itself. The receiver would then use the pre-shared database to look up the appropriate key. The fact that the database is required to look up the key is what prevents an attacker from performing the same calculations.
How could the key be based on the input that the sender used (assuming you mean the encrypted message?) The receiver would have to already know the message in order to decrypt it...
The first part of this is correct.
The second part I don't understand what you're saying. Why wouldn't the stored hash be available? If the database crashes and you lose the hashed passwords then it is impossible to authenticate the users. If the database is temporarily down, then again, it's impossible to authenticate the users. If you don't perform the hashing step for some reason (?) when authenticating the user, then authentication will fail.
If you know the information needed to create the keys then you can recreate the keys.
March 18th, 2013, 02:07 AM
If I'm only dealing with say one user and ONE file that's encrypted, do I still need the database to facilitate the database lookup? And if so, wouldn't that database only have one entry in it?
Originally Posted by E-Oreo
Neither the encrypting nor the decrypting system have a network connection. The only way that files go into and out of those systems is by physical means only.
Or put the question in another way - there are two users. One encrypting, one decrypting. Neither has network access so all transfers (encrypted or not) must be transferred via physical means.
So given that, and there's only ONE user at each end - what would be the best way for handling/dealing with encrypting/decrypting a single file? (including key management and exchange)
Maybe I'm going about this entirely the wrong way. I always thought that the limiting factor was that they had to perform the key calculations that's what makes it attacker-resistant.
But if you only have one entry in the database, then wouldn't that make the calculation really a LOT simpler than if you had a whole bunch of them or do I have this wrong too (because if you have a whole bunch of them, the probability of you hitting ONE of them is higher than if you just had one or two)? I'm so confused.
And so I always thought that it would be better/safer to NOT transmit the key, but rather than the receiver figure out what the key is based on the process that I used to get it. How would that be attacker-resistant? Well, they'd have to know what my process is. And at this stage in the game, even *I* don't really know what my process is.
(Which is sort of what I am trying to figure out).
See when someone logs onto a system and the system does the hashing of the entered password against the known password hash - they're still connected to that one system that's responsible for that. Which means that the hashing process is confined to that system. Here, because there is no network connection between the two systems; and therefore, no communication between them; the decrypting system has to be able to do what the encrypting system is doing.
And even if it was a pre-shared database, doesn't that still mean that the hashing process between the two systems with the shared database would have to be the same in order for the rehashing-and-lookup for it to work properly? (Or am I misunderstanding that too?)
So if say I have server A in city A with password hash database H; and then another server B in city B with the same password hash table H.
userID 1 attempts to log into server A with his password and server A rehashes the entry and checks it against the table H. If it checks out, he logs in.
now, userID 1 travels to city B and attempts to log into server B. Since server B cannot look up server A (no connection) and therefore; it has to replicate the hashing process that server A uses, if either the password or the hashing process is wrong, then userID 1 cannot log in.
Now that I assume that user ID 1 on server B in city B will ALWAYS get the password correct. Without connecting to server A, how can server B authenticate the user?
There's GOT to be a way, some way for server B to do the same thing as server A, exactly the same way, right?
Or put yet another way - how can you ensure that two disconnected systems/servers/computers can authenticate a user in exactly the same, consistent manner? The SYSTEMS must be able to run independent of each other, but the authentication must be the same (so that data carried from one server can be taken to another (physically) and still work).
March 18th, 2013, 09:54 AM
If this is the extent of your security problem then you're making this far more complicated than it needs to be. The two people just need to meet in person, agree on a passphrase, and use that passphrase for key generation in the normal fashion.
March 18th, 2013, 05:34 PM
That would be true except we're 1000 miles apart. And I'm already booked up through December of this year and oh look, it's only March.
Originally Posted by E-Oreo
March 18th, 2013, 09:42 PM
Have them generate an RSA keypair and send you the public key. Encrypt your AES key using their public key and send it back. They can decrypt the AES key using their RSA private key.
This is vulnerable to a man-in-the-middle attack unless you can verify in some external way that they are the owner of the public key that you receive. Depending on who your adversary is, this may or may not be a concern.
Or just call them.
March 18th, 2013, 10:03 PM
Hmmm...that could work.
Originally Posted by E-Oreo
(wiki RSA....) [starts reading...]
What would happen if he were to keep the public key, but I get the private key instead? Would that be better and offer better protection against a MITM attack?
March 19th, 2013, 12:15 AM
It would not be better and would not protect against a MITM attack.
An RSA keypair consists of two keys, each of which can decrypt messages encrypted by the other key. A key cannot decrypt its own messages.
However, by convention, most encryption libraries generate private key files that include BOTH keys, while the public key file only includes one of the keys. Thus if he sends you the private key file, it totally defeats the purpose of using RSA encryption - you may as well just send the AES key in plaintext. If he sends you just one of the keys, then, by definition, he has sent you the public key regardless of which key he sends.
(TBH, if it were more secure for him to send you the private key I would have told you to do it that way in the first place)
March 19th, 2013, 04:58 AM
The safest course to follow -- especially for someone lacking a deep understanding of the underlying techniques -- is to use the Good Stuff that is already out there.
For example, gpg, which is as good as can be found, and available free of charge.
You and your remote correspondent can put your public keys on a server established for that purpose (for example, that run by MIT), also free of charge.
To the extent that (a) you trust that someone hasn't hacked the public key server to give different results depending on who is looking, and (b) you trust that there isn't some man-in-the-middle who can intercept and modify your connection to that server, this is a safe procedure. By the way, you can check each other's public keys on the server from several different computers using different internet connections, as a way to improve confidence in (b) if needed.
A tyro is making a huge mistake, worrying about whether AES is strong enough. If the secrets are compromised, it is a billion times more likely that somebody hacked a computer and keylogged your passphrase (or exploited some other weak link), than that they broke AES.
If you don't know this, DES is now more than 30 years old, and has still never been broken. Yes, DES can be cracked by exhaustive search because the keys are short, but AES keys are so much longer that it is very unlikely that they can be cracked during the lifetime of anyone living today -- even with expected advances in computing power, or if the mythical quantum computer becomes a reality, AES-256 will remain impregnable for many decades. Of course, it could have some yet unknown weakness -- but it is based on a generation of additional knowledge beyond DES, which remains unbroken.
So use the good tools that are already out there, carefully checked, vetted, tested, and debugged. You won't find better security than that.
March 24th, 2013, 11:20 PM
Thanks to all of your feedback.
Originally Posted by mah$us
I was reviewing the information with my friend and we haven't quite decided what we're going to do yet.
The use of the RSA is only to encrypt the AES key correct?
Would that mean that I would need openssl to tell me the key that was used?
We're trying to minimize the electronic transfer (so that if someone wanted to do a MITM attack, they'd basically would have to pull a heist and hijack the transporting vehicle).
March 25th, 2013, 06:13 AM
Yes, the typical use of RSA is to send the key for a symmetric cipher, such as AES.
In fact, it's possible to use RSA for all the data, block-by-block, but this isn't usually done because RSA takes a lot of time to compute, whereas block ciphers are designed to be efficient with computation time.
However you apply RSA, be aware that secrecy can be badly compromised by using it without certain precautions. It is very highly recommended to use a "padding scheme" -- basically, some bits are added to the plaintext, and then removed at the other end after decryption.
I don't have any experience with openSSL, but I see from google that its RSA encryption function can be passed the parameter RSA_PKCS1_OAEP_PADDING, to select the most recommended form of RSA padding.
As an alternative to one side coming up with an AES key and sending it, you could use the Diffie-Hellman protocol, in which neither side knows the key at the outset -- rather, the key is created as a product of the negotiation between the two parties. Both parties use randomly chosen numbers (the randomness must be of cryptographic strength, of course), ensuring that the DH key is unpredictable. openSSL has DH support as well.
Either way, each of you needs to safely communicate a public key to the other (for example, using that MIT server) to protect against forgery. But once you've done that, you can use RSA or DH to communicate keys.
Security-conscious systems don't use symmetric cipher keys (like AES keys) for long. Instead, new keys are generated frequently. For example, a new key might be used for every establishment of a network connection. Or if the connection is long-lasting, keys might be renewed at regular time intervals.
But the PKC keys (RSA/DH/DSA) are safe to reuse for years, provided that the keylength is reasonable (I suggest at least 2048 bits, and if you can afford some extra time, go for 4096).
If you'll be communicating between computer applications, openSSL is great. But if the process will be more manual (that is, you and the other party will work at your consoles), I highly recommend gpg. With openSSL, there are a lot of decisions you might need to make in using it, where a mistake could harm security. gpg will, for the most part, automatically do the safest thing.