Hi all,

This is a very simple question to ask but may be really hard to answer but simply put...

"With regards to TEA, can you determine the key by knowing the original message and the encrypted output?"
​

https://en.wikipedia.org/wiki/Tiny_Encryption_Algorithm

I ask this because I have implemented TEA into RIOTOUS and it uses this method for authentication:

• User connects to server and sends username unencrpyted
• Server has private key and encrypts a random message for the user to solve
• User receives the encrypted message and decrypts it
• User sends the decrypted message back to the server
• Server checks the users answer with the original random message. If correct then user is authentic
• All communication from this point on are fully encrypted

I am wondering if an attacker can determine the key by knowing the original random message and its encrypted result.

 

Hi all,

This is a very simple question to ask but may be really hard to answer but simply put...

"With regards to TEA, can you determine the key by knowing the original message and the encrypted output?"
​

https://en.wikipedia.org/wiki/Tiny_Encryption_Algorithm

I ask this because I have implemented TEA into RIOTOUS and it uses this method for authentication:

• User connects to server and sends username unencrpyted
• Server has private key and encrypts a random message for the user to solve
• User receives the encrypted message and decrypts it
• User sends the decrypted message back to the server
• Server checks the users answer with the original random message. If correct then user is authentic
• All communication from this point on are fully encrypted

I am wondering if an attacker can determine the key by knowing the original random message and its encrypted result.

It is not quite that easy to break, but it has known weaknesses according the the wiki article on the subject.
https://en.wikipedia.org/wiki/Tiny_Encryption_Algorithm

 

With a man in the middle attack I could watch repeated operations on your authentication system for connections and log every authentic message pair.
Having lots of known plaintext/ciphertext makes finding at least one key easier than the brute force attack but I won't worry much about it.

https://en.wikipedia.org/wiki/Impossible_differential_cryptanalysis
http://www.csshl.net/sites/default/files/downloadable/crypto/TEA_Cryptanalysis_-_VRAndem.pdf

 

Ah thanks for the responses guys!

So to sum up...

"It would still be somewhat tricky to break but with repeated messages it could be done. However it is not as simple as an inverse function which could solve it in 1 second"

 

Ah thanks for the responses guys!

So to sum up...

"It would still be somewhat tricky to break but with repeated messages it could be done. However it is not as simple as an inverse function which could solve it in 1 second"

Your system is insecure (too much plaintext on the outside encrypted network) but it's unlikely to be attacked unless something of value is contained in the encrypted messages. Once the key is known (let's say it takes weeks of logging) you do have a inverse function which could solve it in >1 second.

 

@nsaspook

I know that once the key is known then the attacker can just decrypt all messages. One idea would be to negotiate new keys when authentication has been done where the server generates a new key and sends the key (encrypted) to the client. So long as the attacker cannot use an inverse function on cyphertext and plaintext to get the key in a second then I am happy.

 

Is there a reason that you only need to safeguard your message traffic for one second?

 

@nsaspook

I know that once the key is known then the attacker can just decrypt all messages. One idea would be to negotiate new keys when authentication has been done where the server generates a new key and sends the key (encrypted) to the client. So long as the attacker cannot use an inverse function on cyphertext and plaintext to get the key in a second then I am happy.

You have two separate issues. Authentication: You are who you claim to be and the key exchange for symmetrical encryption to hide the conversation between the authenticated parties.
What you have is the classic key exchange distribution problem of symmetrical cryptosystems. Ideally your key management should not be over the network using the same type of bulk encryption system the cleartext uses because if the attacker has one good key on a running system then the attacker can likely follow all key changes (forward secrecy). The key exchange protocol becomes an easier target to identify and attack than the actual crypto if it happens often or at every transaction. It's usually better to extend the usage of a single key to a known safe period for the encryption system data rate where key exchange is costly or questionable. A typical period was 24 hours for most systems and/or at loss of signal for OTP type systems.

I would first look at something like the Diffie-Hellman Key Exchange if you need a session key .

https://iacr.org/archive/eurocrypt2001/20450451.pdf

 

I wanted to implement a key exchange system but getting to work on a micro with less than 256 bytes of ram proved difficult!

 

I wanted to implement a key exchange system but getting to work on a micro with less than 256 bytes of ram proved difficult!

I would use an external crypto co-processor in that case.
https://www.microchip.com/wwwproducts/en/ATECC508A
https://eewiki.net/display/Motley/ATECC508A+Node+Authentication+Example+Walk-through

 

I wanted to implement a key exchange system but getting to work on a micro with less than 256 bytes of ram proved difficult!

Most of the mainline algorithms were designed with the intention that they would be implemented on resource-starved processors. Essentially they are designed so that you can trade speed for memory.

I know someone that implemented a few of the protocols on such platforms, including dealing with most of the side-channel attacks. I can ask him what kind of resources were involved.

 

This is a very useful page
https://en.wikipedia.org/wiki/Modular_exponentiation

 

This is a very useful page
https://en.wikipedia.org/wiki/Modular_exponentiation

Is this the roadblock that you've been running up against in trying to implement a more robust algorithm on your hardware?

 

@WBahn This was one of the major ones