wolfssh
wolfssh copied to clipboard
Added support for Ed25519 private keys and and X25519 curve.
Can one of the admins verify this patch?
ok to test
@JacobBarthelmeh
I have fixed the github build tests by adding the relevant define guards, however the streaming API, as it stands, is necessary to verify the ed25519 signature. Had I to ifdef that out, there'd be no verification, which implies I would have to reimplement what those functions do. The easiest would be to copy and paste them from wolfcrypto and only compile them if the streaming API is not enabled: would that be a welcome approach?
Alternatively, it could be required that wolfcrypto be compiled with the streaming API enabled for the whole ED25519 functionality to be activated.
For the record, we've configured wolfssl with these parameters:
--enable-keygen 'C_EXTRA_FLAGS=-DWOLFSSL_PUBLIC_MP -DWOLFSSL_RSA_KEY_CHECK' --enable-curve25519 --enable-ed25519 --enable-ed25519-stream --enable-aesctr --enable-sp-math-all --enable-sp
With the implementation requiring ed25519 streaming, ed25519 should not be an option if linked against a wolfSSL library that does not have the streaming feature enabled. Similar to how in wolfssh/internal.h there is a check for if wolfSSL has the NO_RSA macro, and if so disabled RSA code in wolfSSH. There would be a macro like WOLFSSH_NO_ED25519 that picks up on if the streaming macro from wolfssl/option.h is found.
89 #ifdef NO_RSA
90 #undef WOLFSSH_NO_RSA
91 #define WOLFSSH_NO_RSA
92 #endif
With the implementation requiring ed25519 streaming, ed25519 should not be an option if linked against a wolfSSL library that does not have the streaming feature enabled. Similar to how in wolfssh/internal.h there is a check for if wolfSSL has the NO_RSA macro, and if so disabled RSA code in wolfSSH. There would be a macro like WOLFSSH_NO_ED25519 that picks up on if the streaming macro from wolfssl/option.h is found.
89 #ifdef NO_RSA 90 #undef WOLFSSH_NO_RSA 91 #define WOLFSSH_NO_RSA 92 #endif
I've implemented that, but some tests are still not passing and since I cannot access them I am not sure what is going on. Could you give more feedback, please?
I've implemented that, but some tests are still not passing and since I cannot access them I am not sure what is going on. Could you give more feedback, please?
@JacobBarthelmeh, after further analysis, it looks like the api test is failing for lack of Ed25519 support in the client side. Is that correct, as far as you can tell?
I'm taking this over. I going to squash your commits into one commit. I'll rebasing it to the current master branch. Since one of my coworkers has added x25519 key agreement already, so I'll remove that.
Will you mind if I force push an update to this branch?
Will you mind if I force push an update to this branch?
Be my guest, so I need to do anything to allow you?
I'll try soon. I'm still adding the client-side support for Ed25519. I do have the rebase, squash, and cleanup of the server-side done enough. I pruned the Curve25519 KEX as it already exists in wolfSSH.
I squashed this PR into a single commit. I rebased it to the recent master branch fixing the conflicts. I added the missing parts for reading Ed25519 key files and for using in both the client and server. I removed the changes for Curve25519 key exchange as it is already in master added by @anhu.