Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Yet the attack, as very clearly stated at your link, does require much more computing resources and time than a standard brute force attack.

So I can only agree with DJB that the attack, in its present form, is completely useless.

At most, it can be argued that maybe someone will find a way to use the ideas from your link to conceive a new attack that is much more efficient.

I do not find this more convincing than the threat that someone will find an efficient attack based on completely different ideas.

Any more recent cryptographic algorithm is riskier than the older algorithms, because it is less understood.

However Gimli is intended for slow microcontrollers, where the encrypted data cannot be very valuable, otherwise one would use a slightly more expensive CPU like Cortex-A55 (a few dollars instead of less than a dollar, for a MCU/MPU package), with standard cryptographic libraries.

So the damage done by an attacker decrypting the MCU communication cannot be great, therefore it is an acceptable risk to use a less trusted algorithm, if that reduces a lot the hardware cost.



So the attack must be useless, but if it was not it wouldn't matter because the software doesn't have to be secure to begin with. That's not a great mindset through which to view cryptography.


You put in my mouth words that I have not said, so I will say more clearly:

1. That attack is useless.

2. Nevertheless, Gimli is relatively new and it is also designed for minimum cost, not for maximum security, so there is a risk that someone else could discover a real attack, a risk that is greater than for older algorithms like AES or Chacha.

3. There exists no practical 100% secure form of cryptography. Any choice of cryptographic algorithms is a compromise between the computational cost for the operations done for protecting data, e.g. encryption/decryption/signing/verifying and the computational cost for an attacker that tries to decrypt or forge the protected data.

4. The compromise must be chosen for each application depending on the implications of a successful attack. Some data is so important that it has to remain secret even 10 or 20 years in the future, other data is ephemeral and it does not matter if an attacker would succeed to decrypt it a week later.

The correct mindset in cryptography, like in any other domain, is to choose the right tool for the job.

If you want to use a $0.50 microcontroller, then you must use simpler cryptographic algorithms that can have an acceptable performance on such low-cost hardware. If you want to use algorithms that are harder to break, then you must accept to pay $5.00 for a more powerful device (at the latter price any decent device would have hardware implementations for standard algorithms like AES and SHA-256, so you would not have reasons to use anything less secure).


You can perform very strong cryptography on a 70 cent microcontroller. While that is more than 50 cents, the considerations are quite simply not purely cost (and certainly not to the extent that you quote). Given your explanation, I do not see how my original interpretation is any different from what you actually meant - given that, I must question your reasoning about absolute cost-effectiveness and how much you need to sacrifice for this in practice.

I do not disagree with the premise that sometimes you must make tradeoffs based on cost, but I do disagree with the premise that a platform that you yourself say is not so good should be used because to do otherwise is to (potentially) lose a lot of money. If we get to chips that are a few cents a piece and somehow still need encryption, perhaps you are correct. Then we can be at peace with encryption that only defeats casual snooping. In all other cases, this seems like a poor tradeoff.


> You can perform very strong cryptography on a 70 cent microcontroller

Yes, thanks to Gimli.

I dunno why you changed the price from 50 cents to 70, but anyway which MCU and algorithms are you thinking of?




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: