3
$\begingroup$

If we have a very performance critical interactive session, like a video game, running on a trusted platform (video game console).

If our goal is to prevent exfiltration of up to date information (enemy locations, health etc) and malicious commands sent to server in a small time frame (aim botting), say ~1000ms through 1h, to prevent MITM cheating, it seems that 128 bits of protection is excessive for our threat model.

Also are there any decent, modern ciphers with a key size of 64 bits that might actually be faster than AES-NI?

Improve this question
$\endgroup$
5
  • 2
    $\begingroup$ I once asked this question. There are some Duplex-Permutation ciphers in the NIST Lightweight Cryptography Project such as Gimli and Xoodyak, you can adjust the parameters to use lower capacity and higher rate for your use case. $\endgroup$
    – DannyNiu
    May 18, 2020 at 4:35
  • 1
    $\begingroup$ Well, this wouldn't be well thought of by cryptographers, but you could use AES-NI, just with fewer rounds (for example, 5 instead of 10). This would most certainly be vulnerable to known cryptographical attacks; however most of them involve chosen plaintexts. If you use a mode that randomizes the plaintext given to the cipher (e.g. CBC), that might be good enough (although integrity protection would be a nontrivial concern...) $\endgroup$
    – poncho
    May 18, 2020 at 14:42
  • 1
    $\begingroup$ Generally we assume that 64 bit ciphers are ciphers that use a block size of 64 bit. Those are not necessarily faster than 128 bit ciphers, e.g. 3DES is slower than AES-128 in most circumstances. Note too that the block size does not indicate a weaker cipher per se, and 3DES can offer up to 112 bits of security, for instance, and Blowfish will offer more than that. Not that I recommend these, by the way. $\endgroup$
    – Maarten Bodewes ♦
    May 18, 2020 at 23:59
  • $\begingroup$ @MaartenBodewes, Since when did bits refer to block size? AES-128 is in reference to the keysize, I'm not talking about 3DES at all, DES is more applicable to my model. $\endgroup$
    – Daniel Hill
    Jun 28, 2020 at 2:30
  • $\begingroup$ Changed your question. Note that I started out by pointing out that "Generally we assume that 64 bit ciphers are ciphers that use a block size of 64 bit." So in that sense your question and especially title were unclear. No relevant tags were added either. I've fixed those now, but next time please try and fix your question instead of criticizing the messenger. $\endgroup$
    – Maarten Bodewes ♦
    Jun 28, 2020 at 11:58

1 Answer 1

Reset to default
2
$\begingroup$

I believe that ciphers of low bitwidth still have a place for sensor data and likely, video game data. Mainly, this is due to the nature of the data. In the case of a sensor, cryptography generally buys you very little in the practical sense outside of verifying a message, and the same is true in video games. Your data is "stale" in a matter of seconds, and as long as the scheme takes minutes to brute force, you are likely to be fine.

If you have access of AES-NI, or an equivalent instruction set, you will not be able to make anything faster. Let's make the assumption that you are not worried about side-channel attacks, do not have cryptographic hardware on your CPU, and just are interested in speed.

I use SIMON in my embedded hardware, and SPECK in software when I cannot get something else to fit in the space. SPECK is about as fast as you get on an IC without explicit cryptographic hardware. The cryptographic community while give you a difficult time for these ciphers as the NSA created them, but I know of nothing better. SPECK64/96 has 26 rounds, on a MIPS 32-bit MIPS core, it takes me 51 instructions (after I expand the keys) to encrypt the block.

Improve this answer
$\endgroup$
7
  • $\begingroup$ Could you maybe expand a bit on the trade off between key size and security for e.g. SIMON? Mainly, does changing from 128 or 96 bits to 64 bits make a big significance? I see that the number of rounds only increases from 32 to 36 for 96 bits... $\endgroup$
    – Maarten Bodewes ♦
    Jun 28, 2020 at 12:02
  • 2
    $\begingroup$ "Your data is "stale" in a matter of seconds..." This is only a valid argument, if the entire result of a brute force can then be considered stale. If the attacker gets the key and the key is never changed / reused during a session, this had to be taken into account. It would be prudent just to look at the single message. $\endgroup$
    – tylo
    Jun 28, 2020 at 12:42
  • $\begingroup$ Ah right, so you use it in 64 bit block mode but still use a 96 bit key. Heh, officially that would put the question out of specs for the question (which I updated to clearly specify that this is about key size, something that was missing from the original), but as the question somehow made key size the determining factor for the speed I guess this is due to the XY-problem. $\endgroup$
    – Maarten Bodewes ♦
    Jun 28, 2020 at 13:51
  • $\begingroup$ For sensor data, surely that's only true as long as you don't need the data to stay private. If an eavesdropper wants to record the data stream (which, for a generic "sensor", could be anything from a temperature reading to an audio/video feed) they may not care much that it takes them a few minutes or hours or days to decrypt it. $\endgroup$
    – Ilmari Karonen
    Jun 28, 2020 at 14:26
  • $\begingroup$ @tylo If you have a 64-bit cipher, at 1million attempts per second, you are still 2000 years (sequential tries). I agree generally with your statement. You just need to assume that your sensor doesn't fall all the bus. I've never come across a real-world problem that could encrypt something at sensor and keep up that was a large key size. here's an example: ti.com/product/ADS54J60 $\endgroup$
    – b degnan
    Jun 28, 2020 at 16:17

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.