profile
viewpoint
If you are wondering where the data of this site comes from, please visit https://api.github.com/users/LoupVaillant/events. GitMemory does not store any data, but only uses NGINX to cache data for a period of time. The idea behind GitMemory is simply to give users a better reading experience.

LoupVaillant/Monocypher 383

An easy to use, easy to deploy crypto library

LoupVaillant/Monokex 16

A simpler alternative to the Noise protocol framework.

LoupVaillant/Monocypher-Handshake 9

Secure channels with Monocypher

LoupVaillant/Monocypher-Utils 3

Utilities based on the Monocypher crypto library (encryption, hashing, signing…)

LoupVaillant/single_file_libs 2

List of single-file C/C++ libraries.

LoupVaillant/awesome-cryptography 0

A curated list of cryptography resources and links.

LoupVaillant/libsodium 0

A modern, portable, easy to use crypto library.

LoupVaillant/Monocypher-RNG 0

User space random generator, that uses the Monocypher crypto library.

LoupVaillant/verifpal 0

Cryptographic protocol analysis for students and engineers.

LoupVaillant/wycheproof 0

Project Wycheproof tests crypto libraries against known attacks.

startedLoupVaillant/Monocypher

started time in 5 days

PR opened LoupVaillant/Monocypher

Canonicalize spellings of algorithms

Inspired by this tweet by Jean-Philippe Aumasson. I believe it makes a positive impression to actually spell names correctly.

I didn't touch the code mainly for reasons of not intruding upon @LoupVaillant's territory, but it may be reasonable to also adjust comments and text case output as well.

+86 -86

0 comment

13 changed files

pr created time in 8 days

issue commentLoupVaillant/Monocypher

Possibly wrong context type for the incremental EdDSA init functions

Your proposal changes the function signatures. When compiling Monocypher as C++, the types necessarily become part of the function name (C++ name mangling).

While the Monocypher makefile compiles Monocypher as C, compilation as C++ is also explicitly supported in the README. It therefore follows that it is possible that for an embedded system, Monocypher was compiled as C++ and shipped as part of an SDK. The downstream consumers of the SDK would then have to lock-step upgrade firmware and SDK.

Since we can't rule out that people are in this situation, this is a breaking ABI change but only in C++ compilation.

That's reason enough for a “no” from me.

LoupVaillant

comment created time in 14 days

fork PX4/Monocypher

An easy to use, easy to deploy crypto library

https://monocypher.org

fork in 19 days

startedLoupVaillant/Monocypher

started time in 21 days

startedLoupVaillant/Monocypher

started time in 24 days

PR opened LoupVaillant/Monocypher

doc: Compute secret/public key in some examples

crypto_sign_init_first_pass(3monocypher) gets two initializations of sk and pk. They're long-lived keys, but at least now it's possible to run the example without wondering why nothing works.

+8 -3

0 comment

1 changed file

pr created time in 25 days

startedLoupVaillant/Monocypher

started time in 2 months

startedLoupVaillant/Monocypher

started time in 2 months

startedLoupVaillant/Monocypher

started time in 2 months

issue commentLoupVaillant/Monocypher

Return plaintext even if Poly1305 fails

Nice, thank you for letting me know. I won't make any changes to the Go bindings that you've linked to on Monocypher's homepage, and I'll just create a separate repo with a notice that it is for a specific use case and point users to the unmodified Go bindings for general use. I'll definitely warn users about corruption and intentional modification, although I think most of then are smart enough not to encrypt an executable and then run it. Thanks again for helping me with this issue, I'll close it as it is completed.

HACKERALERT

comment created time in 2 months

issue closedLoupVaillant/Monocypher

Return plaintext even if Poly1305 fails

Hey LoupVaillant. Is there a way to return the plaintext, regardless of whether Poly1305 passes or not (crypto_unlock)? In my file encryption tool, I have an option that lets the user keep a corrupted or modified file after decryption, but it seems Monocypher returns an empty array of 0's if the Poly1305 is not correct. I understand that this is to prevent any security issues, but it would be nice if there was a way to keep the output, because sometimes, my tool is used by people to encrypt valuable photos, and if a byte in the Poly1305 corrupts, then there's no way that Monocypher lets me retrieve the original data.

closed time in 2 months

HACKERALERT

issue commentLoupVaillant/Monocypher

Return plaintext even if Poly1305 fails

Thanks for your detailed explanation. I love how you use the word naughty, I can't think of a better word ;). Thanks for letting me know. I give users the option to encode the output with Reed-Solomon, which prevents most errors, but you know, someone might drop their hard drive (🤦) and try to recover as much as possible. Looking at crypto_unlock_aead here: https://github.com/LoupVaillant/Monocypher/blob/master/src/monocypher.c#L3009, it seems pretty trivial to just remove the return -1; on line 3009, set a boolean on that line, and return -1 at the end if that boolean is true. If I'm not mistaken, then the crypto_chacha20_ctr will run and the plaintext will be populated, and there shouldn't be any security issues apart from potentially some failing tests, as you mentioned. As you're the creator of this library, can you see any potential pitfalls with this? I check for the return code whenever crypto_unlock is used, so everything should be fine.

HACKERALERT

comment created time in 2 months

issue openedLoupVaillant/Monocypher

Return plaintext even if Poly1305 fails

Hey LoupVaillant. Is there a way to return the plaintext, regardless of whether Poly1305 passes or not (crypto_unlock)? In my file encryption tool, I have an option that lets the user keep a corrupted or modified file after decryption, but it seems Monocypher returns an empty array of 0's if the Poly1305 is not correct. I understand that this is to prevent any security issues, but it would be nice if there was a way to keep the output, because sometimes, my tool is used by people to encrypt valuable photos, and if a byte in the Poly1305 corrupts, then there's no way that Monocypher lets me retrieve the original data.

created time in 2 months

startedLoupVaillant/Monocypher

started time in 2 months

startedLoupVaillant/Monocypher

started time in 2 months

startedLoupVaillant/Monocypher

started time in 2 months

startedLoupVaillant/Monocypher

started time in 3 months

issue commentLoupVaillant/Monocypher

[Question] Options for SHA256, ECC

Thank you for the comprehensive reply. I guess for what I am asking I have to look at mbedTLS. By the way, your solution is so elegant. I am not a C programmer but your code is so easy to read. Thank you for the project.

alberk8

comment created time in 3 months

startedLoupVaillant/Monocypher

started time in 3 months

startedLoupVaillant/Monocypher

started time in 3 months

issue openedLoupVaillant/Monocypher

[Question] Options for SHA256, ECC

Hi, I really like your library implementation, just two files pure and simple. Is it possible to include optional, common sha256, ECC kobliz and NIST for signing?. Thank you.

created time in 3 months