esDynamic
Manage your attack workflows in a powerful and collaborative platform.
Expertise Modules
Executable catalog of attacks and techniques.
Infrastructure
Integrate your lab equipment and remotely manage your bench.
Lab equipments
Upgrade your lab with the latest hardware technologies.
Side Channel Attacks
Evaluate cryptography algorithms from data acquitition to result visualisation.
Fault Injection Attacks
Laser, Electromagnetic or Glitch to exploit a physical disruption.
Security Failure Analysis
Explore photoemission and thermal laser stimulation techniques.
Evaluation Lab
Our team is ready to provide expert analysis of your hardware.
Starter Kits
Build know-how via built-in use cases developed on modern chips.
Cybersecurity Training
Grow expertise with hands-on training modules guided by a coach.
esReverse
Static, dynamic and stress testing in a powerful and collaborative platform.
Extension: Intel x86, x64
Dynamic analyses for x86/x64 binaries with dedicated emulation frameworks.
Extension: ARM 32, 64
Dynamic analyses for ARM binaries with dedicated emulation frameworks.
Penetration Testing
Identify and exploit system vulnerabilities in a single platform.
Vulnerability Research
Uncover and address security gaps faster and more efficiently.
Malevolent Code Analysis
Effectively detect and neutralise harmful software.
Digital Forensics
Collaboratively analyse data to ensure thorough investigation.
Software Assessment
Our team is ready to provide expert analysis of your binary code.
Cybersecurity training
Grow expertise with hands-on training modules guided by a coach.
Semiconductor
Security Labs
Governmental agencies
Academics
Why eShard?
Our team
Careers
Youtube
Gitlab
Github
For a long time, there was the Advanced Encryption Standard (AES). The mighty king of symmetric ciphers. Known by all, used by all, in all cases.
It was great, there was hardware support in many devices making it the most efficient option to use. Any software application requiring a bit of security (confidentiality) was using it, and most other designs could not compete. Security has been thoroughly challenged during many years people spent searching for vulnerabilities without finding any attack breaking the security claim of the authors. Do we need something else? Is symmetric cryptography design a thing of the past? Is it dead?
Except for keeping researchers busy, what is the point of looking for other algorithms since we already have a perfectly secure and efficiently implemented solution? To answer this question, let us return to school for a second. When you study computer science, you learn how to sort. To sort elements, there are a lot of algorithms. Every algorithm has a different time complexity, corresponding to the minimum number of operations to perform. When you implement the algorithm, its complexity is the lower bound of what you can do, and if the implementation is good, you get close to it. However, if the initial complexity is too high, even the best implementation will not save the day. Now you might see where I am going. AES is good, and it might have reached its full potential with years and years of optimization in every aspect. If you want a significant improvement, it might be a dead end.
OK now you might agree that it could be interesting to look for something new, but you are afraid of potential security breaches. AES was designed in the 90s and since then nobody has broken it, so why should we risk using something new that could be broken? This is true, you should not if you don't need it. If there is no reason for you to look for something new don't. However, if you are looking for a significant improvement in performance or a smaller implementation then AES might turn out to be the bottleneck, and then you do not have a choice. No worry, this is good news. Twenty-two years ago, Rijndael was standardized and became known as AES (easier to pronounce). Since then cryptographers haven't stopped working, the knowledge has grown and 10,694 papers later (the number of papers submitted only on https://eprint.iacr.org since 2001), the general understanding of cryptography is much better.
As for phones, computers, or any other technology, we can do it now as robustly as before but faster and with fewer resources.
Some of those reasons led to the idea of Lightweight Cryptography and in 2018 the National Institute of Standard Technology (NIST) started a competition to standardize an algorithm. Light, because compared to AES it should be βlighterβ. Weight, because we should consider different metrics to compare it to AES such as power consumption, speed, or space. The context was settled: finding an alternative to AES-GCM (AES in Galois counter mode which is a mode to do authenticated encryption with additional data) that can perform better.
ASCON won the competition. The decision was supported by a good part of the symmetric cryptographic community. ASCON meets the purpose of being a balanced design performing well in all performance metrics and being as secure as AES. Developed in 2014, it was also selected in the final portfolio of the CAESAR competition for lightweight applications. So after almost 10 years and 2 competitions, no major threat has been discovered wich suggest a bright future following AESβs path. However, what is ASCON?
When we talk to ASCON, we should be more precise because the name "ASCON" can refer to many things. ASCON is the name of a Permutation. Permutation-based cryptography is now a well-known construction that offers good security properties. A permutation is a type of function. In the context of cryptography, permutations can be seen as functions that take large inputs (multiple hundred of bits) and apply transformations with good cryptographic properties. This permutation is used in a sponge-based construction to build the family of authenticated encryption schemes called ASCONv1.2 and the family of hash functions ASCON-Hash.
For various reasons, many people might use the ASCON name to refer to ASCONv1.2 or ASCON-hash and the permutation.
For many companies, the standardization stamp on an algorithm is the green flag for using it. Now that ASCON has the NIST stamp, you may wonder if it will be used since there are plenty of useless algorithms standardized by many different organizations. ASCON is a well-suited design for hardware implementation, and some software and hardware implementations have shown great results compared to the smallest and fastest AES-GCM implementations.
Since time and space are money for chip manufacturers, and they usually don't waste money, you may find in the future ASCON implemented in many devices. It won't replace AES because the hardware support is there and replacing it would be very expensive and completely worthless.
Now we have an algorithm ready and standardized, what else needs to be done? An important aspect to take into account is that the standardization process only concerns the algorithm, not the implementation. Therefore, there is no standard ASCON implementation. However, there are reference implementations produced by the design team of ASCON for the hash function and the authenticated encryption for various platforms. Implementation is necessary to show performance, but it is also crucial for security as side-channel analysis can exploit weaknesses to recover secret information. Those attacks are well-known by the community, therefore the design of ASCON intends to reduce the attack surface and facilitate the adaptation of side-channel countermeasures. However, unprotected implementations (as stated in the name) are not protected against side-channel, and some papers show successful attacks on ASCON.
The recent standardization might increase the focus of side-channel attacks and protection on ASCON, even if the existing literature constitutes a solid base.
Okay, we have now a standard, some implementations for various platforms, and years of analysis to assess the security. So what next? Is it again the end of symmetric cryptography? Fortunately - or unfortunately - not. ASCON solved a problem, but not all problems. The increasing number of devices, technologies, and applications still provide an increasing number of different security problems to solve.
And since those problems exist, researchers will try to find solutions. In the future, some classes of problems might lead to new standards like the very trendy topic of low-latency.