Might be an unqualified question, but are there any encryption systems where two encryption keys are generated (one public, one private), and...
A) The public key is used for encrypting the information, but cannot be used to decrypt it
B) The private key is used for decrypting the information, and cannot be used to encrypt it.
I am asking because I see this as the only practical way to secure a login session to a web service (such as a forum) without the use of SSL/HTTPS. Though, with my limited knowledge of system security and cryptography, it's more than likely that I'm wrong.
The most common private key encryption algorithm is RSA. However, if you don't know what you're doing, stick to higher level constructs such as SSL/TLS.
Related
I am considering building an API system that uses HMAC. The server and client will have a shared secret, the client will sign the requests, the server will validate, and proceed if all is well. The trouble with this sort of system is that the secret has to be stored in a way where it can be retrieved, such as a database. If someone were to steal the secret, they have the key needed to do basically anything that user is authorized to do.
I was thinking that there must be a more secure alternative. Are there any flaws with using RSA?
Client has the "public" key instead of a shared secret. (The public key must still be kept secret for my use case.)
Client will hash the message with SHA-1 or whatever as normal.
Instead of adding the hash to the message directly, the hash will be encrypted via it's public key, and then sent with the message.
Server has the "private" key (to decrypt messages) but has no knowledge of the "public" key. (This is the part that makes this more secure than the normal approach. If the database is stolen, no keys are stolen that can impersonate a user.)
Server will decrypt the hash and validate the message as normal.
Is there anything wrong with this approach? Are there known implementations of this or something similar?
It depends on the asymmetric cryptosystem you chose:
(EC)Diffie-Hellman: It does not work. Publickey is directly derived from the privatekey via the generator, e.g. [d]G = Q
RSA: Usually people chose fixed publickeys like 0x010001. This is done for efficiency reasons. If you take a large enough, fully random e and derive d from it there is no possibility to calculate p and q given d and N OR e and N. Actually they are pretty equally then and the label private and public don't make much sense anymore. All that relies on a smmyetrical property of RSA. Be sure not to walk into textbook RSA issues. And be sure to ask enough clever people about it, this is just my thoughts on it.
If you base your crypto system on a proof of possession of a secret you need to, well - keep it secret :)
But yes, if you dont need the speed of a symmetric authentication then you can use a assymetric signature. Typically it is done with a signed hash, but you can also use a signed hmac.
The terminology is normally, that you sign with a secret key and validate with the public key (even when the signing operation looks like an encryption).
I know that using an asymmetric algorithm is a very easy way to authenticate peers on a serverless network. I have a project where the networked clients only have symmetrical primitives. They have less than 1Mbyte code space and less than 100DMips, so running RSA in software would take too long.
If there is a server, this is not a hard problem. The client asks for authentication, the server sends a random number, the client does a HASH with secret (shared) key, and passes the result back to the server. Only a client with the secret would produce the answer the server is looking for, so the server is satisfied this is an authenticated client.
Here is the problem: what if all the devices on the network are peers, with none of them trusted more than others? Is it even possible to talk about general network-wide authentication without public key cryptography?
IF I could use RSA, then each node would have all the public keys of all the other nodes. Problem solved.
The only thing I can think of so far is to have each node store a public hash of each nodes private key. Then a series of secure transformations (http://en.wikipedia.org/wiki/Secure_multi-party_computation) are done to the hash in such a way that the other client can recover the transformations only if the hashed key belongs to them. Returning the transformations (without the secret) proves the node really is the one that owns that hash. Has anyone seen papers about this?
I suspect this is even more computationally expensive than just using RSA, but it is an interesting problem.
I have looked for other articles about this, but have not found much:
Authenticate without using a server
In addition to recommending not doing client-side authentication, this article suggests to make it good enough. That is not enough for me. I want something this is provably secure, like RSA, just without asymmetric components.
Here is the same problem: Decentralised user authentication -- possible?
but the answer is to use public-key authentication.
I just found a possible answer-- pre-shared keys:
http://en.wikipedia.org/wiki/TLS-PSK
I am afraid this means that one compromised device will compromise the entire network, but I have not dug in very far yet. More research to do.
Any other ideas you have come across?
I was arguing about an S3 like aproach using authorization hash with a secret key as the seed and some data on the request as the message signed with hmac sha1 (Amazon S3 way) vs an other developer supporting symetric encryption of the data with a secret key known by the emiter and the server.
What are the advantage of using signed data with hmac sha1 vs symetric key other than the fact that with the former, we do not need to encrypt the username or password.
What would be the hardest to break ? symetric encryption or sha1 hashing at la S3 ?
If all big players are using oauth and similar without symetric key it is sure that there are obvious advantages, what are those ?
An hmac and a symmetric cipher are not mutually exclusive ideas. In fact AES-CMAC which is both an MAC (not hashed) and a symmetric cipher, AES-CMAC is the cryptographic primitive that makes WPA secure. (Although a WPA can still be broken using a rainbow table).
You should not need an exotic authentication system for this. Logging in with a username and password and maintaining session state with a cookie is commonly used because it is easy to implement and it is secure. By storing state, like a cookie its no longer technically RESTful, but there is nothing stopping you from doing it.
However, in terms of authentication I believe that asymmetric cryptography like RSA is the most secure. (Amazon uses asymmetric cryptography for ssh connections by default.) This allows you to only store the public keys, so that if your server where to be compromised no authentication credentials could be used. It also defends against MITM attacks. In many cases this can be implanted quite easily with REST because HTTPS already supports client certificates. You can sign the clients certificates for free and then verify them your self.
If implemented properly, the strength of an hmac vs symmetric cipher it mostly comes down to the strength of the secret. If you are using a secret like a password, then both systems are equally very weak. These secretes must be large, Cryptographically Secure Psudorandom Numbers. Another thing to keep in mind is that symmetric ciphers are very difficult to implement properly. Most programmers do not understand this and end up reusing PRNG when using stream cipher or when using a block cipher they use an incorrect mode and leave the IV null. By contrast HMACS are very easy to implement and less can go wrong. If everything is transmitted over HTTPS, and your are using an hmac then its easy to implement a secure authentication system. If you really want to implement a symmetric cipher you must get a copy of Piratical Cryptography, there are a few chapters devoted to symmetric ciphers alone because so much can go horribly wrong. You also have to take key distribution into consideration, ssl uses a DH-Key Exchange for its symmetric keys.
Make sure to read the OWASP top 10, especially Broken Authentication and Session Management. This requires the use of https for the entire session, most web application programmers don't realize this.
The big differences would be that HMAC would provide integrity but no privacy, while encryption would provide privacy without integrity. Many use cases would require both, but I can't think of any where integrity is unnecessary. HMAC seems like a minimum requirement, with encryption being a likely companion.
I'm not a cryptography expert, I actually only have a little bit of experience using it at all. Anyways, the time has come where one of my applications demands that I have some encryption set up. Please note, the program won't be managing anything super critical that will be able to cause a lot of damage.
Anyways, I was just trying to see if this scheme that I'm using is common and if there are flaws (of which there may be completely stupid & horribly flawed design, that's why I'm asking).
Ok, I have a client -> server communication. The Client I can hard code in the public portion of a 2048-bit RSA key. When the client wants to initiate a secure connection, he sends his username, md5 hash of his password, and a hash of a random UUID, all of which has been encrypted against the server's Public Key. The server receives the information and decrypts using its private key. Checks the database to see if his login + pass work & if they do, create a new entry in the "Sessions" table in the DB. This includes a SessionID, UID (user ID), and the UUID hash. Using the corresponding session ID's UUID as the keyphrase, the server will then send back a message that has the Blowfish encrypted word "Success!" + a random UUID (this message is Digitally Signed so we can determine if it came from the server or not). From that point on, when the client sends info to the server, it will be with a plaintext sess_id & include a Blowfish encrypted message, using the corresponding Session ID's blowfish secret (stored encrypted in the DB) as the key to encrypt / decrypt.
Specifically, I am curious as to whether this system "should work" or if anyone notices that it's glaringly obvious that a vulnerability exists, such as MITM.
Issues I can see off the top of my head (although you have left out most of the details, which is where the devil famously resides):
If you're using a UUID generator rather than a real cryptographic RNG, it likely has insufficient entropy. Don't discount this - in the real world, the favourite way of covertly weakening an encryption system has been to weaken the RNG;
Your initial RSA encryption sounds like it is susceptible to a small-exponent attack, and potentially other creative attacks. There's too much structure there to be comfortable;
It sounds like there's numerous opportunities for replay attacks;
What block cipher mode are you using with Blowfish?
I recommend using TLS/SSL - it's had a lot more friendly eyes looking at it for a lot longer than anything you build yourself ever will.
Just use SSL or DTLS, IKEv2, HIP, EAP or some suitable standard protocol. Don't try to invent your own crypto protocols, nobody has enough expertise to do this on their own. Your protocol doesn't have nearly enough entropy in it, so far as I can see, so your resulting keys will be pretty weak.
From that point on, when the client sends info to the server, it will be with a plaintext sess_id & include a Blowfish encrypted message, using the corresponding Session ID as the key to encrypt / decrypt.
If you're sending the session id in plaintext, and using it as the encryption key, how is that secure?
I see no reason why you can't use standard SSL authentication and let the library implementer worry about the handshaking.
If we consider Man In the Middle Attack;
Can such an attack occur if symmetric keys are used?
Sure. All you need to do is intercept the key exchange. Then you can pass on your own (fake) key to the other end. You intercept the messages using the key you obtained fraudulently and re-encrypt with your fake key and pass on to the other end.
The trick is to agree on the symmetric key in the first place.
Man-in-the-middle attacks usually occur during the key exchange phase (making you agree on the key with the middle-man instead of your real partner).
So what usually happens (in web browsers' SSL sessions) is that you use asymmetric cryptography to exchange the symmetric key. However, that depends on your partner's public key really belonging to who you think it does. Usually, you take Verisign's or (some other CA's) word for that.
At some point, a secure and authenticated key exchange has to have taken place.
Since the MIM attack can happen during the key exhange, you could do what SSL/TLS does.
SSL/TLS uses RSA in the key exchange, so that the exchange of the symmetric key is [heavily] protected with RSA.
Above answers correct of course, but you should note that there are several efficient, cryptographically secure methods for securely exchanging keys. I think the one wow uses is SRP6.
Yup. Even if you use symmetric key you have to use authentication/integrity checks. Using symmetric key encryption without authentication/integrity checks makes you susceptible to various forms of replay attacks or substitution attacks. An attacker can modify your ciphertexts and may even know what the effect of his changes are.