4 ms·
The biggest problem for me (note: others may not care or consider that an advantage): implemented in go. I'm however interested in something as small as possib
by acqq 6y ago
The biggest problem for me (note: others may not care or consider that an advantage): implemented in go.
I'm however interested in something as small as possible, with minimal number of dependencies and implemented in C. Yes I know it's an old language with its own issues. But C is the "highest level" I at this moment consider acceptable for something that should be a competition to GPG.
- da_big_ghey 6y agoThat's a potential concern, as C is still probably unrivaled for portability. However, portability is not the only concern. Age also has a spec, so it can be reimplemented in other languages: https://age-encryption.org/v1 https://age-encryption.org/v1 There's already a Rust implementation: https://github.com/str4d/rage https://github.com/str4d/rage
- acqq 6y agoAm I missing something or the existing tests in the repositories both in age and rage aren’t covering the specification? The other languages could be used for the "proof of concept" implementation or with which the additional comparison tests could be performed, but having C as the most important version is unavoidable.
- diegocg 6y agoTo me, writing cryptographic software in a memory unsafe language these days seems a huge mistake.
- acqq 6y agoWhichever your favorite language is, try researching its dependencies used in the cryptographic primitives, especially in the use cases where performance matters. More often than not, what at the end “does the job” is some library written in C (even with the asm parts) or marked with “unsafe” tags. The practice is still different to what the idealists believe.