I am relatively new to Cryptography. From what I have read, it says that AES is symmetric. Hence there is no concept of Public and Private. So how is AES implemented to secure information transmitted over the web?
To try to explain, when a website uses SSL/TLS for transmitting encrypted data over the transport layer is first establishes the identity of the server (an/or client depending on the certificates used). Together, using Asymmetric crypto (for example RSA) the two sides (client and server) establish connection and using public and private keys, they figure out a symmetric key that they both can use for transmitting data for the remainder of the session. The actual symmetric key is never transmitted.
Once they have done that, they switch to using symmetric crypto (AES, RC4, etc) for the rest of the session using the key that they determined during the previous steps. Symmetric crypto is much, much faster then asymmetric, hence the reason for switching, but since they can't just pass a symmetric key back and forth the first step is needed to figure out what key to use.
This is a very simplistic explanation of the extremely complex tasks that are really going on, but since you said you're a beginner, I'll keep it simple.
Symmetric encryption (AES and others) are also commonly used strictly within the application (not for transmitting data) for storing encrypted data in a database or on a file system. So in that way AES (or others) can be used for website security.
AES Reference
NIST FIPS 197 doc
Related
I have a question about how to encrypt messages between users. Note i will only talk about cryptography theory and not platform dependent code like C++ with Windows Cryptography. I am talking about system programming and not web programming encryption with TLS, SSL, etc...
Also, ignore Certificates and Signing of messages, so just think of the Public keys as already being verified as not fraudulent and messages as being from the correct user.
I believe the best way to reach fast and secure encryption communication between users is to have both users with a session key because symmetric encryption is faster than asymmetric, and using asymmetric encryption (RSA) for the secure transfer of the session key.
I know there are other key agreement algorithms like Diffie-Hellmans, but lets stick with RSA which is what i've chosen.
Please tell me if you see where this might be a insecure (man-in-the-middle attack) or drastically inefficient way of performing encrypted communications.
Theory steps:
i.) Parties = {Server, Client}
ii.) Server: Generate session key (RC4)
iii.) Client: Generate private/public key pair (RSA)
iv.) Client: Send public key to Server
v.) Server: Encrypt session key with Client's Public Key, then send encrypted
session key to Client
vi.) Client: Decrypt session key using Client's Private Key
vii.) Both parties now hold the session key for fast encrypted communications
Server(Server's Session key) <--> Session Key's encrypted packet (Communication medium) <--> Client(Server's Session key, Client's Public/Private key pair)
Thanks!
Assumptions:
Public Key Tampering is not possible.
I think you mean this, by "ignore Certificates and Signing of messages"
Cryptosystem is not broken.
Symmetric cipher is not broken (RC4 is broken, for example)
Asymmetric cipher is not broken
One-way Hash function is not broken
Random number generator is not broken
Under these conditions, that's perfectly safe. In fact what you described in your question is how PGP works.
If you are willing to learn more about attacks against PGP, go here.
And if you are willing to learn basics of cryptology, this is an excellent beginner tutorial.
lets stick with RSA which is what i've chosen.
That's where your biggest vulnerability is.
Protocols such as TLS (which can use RSA) SSH and PGP provide a well defined mechanism for negotiating encryption, and implementations such as openssl provide a documented, tested, portable, robust and we'll tested abstraction layer.
Rolling your own solution carries massive risks of injecting vulnerabilities. And entails ongoing pain in maintenance.
BTW RC4 is considered broken by many people.
I’m trying to implement a message level encryption. Here is the current situation:
We have a mobile app client connects to server via oneway certificate https and we have username/password authentication and secure token for subsequent client to server invocations. So intention of message level encryption is not try to prevent 3rd part sniffing information or stealing client identity, instead to prevent the client user him/her self to something like,
1) Inspect and try to understand server - client protocol
2) Forgery request with other application than our app client
The initial idea is to use symmetric algorithm (DES, AES, or some simpler algorithm, as long as it could not be simply cracked by statistical or mathematical method without knowing the key). And the key is generated from a hash (SHA etc) from a string concatenated from a salt pre-agreed between client and server, and some information server tell client in non-encrypted content (for instance, the first call from client to server happens in non-encrypted context, and server returns a timestamp to client and also remember it for later key generating).
Does this do what I want to do for 1&2? And what is the major vulnerability if any?
There is no "secure" solution to what you try to achieve as long as you publish your software, because any key you use for the message level encryption will have to reach your software somehow. Either it is compiled into it, then a dedicated attacker can read it out of the binary, or it is transferred to the running software using the network, then the attacker can emulate the protocol your software is using to get the key.
The best you can hope for is to make it difficult for a reverse engineer to get to the key. That means you could assemble it in such a way that no complete piece of it can be found in the binary. But still if someone attaches a debugger at runtime she could still read it out of a variable trivially. In the end it remains an arms race between you and the reverse engineer.
I have a server (will be noted as 'A') that transmits multicast to some end stations.
I would like only those that are privileged to see the information, to actually see it.
There is a third party server ('B') that manages unicast communications with both 'A' and the end stations and SSL with both of them.
My goal is to implement a secured multicast:
Two necessary givens:
It has to be multicast.
I want the security in the Application level (not the Network or Transport)
Questions:
Are there such implementations? I've tried searching for "secured multicast" etc. and have come across only IP Multicast security. I want an applicative implementation. If so, Could you recommend some and how to use them?
I thought about generating a special symmetric key - during the communication of 'A' and 'B' and during the conversation of 'B' and end station = to pass it (over SSL) to the end stations.
a. Is that a good idea?
b. A problem I see is that revealing the key becomes easier because of the amount of stations. I thought about replacing the key every hour. I shall inform the stations the key has changed by sending multicast messages: (sequence_number, encrypted_message) - this way every time the key changes then sequence_number++.
What do you think of the implementation? Have better ideas?
I wrote an app called UFTP (http://uftp-multicast.sourceforge.net) that does exactly this.
In terms of key management, each multicast session performs a TLS-like key exchange between the sender and each receiver, then uses the negotiated key for each receiver to send out the group key which is used to encrypt the data. By doing key negotiation for each session, this eliminates complications related to re-keying mid session.
Authentication is done via key fingerprinting, with fingerprints being communicated out-of-band. This is simpler than a certificate based system and minimizes overhead. Each sender and receiver has an RSA or ECDHA key they are identified by.
What you describe is a simple application of PKI:
Each station creates an RSA keypair and sends its public key to the server.
The server generates a random symmetric key and encrypts the multicast message using this symmetric key. New symmetric key should be generated for each message but usually it's not a big deal.
The symmetric key is encrypted using each station's public RSA key. Products of all such encryptions (i.e. encrypted session keys) are merged with encrypted data and compose the multicast packet.
Unfortunately such scheme will cause a significant extra data load on the multicast message, but this is caused by length of keys and the length can't be reduced without sacrificing security.
I'm in the designing stages of a custom tcp/ip protocol for mobile client-server communication. When not required (data is not sensitive), I'd like to avoid using SSL for overhead reasons (both in handshake latency and conserving cycles).
My question is, what is the best practices way of transmitting authentication information over an unencrypted connection?
Currently, I'm liking SRP or J-PAKE (they generate secure session tokens, are hash/salt friendly, and allow kicking into TLS when necessary), which I believe are both implemented in OpenSSL. However, I am a bit wary since I don't see many people using these algorithms for this purpose. Would also appreciate pointers to any materials discussing this topic in general, since I had trouble finding any.
Edit
Perhaps the question should have been: is there a best practices approach for secure passwords over unencrypted tcp/ip? If not, what are the reasons for selecting a particular method over others? (The Rooks answer is closest in spirit to this question so far, even if it does violate the letter).
Edit, part deux
I'm primarily interested in the case of client-server authentication, where there is an expectation that both parties have a shared secret (password) a priori.
You should have a look at "Diffie-Hellman key exchange":
Diffie–Hellman key exchange (D–H) is a cryptographic protocol that allows two parties that have no prior knowledge of each other to jointly establish a shared secret key over an insecure communications channel. This key can then be used to encrypt subsequent communications using a symmetric key cipher.
Once you have exchanged a key, you can encrypt your password with this key and transmit it over the insecure protocol.
I still think that SSL is by far your best choice, after all why reinvent the wheal when so much can go wrong? You don't have to buy an expensive certificate if your have a list of "good" and "bad" (compromised) certificates. openSSL is completely free, and i don't see a good reason not to use it.
Some things you might not know: ssl handshakes can be resumed.
Also you can use SSL/TLS over UDP to reduce overhead its called DTLS.
You could use a challenge-response algorithm. The algorithm goes like this:
The server sends a random string to the client.
The client combines this string with the password (by combining, you can xor them or just append them).
The client calculates a hash (for example, SHA1) of the result, and sends it to the server.
The server calculates the same hash using this random number and the real password.
The server compares the two hashes.
Since you shouldn't store a password in plain text, but as a hash instead, the client should calculate this hash at the very beginning.
There are possibly several libraries implementing this, so you probably don't need to code it yourself.
I'm using RSA to encrypt communication between a server and a client.
Lets say we have 2 Asymetric keys, key 1 and key2.
The server has key1 (Private) from the start and the client has the key1(public)
So here is the scenario:
the client generates key2
client connects to the server
sending key2(public) encrypted with key1(public)
from now on the server will send all data encrypted with the key2(public)
the client sends some random data to the server
the server sends back the same data hashed
the client verifies that the data is right
As far as I can see this should prevent a man-in-the-middle attack, or am I missing something?
At point 7 the client should know if someone is trying to give the server the wrong key to encrypt with, as no one else but the server can decrypt key2(public).
If there is anything that can be done to improve the security please tell me.
The best thing you can do to improve the security is to use an existing design and not try to reinvent the wheel. I'm not saying that what you've done is necessarily wrong, but just that many people much smarter than you and me have spent a lot of time thinking about this problem. Use TLS instead.
As long as key1 (private) has not been intercepted somehow by a third-party, your scenario looks secure.
I think I saw this somewhere in a paper actually. In it, Alice gave Bob an unlocked box (key 1 public), then Bob put a bunch of his own boxes (key 2 public) in it, locks it and sends it back to Alice. Alice then opens the box(key 1 private), and now she can securely seal the boxes that Bob just gave her.
Despite the box analogy, that's essentially what you're doing, so I'd say its secure.
I agree, just use TLS.
Also, what value do steps 5 through 7 provide? A MITM wanting to do an attack that would work after steps 1-4 (e.g. DoS of some sort by passing n transactions through and then stopping, forcing a retry from the start) could do so just as well after 5-7. What do they add?
-- MarkusQ
No, this protocol is not safe.
A man-in-the-middle can intercept the data sent by the client and send whatever it wants to the server, since you haven't specified any mechanism for the server to authenticate the client or verify the integrity of messages it receives.
Sure, you could doctor up your protocol to fix these glaring problems, but there would be others. If you ever fix them all, you'd have something that maps to TLS or SSH, so why not just start there?
#Petoj—the problem I was focusing on was that of the server trusting the messages it receives; your proposal doesn't provide any security there. However, if you are worried about confidentiality, you still have a problem, because the MITM could pass messages back and forth unaltered until he sees what wants to find because you don't have any privacy on the client messages.
Your proposal seems to be aimed at ensuring the integrity of messages from the client. You've developed the protocol to the point where the client can't distinguish between an attack and a network failure. Rather than trying to help the client determine whether the server acted on a tampered message, allow the server to verify the integrity of the message before acting on it.
I will agree with Greg that you are reinventing the wheel. What you are essentially describing is some basic form of key exchange. Incidentally, in order to ensure that it is secure against man-in-the-middle attacks you must also be certain of the server's identity, i.e. ensure that the client can know with certainty that what it believes to be public(key1) really is the server's and not the man-in-the-middle's (e.g. using a CA or having the server's public(key1) in secure storage on the client side.)
Moreover, there are additional considerations you must be aware from a systems standpoint, such as:
asymmetric key encryption is slower than symmetric key encryption, which is one of the reasons why existing solutions such as TLS will use asymmetric key encryption only to negotiate a temporary symmetric key, which is then used for channel encryption.
if traffic analysis by a third-party succeeds in cracking a temporary symmetric key, you have not compromised you asymmetric key pair. You are encouraged to re-negotiate the temporary key relatively often for this reason. Arguably, generating a new key2 in your scenario would mitigate this aspect.