ezcrypt

Tried box64 on a Raspberry Pi 5 the other day and it worked above expectations. Except for a minor glitch with OGG audio, I got about 60 FPS in Xonotic (x86_64 emulated on AArch64).

For the record: The latest release of ezcrypt (v1.3.0) has poly1305 authentication. Thanks for the feedback!

Very interesting! Thanks for the link, I didn't know about it and I'll have to check it out.

It still falls slightly outside of my zone of preference, though, as it's a .Net application, which limits which platforms it can be run on (I'm aiming for a tool that can readily be used on most of my devices, including on an old Raspberry Pi or a router).

"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.

Thanks for having a look. The software implementation of AES is actually mostly a copy-paste of https://github.com/kokke/tiny-AES-c (see 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.

If it's the AxCrypt I think it is, it doesn't even run on Linux, never mind Raspberry PI or Milk-V for instance. And it's not free either. So it doesn't meet many of my requirements, unfortunately.

Can you use PGP in the same way (I haven't tried)? Basically, symmetric file encryption based on a secret password and optionally a secret pepper file (effectively a secret key).

No, I realize that (I was thinking that ssh-keygen could be used as a poor-man's authentication for some use cases - basically share a secret between sender & receiver that can be used to ensure that the message has not been tampered with). One of the reasons that I haven't implemented authentication yet is that I want to better understand the differences and nuances of different methods and use cases before deciding on a method. Recommendations are welcome.

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. ;-)

That's pretty much spot on. Authentication is planned (and that should handle truncation too if I'm not mistaking): https://codeberg.org/ezcrypt/ezcrypt/issues/3

Very good point!

I have been planning to look into authentication. I didn't need it for my use cases, yet, but as you say that should be an integral part of any serious tool. I added a ticket: https://codeberg.org/ezcrypt/ezcrypt/issues/3

In the meantime, signing and verification can be done separately, e.g. with ssh-keygen, although that is a bit inconvenient (which kind of defeats one of the key points of the tool).

This should be the top rated comment ;-) Sorry. I can't remedy the situation for you, though.

All good points. I intend to make it clearer: https://codeberg.org/ezcrypt/ezcrypt/issues/4

The idea isn't really to make the encryption stronger or to widen the key. It's a classical case of trust - if one cipher is compromised, there are others to cover for you. Also, I wanted to learn the different ciphers, and speed wasn't a top priority.

I also recommend the video by SimonDev: Exploring a New Approach to Realistic Lighting: Radiance Cascades <https://www.youtube.com/watch?v=3so7xdZHKxw>

(I recently discovered his channel, and I like his calm down-to-earth explanations of game dev techniques).

In this case I think it's mostly about using different sub-carriers (kind of a "channel in the channel"), so that the data information and the audio are separated in frequency and do not disturb each other. That's generally called Frequency Division Multiple Access (FDMA), IIRC.

Another more advanced technique is Code Division Multiple Access (CDMA), e.g. used by GPS and some mobile communication modulation schemes. It allows you to have multiple senders on a single radio carrier frequency, and the receiver "selects" which sender to listen to by knowing its "code".

There's also Time Division Multiple Access (TDMA), i.e. senders take turns sending content in allocated time slots.

Is the Finnish bus stop timetable data channel well documented, though? Not sure, maybe it is?

I mean, she was pretty clear about why she found the signal, and that she read the RDS documentation in order to decode it, etc.

I think the more fun part was towards the end, when she brute-forced decryption keys for traffic information coordinates and also found the (AFAIK) non-standard Finnish bus stop time table information in another band and reverse-engineered that, and I think that was the takeaway of the talk.

Rather, I don't think the data channel was actually down-shifted, but that it wasn't filtered out (probably due to a broken analog filtering circuit after the fall), so it was still outside of the audible spectrum but available to the sound card and hence visible in her software spectrum analyzer. It also sounded like she was seeing some aliasing effect, i.e. that the data signal was probably out of band for the sound card ADC, but "folded" down into the sampler frequency range due to Nyquist folding "magic" (which is maybe what you meant with "down-shifting", now that I think about it?).

I actually find it a bit surprising that they have not used AES-NI until now, as it has been around for over a decade. In my experience it's about 2-6x faster than ChaCha20 (I use and benchmark both in <https://codeberg.org/ezcrypt/ezcrypt>), which ought to be a huge benefit for ransomware that needs to encrypt the data as quickly as possible (before someone pulls the plug).

I get that portability and robustness across a wide range of targets is key for software like this (and as such ChaCha20 is a good choice as it's the fastest algorithm for pure software implementation, given same level of encryption strength), but the solution used by Qilin.B seems like a no-brainer (prefer AES-NI but fall back to ChaCha20 for ancient machines).

Edit: I also find the title misleading. AES-256 isn't really "stronger" than ChaCha20, it's only faster when the CPU has the AES-NI extension.