3 ms·

How does Libsodium compares with Crypto++[1] now? Wei Dai [2] is a highly reputable engineer. [1] https://github.com/weidai11/cryptopp https://github.com/weida

by wslh 2y ago

How does Libsodium compares with Crypto++[1] now? Wei Dai [2] is a highly reputable engineer. [1] https://github.com/weidai11/cryptopp https://github.com/weidai11/cryptopp [2] https://en.wikipedia.org/wiki/Wei_Dai https://en.wikipedia.org/wiki/Wei_Dai

awaythrow999 2y ago
Because extending trust usually works retrospectively? Or which battle tested applications exist today using crypto+, that illustrate it's a better choice than what sofar held up under libsodium (which is a lot)?
- wslh 2y ago
  My comment was intended to be constructive, not to spark a flamewar. If you compare Crypto++ and Libsodium, you’ll notice they were created in different decades. This reflects that, at one point, C++ developers predominantly used Crypto++, while later, Libsodium emerged as an alternative.
adastra22 2y ago
I’m not casting shade on anyone, but “highly reputable engineer” is not how I would describe Wei Dai. “Early thinker in this field, respected for his opinions” might be more accurate. Especially if you are directly comparing against libsodium and Daniel Bernstein who is a widely respected engineer whose work is widely used and heavily reviewed.
- wslh 2y ago
  Daniel Bernstein is not the creator of libsodium. Libsodium is based on his work on <https://nacl.cr.yp.to/ https://nacl.cr.yp.to/> which is not the same.
  - wolf550e 2y ago
    Frank Denis, maintainer of libsodium, is also a reputable engineer.
  - adastra22 2y ago
    Libsodium is a fork of nacl.
    - tptacek 2y ago
      It's certainly not the same as Nacl. But I'd reiterate: the point here isn't trust in the library's author. It's the intent of the library.
tptacek 2y ago
The MSB on these libraries isn't the author, but rather the intent of the library. Libsodium is designed to get you to basic core cryptographic functionality with the fewest possible landmines. Crypto++ is designed to be an interface to the maximum number of constructions and primitives. Those are radically different goals, and almost everybody is better served by the former.
- blacklion 2y ago
  For me, libsodium has one problem... grr... not exactly problem, but peculiarity, which is not mentioned in docs anywhere. libsodium doesn't put any metadata (including library and/or construction "version") in any its results, like boxes, keys, etc. So, there is no mechanism for versioning and backward compatibility. So, it is so-so Ok for real time communication between two installations of software product (and even then two ends could have different versions of software and/or library used!), but it is not suitable for long-time storage or communication between different systems. You store your "boxed" backup [keys] on disk. You want to read it 15 years later. How could you be sure, that libsodium didn't change algorithms in these 15 years? You need exactly same version of library that created this "box". And even application which is aware of this problem could not properly solve this: it could record & check libsodium version and refuse to work with "old" data, but how could it enforce future libsodium to read product of old one, as there is no any provision for this in API? libsodium is too simple for many tasks.
  - comex 2y ago
    Has libsodium actually made backward incompatible changes to its formats?
    - blacklion 2y ago
      Not YET, but there are no any promises too. New API like secretstream includes algo into API names, so, I hope, it is "stable forever", but it is rather new feature. Basic APIs like "crypto_secretbox" are "black boxes" and there are no any guarantees spelled out. Algorithms are mentioned in documentation, though. What will do libsodium if used algorithm will be broken? I don't know.

by wslh 2y ago

awaythrow999 2y ago

Because extending trust usually works retrospectively? Or which battle tested applications exist today using crypto+, that illustrate it's a better choice than what sofar held up under libsodium (which is a lot)?

wslh 2y ago
My comment was intended to be constructive, not to spark a flamewar. If you compare Crypto++ and Libsodium, you’ll notice they were created in different decades. This reflects that, at one point, C++ developers predominantly used Crypto++, while later, Libsodium emerged as an alternative.

adastra22 2y ago

I’m not casting shade on anyone, but “highly reputable engineer” is not how I would describe Wei Dai. “Early thinker in this field, respected for his opinions” might be more accurate. Especially if you are directly comparing against libsodium and Daniel Bernstein who is a widely respected engineer whose work is widely used and heavily reviewed.

wslh 2y ago
Daniel Bernstein is not the creator of libsodium. Libsodium is based on his work on <https://nacl.cr.yp.to/ https://nacl.cr.yp.to/> which is not the same.
- wolf550e 2y ago
  Frank Denis, maintainer of libsodium, is also a reputable engineer.
- adastra22 2y ago
  Libsodium is a fork of nacl.
  - tptacek 2y ago
    It's certainly not the same as Nacl. But I'd reiterate: the point here isn't trust in the library's author. It's the intent of the library.

tptacek 2y ago

The MSB on these libraries isn't the author, but rather the intent of the library. Libsodium is designed to get you to basic core cryptographic functionality with the fewest possible landmines. Crypto++ is designed to be an interface to the maximum number of constructions and primitives. Those are radically different goals, and almost everybody is better served by the former.

blacklion 2y ago
For me, libsodium has one problem... grr... not exactly problem, but peculiarity, which is not mentioned in docs anywhere. libsodium doesn't put any metadata (including library and/or construction "version") in any its results, like boxes, keys, etc. So, there is no mechanism for versioning and backward compatibility. So, it is so-so Ok for real time communication between two installations of software product (and even then two ends could have different versions of software and/or library used!), but it is not suitable for long-time storage or communication between different systems. You store your "boxed" backup [keys] on disk. You want to read it 15 years later. How could you be sure, that libsodium didn't change algorithms in these 15 years? You need exactly same version of library that created this "box". And even application which is aware of this problem could not properly solve this: it could record & check libsodium version and refuse to work with "old" data, but how could it enforce future libsodium to read product of old one, as there is no any provision for this in API? libsodium is too simple for many tasks.
- comex 2y ago
  Has libsodium actually made backward incompatible changes to its formats?
  - blacklion 2y ago
    Not YET, but there are no any promises too. New API like secretstream includes algo into API names, so, I hope, it is "stable forever", but it is rather new feature. Basic APIs like "crypto_secretbox" are "black boxes" and there are no any guarantees spelled out. Algorithms are mentioned in documentation, though. What will do libsodium if used algorithm will be broken? I don't know.