AES + Integration with `Io`

jordan commented

2023-11-01 12:25:32 +00:00

Owner

While it may not strictly be necessary for Telodendria, I think it would be cool to have an AES implementation in Cytoplasm. We should also add an IoAes API which allows streams to be encrypted on the fly using GCM.

Attached is the official NIST specification.

While it may not strictly be necessary for Telodendria, I think it would be cool to have an AES implementation in Cytoplasm. We should also add an `IoAes` API which allows streams to be encrypted on the fly using GCM. Attached is the official NIST specification.

NIST.FIPS.197-upd1.pdf

1.1 MiB

jordan added the

enhancement

label 2023-11-04 19:34:52 +00:00

uis commented

2023-12-02 17:22:37 +00:00

I don't think touching crypto is good idea. Maybe use implementation from TLS library?

jordan commented

2023-12-05 13:05:18 +00:00

Author

Owner

Everyone says not to touch crypto, but somebody has to do it, and honestly it isn't that hard. Conceptually it is not difficult to understand, and the specifications are very thorough. There are also plenty of good, high-quality test suites that can verify the correctness of an implementation.

This for sure isn't something that would replace the already-existing TLS implementations we support in Cytoplasm. It would just be a fun exercise, although someday I would definitely love to implement a TLS library. Understanding cryptography is really important. It's critical for our digital safety and privacy. I think knowing how it works is a good thing because everyone relies on it so heavily and if only a few people understand it, that sounds dangerous.

So I think touching crypto is a great idea. A low-priority idea that I probably won't be able to get to for a long time, but a good idea nonetheless.

Everyone says not to touch crypto, but *somebody* has to do it, and honestly it isn't that hard. Conceptually it is not difficult to understand, and the specifications are very thorough. There are also plenty of good, high-quality test suites that can verify the correctness of an implementation. This for sure isn't something that would replace the already-existing TLS implementations we support in Cytoplasm. It would just be a fun exercise, although someday I would definitely love to implement a TLS library. Understanding cryptography is really important. It's critical for our digital safety and privacy. I think knowing how it works is a good thing because everyone relies on it so heavily and if only a few people understand it, that sounds dangerous. So I think touching crypto is a great idea. A low-priority idea that I probably won't be able to get to for a long time, but a good idea nonetheless.

lda commented

2024-11-22 12:29:00 +00:00

Contributor

I don't think touching crypto is good idea. Maybe use implementation from TLS library?

I do believe that if we ever have to do it, we should be extremely careful to get the implementation right (as one that wouldn't can, both in theory and practice leak information about keys through side-channels), and ideally use the TLS library's version if possible, for speed (with modern processors having dedicated instructions for basic AES operations that we cannot use), size (TBF, an AES implementation doesn't seem too heavy, but may as well cut down space), and security (see the point I made about leaking information).

An AES implementation could also mean a pretty decent (still not as perfect as something like /dev/random, but a pretty good last resort) secure random number generator too with CTR-DRBG, which would be highly important for projects that need to have good randomness, like Telodendria would for signatures (This would also require having a CTR mode, which would be also useful for e.g Matrix clients, since files can be encrypted with that mode)

> I don't think touching crypto is good idea. Maybe use implementation from TLS library? I do believe that if we ever have to do it, we should be *extremely careful* to get the implementation right (as one that wouldn't can, both in theory **and** practice leak information about keys through side-channels), and ideally use the TLS library's version if possible, for speed (with modern processors having dedicated instructions for basic AES operations that we cannot use), size (TBF, an AES implementation doesn't seem too heavy, but may as well cut down space), and security (see the point I made about leaking information). An AES implementation could also mean a pretty decent (still not as perfect as something like `/dev/random`, but a pretty good last resort) **secure** random number generator too with CTR-DRBG, which would be highly important for projects that *need* to have good randomness, like Telodendria would for signatures (This would also require having a CTR mode, which would be also useful for e.g Matrix clients, since files can be encrypted with that mode)

jordan commented

2024-11-24 19:31:28 +00:00

Author

Owner

Yep, that was kind of my thoughts as well. Interestingly enough, I was just thinking about /dev/random a few days ago, and since it is implemented on pretty much every operating system, it might be worth using instead of our current random code, even if it isn't necessarily POSIX. Thoughts?

Yep, that was kind of my thoughts as well. Interestingly enough, I was just thinking about `/dev/random` a few days ago, and since it is implemented on pretty much every operating system, it might be worth using instead of our current random code, even if it isn't necessarily POSIX. Thoughts?

lda commented

2024-12-03 15:08:37 +00:00

Contributor

it might be worth using instead of our current random code, even if it isn't necessarily POSIX. Thoughts?

I don't think getting rid of the old Rand code is a good thing. As you said /dev/random may not even exist, but even if it does, it still can block in cases where entropy is not low, and I think there are scenarios where using Rand is good enough as-is, and where /dev/random may actually be harmful due to blocking. (e.g: non-cryptographic tasks)

I believe we should just go and add a set of cryptographic RNG functions(that can use /dev/random if possible), and just keep Rand as-is (or at least, keep a way to generate non-cryptographic numbers somehow)

> it might be worth using instead of our current random code, even if it isn't necessarily POSIX. Thoughts? I don't think getting rid of the old `Rand` code is a good thing. As you said `/dev/random` may not even exist, but even if it does, it still *can* block in cases where entropy is not low, and I think there are scenarios where using `Rand` is **good enough as-is**, and where `/dev/random` may actually be harmful due to blocking. (e.g: non-cryptographic tasks) I believe we should just go and add a set of cryptographic RNG functions(that *can* use `/dev/random` if possible), and just keep `Rand` as-is (or at least, keep a way to generate non-cryptographic numbers somehow)

AES + Integration with Io #7

AES + Integration with `Io` #7