US NIST Unveils Winning Encryption Algorithm For IoT Data Protection (bleepingcomputer.com) 9
The National Institute of Standards and Technology (NIST) announced that ASCON is the winning bid for the "lightweight cryptography" program to find the best algorithm to protect small IoT (Internet of Things) devices with limited hardware resources. BleepingComputer reports: ASCON was selected as the best of the 57 proposals submitted to NIST, several rounds of security analysis by leading cryptographers, implementation and benchmarking results, and feedback received during workshops. The whole program lasted for four years, having started in 2019. NIST says all ten finalists exhibited exceptional performance that surpassed the set standards without raising security concerns, making the final selection very hard.
ASCON was eventually picked as the winner for being flexible, encompassing seven families, energy efficient, speedy on weak hardware, and having low overhead for short messages. NIST also considered that the algorithm had withstood the test of time, having been developed in 2014 by a team of cryptographers from Graz University of Technology, Infineon Technologies, Lamarr Security Research, and Radboud University, and winning the CAESAR cryptographic competition's "lightweight encryption" category in 2019.
Two of ASCON's native features highlighted in NIST's announcement are AEAD (Authenticated Encryption with Associated Data) and hashing. AEAD is an encryption mode that provides confidentiality and authenticity for transmitted or stored data, combining symmetric encryption and MAC (message authentication code) to prevent unauthorized access or tampering. Hashing is a data integrity verification mechanism that creates a string of characters (hash) from unique inputs, allowing two data exchange points to validate that the encrypted message has not been tampered with. Despite ASCON's lightweight nature, NIST says the scheme is powerful enough to offer some resistance to attacks from powerful quantum computers at its standard 128-bit nonce. However, this is not the goal or purpose of this standard, and lightweight cryptography algorithms should only be used for protecting ephemeral secrets. For more details on ASCON, check the algorithm's website, or read the technical paper (PDF) submitted to NIST in May 2021.
ASCON was eventually picked as the winner for being flexible, encompassing seven families, energy efficient, speedy on weak hardware, and having low overhead for short messages. NIST also considered that the algorithm had withstood the test of time, having been developed in 2014 by a team of cryptographers from Graz University of Technology, Infineon Technologies, Lamarr Security Research, and Radboud University, and winning the CAESAR cryptographic competition's "lightweight encryption" category in 2019.
Two of ASCON's native features highlighted in NIST's announcement are AEAD (Authenticated Encryption with Associated Data) and hashing. AEAD is an encryption mode that provides confidentiality and authenticity for transmitted or stored data, combining symmetric encryption and MAC (message authentication code) to prevent unauthorized access or tampering. Hashing is a data integrity verification mechanism that creates a string of characters (hash) from unique inputs, allowing two data exchange points to validate that the encrypted message has not been tampered with. Despite ASCON's lightweight nature, NIST says the scheme is powerful enough to offer some resistance to attacks from powerful quantum computers at its standard 128-bit nonce. However, this is not the goal or purpose of this standard, and lightweight cryptography algorithms should only be used for protecting ephemeral secrets. For more details on ASCON, check the algorithm's website, or read the technical paper (PDF) submitted to NIST in May 2021.
ASSCON (Score:1)
ASCON? You know you are fucked with a name like that.
Does this make sense? (Score:2)
Is it really worth it to create another standard rather than just counting on hardware acceleration for AES? I mean doesn't the economics tend to favor just making a SoC that works for everything and can thus be made at high volumes on recent processes?
Re:Does this make sense? (Score:5, Informative)
ASCON is targeting slightly more expensive than dirt, slightly less common than sand silicon devices that ideally can run on a button battery for a few years. A hardware acceleration assist is added to MCU's you have so many transistors they are essentially free and it's considered OK if they take over a day to drain a 5000mAh battery. In other words: one is targeting apples, and the other oranges.
If you look ASCON's throughput and power consumption figures on constrained hardware [mit.edu] it is literally orders (plural) of magnitudes better than AES. But ASCON can't be block parallelised. AES-GSM can, so if you hard hardware to burn it's going to be faster to ASCON.
Re: (Score:2)
Indeed. ASCON is targeted at systems too small and too low power to have hardware AES. This does lower the security somewhat, but AES has a lot of reserves and ASCON is still suitably secure against anything but a high-resource attacker for the foreseeable future. A high-resource attacker eventually may or may not be able to break ASCON, so do not encrypt anything with it that needs long-term protection.
Re: (Score:2)
It's very interesting stuff because at the moment most very low end devices either don't encrypt, or end up using a significant amount of their resources to do so. LORA is a good example of the overhead added by the crypto.
Only 128 bits? (Score:3)
Yes, I know that 128 bits is good enough for most things, but most encryption algorithms for bulk/symmetric stuff at least can go to 256 bits if not more, for long term purposes. It looks like ASCON tops out at 128 bits, 80pq for something resistant against Shor's Algorithm.
This is good enough for maybe having some IoT device send out a log to some central server, but it would be nice to have something that would pass audits, especially if 256 bit encryption is stipulated.
Overall, time will tell... The people who made it know their stuff, but it would be nice to have the option for 256 bits. Of course, one could use three keys and do EDE (encrypt with one key, decrypt with another key, encrypt with a third key) encryption like 3DES, but that is a really nasty hack, and something to be avoided if at all possible.
Re:Only 128 bits? (Score:4, Interesting)
Even AES-256 thinks that 128-bit is good enough. The -192 and -256 variants increase the key length but not the cipher state - and the -128 key schedule has actually been shown to be stronger than -256.
The other variants were only developed because it was a contractual requirement that there _be_ a differentiation of three distinct levels. Not that they be stronger, they just have to be algorithmically incompatible so that e.g. a medium-security printer couldn't print high-security documents.
Wonder when this will be in mainstream libs... (Score:3)
I wonder when OpenSSL/LibreSSL/GnuPG, and the Linux kernel will support this algorithm, and if it will wind up in the next TLS spec. Right now, there isn't much info on it, although the test libraries are a good PoC, but there is a big difference between basic stuff implementing the algorithm versus optimized and throughly audited source code that is going to be hammered on and looked at, line by line, by many, many blackhats and nation-states.
Hopefully we will see a useful implementation of this soon, so it can be tested and used in SoC and SBC applications.