Start optionally using the SHA implementation from the existing crypto API #44

lda · 2024-08-16T16:33:00Z

lda commented

2024-08-16 16:33:00 +00:00

Those are probably faster and more secure than the default one. The older implementation still stays when no good TLS library can provide its SHA functions.

Keeping this as a WIP since I'm not 100% sure it compiles on LibreSSL, but can't test as of now. If anyone has the time to do so, please let me know.

Those are probably faster and more secure than the default one. The older implementation still stays when no good TLS library can provide its SHA functions. Keeping this as a WIP since I'm not 100% sure it compiles on LibreSSL, but can't test as of now. If anyone has the time to do so, please let me know.

lda added 2 commits 2024-08-16 16:33:01 +00:00

[MOD/WIP] Get SHA to use Open/LibreSSL if present 3843a8d114

I still haven't tested on LibreSSL (Debian doesn't seem to actually like
it all that much), but manuals seems to state that they're the same in
that regard. If anyone is up to verify, let me know so that I'm aware
it's safe to merge it.

[FIX/WIP] Don't include Log. e8543bdb2a

lda added 1 commit 2024-08-16 16:33:14 +00:00

Merge branch 'master' into opt-ssl-for-sha c7204f316c

jordan commented

2024-08-18 23:22:00 +00:00

Faster, yes, probably.

More secure, probably not. It's just an algorithm. Unless I didn't implement it properly, it should be just as secure as the TLS library's. Anyone can audit the code if they want. As far as I can tell, it is implemented properly, but I'm always open to being corrected.

That being said, I have no problem with this pull request at all. I'll happily merge it once we verify it can compile with LibreSSL. I unfortunately am not in the position to verify this for myself, as I'm on mostly Linux systems these days that have OpenSSL.

Faster, yes, probably. More secure, probably not. It's just an algorithm. Unless I didn't implement it properly, it should be just as secure as the TLS library's. Anyone can audit the code if they want. As far as I can tell, it is implemented properly, but I'm always open to being corrected. That being said, I have no problem with this pull request at all. I'll happily merge it once we verify it can compile with LibreSSL. I unfortunately am not in the position to verify this for myself, as I'm on mostly Linux systems these days that have OpenSSL.

jordan reviewed 2024-08-23 20:22:15 +00:00

src/Sha/Sha1.c Outdated

					
				@ -28,6 +28,26 @@

				#include <limits.h>

				#if (TLS_IMPL == TLS_OPENSSL) || (TLS_IMPL == TLS_LIBRESSL)

jordan commented

2024-08-23 20:22:15 +00:00

If you just say #if (TLS_IMPL == TLS_OPENSSL) and get rid of the LibreSSL check, then this will only be applied with OpenSSL, which you verified to work. We can then merge this and add back LibreSSL support later after we verify it is working.

If you just say `#if (TLS_IMPL == TLS_OPENSSL)` and get rid of the LibreSSL check, then this will only be applied with OpenSSL, which you verified to work. We can then merge this and add back LibreSSL support later after we verify it is working.

lda marked this conversation as resolved

lda added 2 commits 2024-08-23 20:46:15 +00:00

Merge branch 'master' of https://git.telodendria.io/Telodendria/Cytoplasm into opt-ssl-for-sha d00dcc9b50

[MOD] Drop LibreSSL "support" in SHA for now 7752ea7b86

We'll test later...

lda changed title from ~~WIP: Start optionally using the SHA implementation from the existing crypto API~~ to Start optionally using the SHA implementation from the existing crypto API

2024-08-23 20:46:26 +00:00

jordan merged commit f5ce4f5238 into master

2024-08-24 17:06:05 +00:00

jordan referenced this pull request from a commit

2024-08-24 17:06:07 +00:00

Merge pull request 'Start optionally using the SHA implementation from the existing crypto API' (#44) from lda/Cytoplasm:opt-ssl-for-sha into master

Sign in to join this conversation.

No reviewers