Liblithium: A lightweight and portable cryptography library
github.com
github.com
Frank Denis also wrote libsodium, so guess it is a pun by him? Don't think there was any lib{chemical element} popularised before that, and there's a few now, but could be wrong.
Acronyms all the way down.
The first version was a rewrite of libsodium, that was small and contained in a single C file. Also introduced xchacha20 for the first time. Then, the Gimli paper was published, and libhydrogen was rewritten to take advantage of it.
Smaller than libhydrogen, there's now charm: https://github.com/jedisct1/charm , also a pun. The plan was to eventually add bottom (platform abstraction layer), strange (asymmetric cryptography), and top (high-level APIs) to build a modular, component-based library.
That being said, Gimli in libhydrogen may eventually be replaced by Xoodoo.
Nothing wrong with that, and I'm glad that libhydrogen was useful for Tesla, but mentioning it would have been polite.
[1]: https://embeddeddisco.com/
PS: more info:
* video: https://www.youtube.com/watch?v=bTGLO4obxco
* paper: https://eprint.iacr.org/2019/180
It's unwise to use cryptographic code written by engineers working 72 hour weeks at an "extremely hardcore" company.
Here is the Gimli spec:
https://gimli.cr.yp.to/spec.html
Here is the attack illustrating weaknesses in the design:
https://eprint.iacr.org/2017/743
Here is a statement from the Gimli team arguing that it is still secure despite the published 22-round attack:
https://gimli.cr.yp.to/statement.html
Finally, Hamburg's "attack" will not be feasible in the foreseeable future, even with quantum computers. Even if the "attack" were extended to the full 24 rounds, it would not contradict any security claims made in the Gimli paper.
Daniel J. Bernstein (djb) is a wizard, but use Gimli at your own risk.
Basically the attack shows that Gimli's speed and simplicity introduces exploitable flaws and reduces its security:
Bernstein et al. have proposed a new permutation, Gimli, which aims to provide simple and performant implementations on a wide variety of platforms. One of the tricks used to make Gimli performant is that it processes data mostly in 96-bit columns, only occasionally swapping 32-bit words between them. Here we show that this trick is dangerous by presenting a distinguisher for reduced-round Gimli.
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.
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).
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.
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?
Still, reading that, against 22.5 (of 24) rounds of the Gimli computation, the attack is claimed to need 2^129 bits of memory. That is 77,371,252,455,336,267,181,195,264 TB if math is right, which does seem to gently push that "attack" into a rather theoretical plane?
Not sure what I'm missing, from your tone I would expect a smoking hole and this doesn't seem to be that.
It has nothing else in it apparently.
WolfCrypt is a better solution and is FIPS certified.
EDIT: I didn't know what GIMLI was.
(That is not an endorsement.)
I've implemented some ciphers, and many more security protocols, but I won't pretend to understand the math well enough to directly address your question. But I believe schemes sharing keys between Ed25519 and X25519 generally rest on this paper: https://eprint.iacr.org/2021/509.pdf That paper describes the process in both directions, IIUC. See page 4,
> In this case the recipient translates the public key from edwards25519 to an X25519 public key using the map from [17]
and page 6,
> We will retrieve the two candidates for the v-coordinate from the curve equation and choose one of them uniformly at random. We then change coordinates to edwards25519 using the map in [17, 4.1]. This change of coordinates preserves addition on the curve and the basepoint of curve25519 is mapped to the basepoint on edwards255196.
See https://libsodium.gitbook.io/doc/advanced/ed25519-curve25519 for an actual implementation converting Ed25519 to X25519 keys. See also https://www.rfc-editor.org/rfc/rfc7748.html#section-4.1 (citation reference 17, above) for the mapping function(s), though it sounds like you may have already been familiar with it.
Maybe there's some nuance wrt converting public vs private key components I'm ignoring. But libsodium provides routines for converting both public and private Ed25519 keys to X25519 independently--i.e. doesn't require the private Ed25519 key to convert the public key. Because EdDSA is more common and widely deployed than X25519/X448 key exchange (or signing) schemes, Ed25519 -> X25519 is typically the direction you care about, permitting you to preserve or leverage existing public and private key management infrastructure.
Do you have some reason to believe that WolfSSL has suddenly gotten better for some reason?
https://www.wolfssl.com/docs/security-vulnerabilities/
For another, I used them for an embedded project for 5 years and they were the most complete, competent, and up-to-date library of the open-source ones we surveyed (and had a TON of optimizations for TI, STM, Arm and Cavium MCUs).
Also, while I'm fully on board the "Rust as a default userspace systems language," the machine code I've gotten out of trying #[no_std] Rust to write part of a bare-metal project was heinously bloated. This is without even using any non-libcore dependencies! Something like 3/4s of the machine instructions looked like they were related to building error messages for panics, despite the fact that there shouldn't have been any reachable panics (and the code was small and simple enough that I expected LLVM to be able to reason about this without any MIR-level optimizations).
Maybe this would be better on a project that could use rustc as its linker, but based on this, I wouldn't necessarily recommend that a bare-metal library intended to be linked to C and hand-written assembly be written in Rust versus, say, verified with Frama-C or other C-specific tools.
As you're likely aware, Rust for embedded sucks when there's no HAL, but should be pretty pleasant otherwise. Have you looked into the cortex-a[1] crate?
Some unnecessary instructions could also be a part of an ongoing optimization effort[2][3].
[1]: https://github.com/rust-embedded/cortex-a
[2]: https://old.reddit.com/r/rust/comments/yn6105/optimization_o...
People like C. I like C. I like Rust too but I like C more.
“I like C” won’t sound so good when someone finds an out of bounds exploit on your car update mechanism and manages to load a malicious firmware.
No: not if you avoid memory-unsafe functions. The language does not automatically introduce vulnerabilities.
C has a much smaller footprint and runs on thousands of architectures unsupported by other languages.
heres a shotgun with a hair trigger, now you be careful! shoots face off
C and assembly were the only options. Zig didn't exist back then.