3 ms·

age is definitely more mature, and as you say, it should probably say somewhere that ezcrypt is still a hobby project (albeit a serious one). Some motives (som

age is definitely more mature, and as you say, it should probably say somewhere that ezcrypt is still a hobby project (albeit a serious one). Some motives (some of which may sound strange, but mattered to me): * Completely public domain. * Without any third party dependencies (not even openssl or similar). * Don't rely on a single cipher (low trust). * Extremely portable (should easily build for and run on anything from an M4 Mac to a Raspberry Pi to an old OpenWRT MIPS router with 32 MB RAM for instance). * Should be easy to use (e.g. no key management, unless you want to), and composable in standard Unix ways (pipes etc). * Security focused, obviously. E.g. software architecture-wise, minimize dependencies, properly manage files, processes and secrets, etc. * Personally: To learn and to build something that I trust. In a way: When the dust settles after the nuclear apocalypse, if you manage to dig out a C compiler, this is your tool. ;-)

tptacek 2y ago
"Don't rely on a single cipher" is an anti-goal, and a reason your hobby project won't be taken seriously. You'd be better off striking it from the list. "Zero dependencies" is also not especially reassuring, as it implies you're using your own cipher implementations (or reference implementations).
- shanusmagnus 2y ago
  > "Don't rely on a single cipher" is an anti-goal, and a reason your hobby project won't be taken seriously. Why?
  - metadat 2y ago
    If unanticipated issues are discovered, end users may not receive the updates in a timely fashion if, for example, the repo owner is the only committer and they're on vacation when the next Heartbleed 0day hits. I am confident and trust the OpenSSL and LibreSSL projects each have multiple folks capable of merging and releasing critical updates. Amazing as he is, Filippo is a single person who presumably has human needs. If he's a Terminator, though, swell, do let me know.
    - shanusmagnus 2y ago
      Ah. I was thinking the critique was about combining different crypto methods in serial; I've heard people say this is a bad idea but have never understood why.
      - tptacek 2y ago
        Mostly it's just that it doesn't accomplish anything.
some_furry 2y ago
> Without any third party dependencies (not even openssl or similar). In your pursuit of "no dependencies", you made a classic blunder: making AES vulnerable to cache-timing attacks. https://codeberg.org/ezcrypt/ezcrypt/src/commit/3268d71e80d377c7be28770cb365a41be35ba032/src/libezcrypt/crypto/aes.c#L166-L184 https://codeberg.org/ezcrypt/ezcrypt/src/commit/3268d71e80d3... I'm not going to review the rest of your code. This is sufficient for me to recommend everyone run the other way screaming.
- ezcrypt 2y ago
  Thanks for having a look. The software implementation of AES is actually mostly a copy-paste of https://github.com/kokke/tiny-AES-c https://github.com/kokke/tiny-AES-c (see https://github.com/kokke/tiny-AES-c/blob/master/aes.c#L189 https://github.com/kokke/tiny-AES-c/blob/master/aes.c#L189 ). I have been meaning to replace and/or improve it. Even moderately modern x86 machines will always take the fast AES-NI path, though.
  - some_furry 2y ago
    "mostly a copy-paste" is also known as a dependency Look to BearSSL for inspiration for how to implement cryptography right
    - ezcrypt 2y ago
      "also known as a dependency" - There are different kinds of dependencies. The ones I'm usually concerned with are the ones that cause you headaches when you try to get the software working on an exotic platform ten years from now. I've developed software for 30+ years, and along the way I have grown a strong disliking to external dependencies (be it Python packages, Boost C++ libraries, 3rd party C libraries or a hefty Mono or Java runtime). Thanks for the reference to BearSSL - it appears to be very much in line with my own preferred design principles.

tptacek 2y ago

"Don't rely on a single cipher" is an anti-goal, and a reason your hobby project won't be taken seriously. You'd be better off striking it from the list. "Zero dependencies" is also not especially reassuring, as it implies you're using your own cipher implementations (or reference implementations).

shanusmagnus 2y ago
> "Don't rely on a single cipher" is an anti-goal, and a reason your hobby project won't be taken seriously. Why?
- metadat 2y ago
  If unanticipated issues are discovered, end users may not receive the updates in a timely fashion if, for example, the repo owner is the only committer and they're on vacation when the next Heartbleed 0day hits. I am confident and trust the OpenSSL and LibreSSL projects each have multiple folks capable of merging and releasing critical updates. Amazing as he is, Filippo is a single person who presumably has human needs. If he's a Terminator, though, swell, do let me know.
  - shanusmagnus 2y ago
    Ah. I was thinking the critique was about combining different crypto methods in serial; I've heard people say this is a bad idea but have never understood why.
    - tptacek 2y ago
      Mostly it's just that it doesn't accomplish anything.

some_furry 2y ago

> Without any third party dependencies (not even openssl or similar). In your pursuit of "no dependencies", you made a classic blunder: making AES vulnerable to cache-timing attacks. https://codeberg.org/ezcrypt/ezcrypt/src/commit/3268d71e80d377c7be28770cb365a41be35ba032/src/libezcrypt/crypto/aes.c#L166-L184 https://codeberg.org/ezcrypt/ezcrypt/src/commit/3268d71e80d3... I'm not going to review the rest of your code. This is sufficient for me to recommend everyone run the other way screaming.

ezcrypt 2y ago
Thanks for having a look. The software implementation of AES is actually mostly a copy-paste of https://github.com/kokke/tiny-AES-c https://github.com/kokke/tiny-AES-c (see https://github.com/kokke/tiny-AES-c/blob/master/aes.c#L189 https://github.com/kokke/tiny-AES-c/blob/master/aes.c#L189 ). I have been meaning to replace and/or improve it. Even moderately modern x86 machines will always take the fast AES-NI path, though.
- some_furry 2y ago
  "mostly a copy-paste" is also known as a dependency Look to BearSSL for inspiration for how to implement cryptography right
  - ezcrypt 2y ago
    "also known as a dependency" - There are different kinds of dependencies. The ones I'm usually concerned with are the ones that cause you headaches when you try to get the software working on an exotic platform ten years from now. I've developed software for 30+ years, and along the way I have grown a strong disliking to external dependencies (be it Python packages, Boost C++ libraries, 3rd party C libraries or a hefty Mono or Java runtime). Thanks for the reference to BearSSL - it appears to be very much in line with my own preferred design principles.