This is not a programming question per se, but it is related to a c program that I am trying to make in order to respond the ip sla control messages sent by a cisco router. I know that it uses MD5 using and a key chain in order to authenticate the packet (Could be MD5 or HMAC). I know about the theory about HMAC and MD5 and all about the message and the key and all that stuff that the theory on the book give us... but I have a question that does not seems very simple at least to me that is at the end Which is the "message" that is hashed and added to the packet so the other end could know that he packet is valid?
Thanks for your help...
EDIT:
I have two routers one acting as a ip sla generator and another one as an ip sla responder. The ip sla generator authenticate the data sent by using MD5 and a key.
Capturing the packets that left the ip sla generator interface with Wireshark I found this:
Packet not Authenticated:
IP header
4500005000000000ff1136e3c0a801c3c0a801a6
UDP Header
e2e607af003ccdbd
Payload
01040034000000000004001000000000c0a801a6ea6014500001001c000000000000000000000000000000000000000000000000
Packet Authenticated with key "cisco":
IP Header
4500005000000000ff1136e3c0a801c3c0a801a6
UDP Header
c20107af003cd296
Payload
01040034000000000004001000000000c0a801a6ea6014500001001c00000000*01ff0000b9c0ae94fec238bd43d13129a6625eda*
*where at the end of the payload you could see 0x01ff that is the key number used to authenticate the packet and 0xb9c0ae94fec238bd43d13129a6625ed that is the authentication string
Capturing another Authenticated packet with key "cisco" I got this:
IP Header
4500005000000000ff1136e3c0a801c3c0a801a6
UDP Header
d47607af003cc021
Payload
01040034000000000004001000000000c0a801a6ea6014500001001c00000000*01ff0000b9c0ae94fec238bd43d13129a6625eda*
As you could see the UDP header changes but the authenticated message remains the same, that lead me to infer that the message to hash is just the payload but hashing the following combinations does not produce the authentication needed:
MD5 of the payload not authenticated
MD5 of the payload not authenticated + key in Hex
Hmac-Md5 of the payload not authenticated
Hmac-Md5 of the payload not authenticated + key in Hex
A lot more combinations too long to be listed...
So i think that the message is not as simple as the payload or the Authentication Method used by Cisco is not standard. Am I missing something? or There is something else I could try?
Thanks for your help...
The answer is: yes, it depends on the protocol (which I cannot find). I don't see any mention of HMAC in the documentation though, so it is much more likely that the key is included as last part in the hash calculation, but is not in the package (of course). This is different from appending zero's. The plain MD5 hash is then used as some poor man's authentication scheme.
All this from the confusing docs from Cisco and the relatively hard to read question - and general knowledge of crypto, of course.
Related
Suppose I have a fixed message pool of 1000 messages, person A is sending message from this fixed message pool to person B using RSA.
If an interceptor also have the message pool he can precompute all the encrypted messages using B's public key. Now if he intercept A's message can he surely tell which message A has sent to B?
In this case should we use RSA only for a symmetric key exchange and then messages should be encrypted using a symmetric algorithm?
The text-book RSA encryption algorithm is deterministic. But the official RSA specifications (and also all implementations used in practice) include some (partly random) padding, so we don't actually encrypt plaintext, but pad(plaintext). So the above mentioned problem will not occur.
More details can be found in this answer https://stackoverflow.com/a/7933071/10690480
I'm planning to use the crypto_box() functions of Nacl to encrypt messages as part of a client/server protocol. The server has to deal with multiple clients and each message from a client to the server is encrypted using the public key of the server and signed with the private key of the client.
The cypto_box() functions also require me to provide a nonce. The current message number could be used as a nonce–to my understanding, the nonce is necessarily known to an attacker who is capable of keeping track of how many messages were exchanged. Both, the client and server would then maintain a message counter and simply use the newest counter value as a nonce.
However, I must deal with the case where messages are reordered or lost. Therefore I'd send the nonce in plaintext alongside the encrypted message. As long as the same nonce is not used twice, I don't see any problems with this approach. Did I miss out on something?
No, nonce's and IV's may be considered public knowledge. I've just checked the NaCl site and I don't see any explicit remarks that contradict this.
CBC mode of operation has some additional requirements for the IV (non-predictability) but that's of course not an issue in NaCl.
You should make sure that you don't accept any nonces <= the last received nonce though, otherwise an attacker could probably resend or reorder messages.
For a personal MMO game project I am implementing a homebrew reliable UDP-based protocol in java. Given my current setup I beleive it would be relatively simple for a snooper to hijack a session, so in order to prevent this I am taking the opportunity to learn a little cryptology. Its very interesting.
I can successfully create a shared secret key between the client and server using a Diffie-Hellman key exchange (a very clever concept), but now I need to use this to guarantee the authenticity of the packets. My preliminary testing so far has shown that the couple of different ciphers Ive tried bloat the amount of data a bit, but I would like to keep things as small and fast as possible.
Given that I am only trying to authenticate the packet and not nessecarily conceal the entire payload, I have the idea that I could put an 8 byte session ID generated from the secret key into the packet header, encrypt the whole packet, and hash it back down to 8 bytes. I take the unencrypted packet and put the 8 byte hash into the place of the session ID and then send it off.
Would this be secure? It feels a little inelegant to encrypt the whole packet only to send it unencrypted - is there a better/faster way to achieve my goal? Please note I would like to do this myself since its good experience so Im not so interested in 3rd party libraries or other protocol options.
If both peers have access to a shared secret (which they should, since you're talking about Diffie-Hellman), you could simply store a hash of the datagram in its header. The receiver checks to see if it matches.
As an added security measure, you could also add a "challenge" field to your datagram and use it somewhere in the hashing process to prevent replays.
So this hash should cover:
The shared secret
A challenge
The contents of the datagram
EDIT
The "challenge" is a strictly incrementing number. You add it to your datagram simply to change the hash every time you send a new message. If someone intercepts a message, it cannot resend it: the receiver makes sure it doesn't accept it.
I'm wondering why ssl encrypted data can't be cracked easily once the packets are intercepted. As i understand it when you connect to a site like facebook the browser and site agree on a cipher, what stops the sniffer from seeing what cipher they agreed to?
SSL uses asymmetric encryption, meaning the decryption key is different than the encryption key. So if you as a client encrypt your packets with the server's public key, it can only be decrypted by the private key, which remains on the server. Of course, this is a simplification of everything that happens in an SSL transaction, but that's the basis of the concept.
Imagine sending a box with an open padlock to the other side - when the other side wants to send a message, they put it inside the box, lock the padlock and send it back to you, where you use your (private) key to unlock it. Even if the intercepting party has sees the padlock, they still don't have the key.
There's a lot of ways to describe it. For me, my ah-hah moment was when I figured out that, after information is encrypted multiple times, it can be decrypted in any order.
A encrypts first, passes to B a single encrypted message [A encryption].
B encrypts the message a second time, and passes to A a double encrypted message [A encryption and B encryption]
A removes [A encryption] from the message, leaving only [B encryption], and sends the message to B.
B now has a [B encrypted] message, and knows how to decrypt it.
The sniffer sees the message encrypted three different ways: [A], [AB], and [B].
That's three message passes to exchange one message, but once it's passed and both sides have the unique information to decrypt further communication, future messages only need one trip.
If you want a simple example of how a message could be decrypted in any order, you can use XOR as a sample encryption method. For keys A and B, message M, and XOR is ^, then
M ^ A ^ A = M
M ^ A ^ B ^ A ^ B = M
Facebook signs it's package with a certificate that Facebook got from an certificate authority such as RapidSLL.
As long as you trust the certificate authorities that all certificate they issue for facebook.com do really belong to facebook.com the connection is safe.
Facebook then sends you via a signed message it's public encyrption key which you can use to encrypt your messages to be read by facebook.
Yes, the cipher is public. However, the client asymmetrically encrypts a random session key (or rather a precursor) using Facebook's public key (they verify it's really Facebook's key by checking that it is signed by someone trusted). So only Facebook (who has a private key) should be able to derive the actual symmetric keys that are used to exchange website data.
See this detailed walk-through. In that example, an eavesdropper can tell that the connection uses RSA, RC4, and MD5. But they don't have Amazon's private key, so they can't derive the session keys.
Like Derek H said, there are fundamental differences between symmetric and asymmetric encryption. Look up stuff like DH key exchange protocol and RSA cipher, they are fundamental in SSL/TLS. On the other hand, it's relatively easy to decrypt sniffed data (ROBOT attack).
If you just need to be sure your communication is secure, you can simply use SSL/TLS Server Test, there you can see if you're not using recommended algorithms or see if your SSL/TLS configuration is PCI-DSS/HIPAA/NIST compliant.
I want to secure the communication of a TCP-based program using a shared passphrase/key. The easiest way to do that without having to deal with block size, padding, ... is to directly use a stream cipher. Doing that way, the amount of data is not changed between clear and encrypted data and the modification is trivial.
Using only a stream cipher means that there is no authentication and I have always considered/heard that encryption without authentication is not secure enough and should not be used.
If adding authentication to a stream cipher is mandatory, we lose the simplicity that stream cipher has added because we must add an HMAC or use an authenticated encryption method (like crypto_secretbox from NaCl), there is a minimum message length, we must handle padding, ...
What would you recommend? Is it safe to only use stream cipher without authentication in some particular cases?
Using some kind of message authenticator is particularly important with stream ciphers, because the relationship between changes to the ciphertext and changes to the plaintext is so simple.
You can't just blindly go and apply the stream cipher without adding any extra information to the stream, anyway - remember the most important rule of stream ciphers:
NEVER RE-USE THE SAME KEYSTREAM
So unless you are only ever going to encrypt a single connection, and throw the passphrase away afterwards, you will need to generate a session key for each connection from the shared secret. This implies that you will need to send some extra information at the start of the connection, and since you're sending that anyway, sending a HMAC after each message should be no big deal.
Using a stream cipher because it seems simpler is usually a mistake, anyway. You mentioned crypto_secretbox from NaCl - I recommend using that, it will take care of the authentication and padding issues for you.
You could consider using AES in GCM-mode. That will give you a stream-cipher with built-in authentication.