[HN Gopher] Liblithium: A lightweight and portable cryptography ...
___________________________________________________________________
Liblithium: A lightweight and portable cryptography library
Author : todsacerdoti
Score : 35 points
Date : 2022-11-16 20:29 UTC (2 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| sbf501 wrote:
| It is not a crypto library, it is an Ed25519 EdDSA library.
|
| It has nothing else in it apparently.
|
| WolfCrypt is a better solution and is FIPS certified.
|
| EDIT: I didn't know what GIMLI was.
| bsder wrote:
| I seem to remember that WolfSSL had some fairly egregious
| vulnerabilities even while being FIPS certified.
|
| Do you have some reason to believe that WolfSSL has suddenly
| gotten better for some reason?
| lvh wrote:
| No, it's an Ed25519 library _and_ a Gimli library. Gimli can be
| used to make a wide range of functions, including MACs, hashes
| and stream ciphers, just like SHAKE.
|
| (That is not an endorsement.)
| svnpenn wrote:
| Doesn't C have years and years of repeated security flaws due to
| lack of memory safety? What's the motivation to continue
| releasing greenfield projects in C?
| remexre wrote:
| Sounds like this is intended to run on targets rustc would not
| support, given the claim that it "does not assume 8-bit
| addressability".
|
| 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.
| mananaysiempre wrote:
| To be fair, the AVR and STM8 code I've got out of GCC and
| SDCC when feeding them normal (non-8-bitter-adapted) C also
| sucked--though not to the point of building strings--because
| the default promotion to int required by the standard really
| hurts when the minimum required 16-bit int does not fit into
| a register.
| remexre wrote:
| oh, yeah, I can totally imagine that; this was being built
| for AArch64 though; with all the Cortex-A features, even!
| lvh wrote:
| This seems extremely similar to
| https://github.com/jedisct1/libhydrogen -- X25519 and Gimli.
| (well, and the name...). It also appears to pull from its test
| suite and aim for compatibility in some ways.
| TontonNestor wrote:
| I would be careful with Gimli https://eprint.iacr.org/2020/744
| bugfix-66 wrote:
| Published by Tesla?
|
| 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.
| mananaysiempre wrote:
| Judging from the statement (I haven't the cryptographic kung fu
| to distil the paper myself), the attack seems to be more of an
| exploration of how vulnerable the (relatively new) ways the
| Gimli suite builds everything out of a single crypto core can
| be when used badly, not something applicable to the usage
| that's actually specified. Or is that still concerning? (Plus
| it does seem worse than brute force from the numbers given,
| though I can't judge whether that makes it uninteresting in
| general, either.)
| bugfix-66 wrote:
| Yes, you clearly don't understand it. That's ok, but you
| probably shouldn't confuse the issue.
|
| 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._
|
| https://eprint.iacr.org/2017/743
___________________________________________________________________
(page generated 2022-11-16 23:00 UTC)