starred/hickory-dns

Fork 0

mirror of https://github.com/hickory-dns/hickory-dns.git synced 2026-04-24 18:55:55 +03:00

[GH-ISSUE #180] When ring feature is enabled, use it for RSA and other supported DNSSec proofs #384

New issue

Open

opened 2026-03-15 22:13:08 +03:00 by kerem · 10 comments

kerem commented

2026-03-15 22:13:08 +03:00

Owner

Originally created by @bluejekyll on GitHub (Aug 24, 2017).
Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/180

As of now, all RSA and ECDSA proofs are performed with OpenSSL. It would be good to remove the dependency on OpenSSL entirely but allow RSA to be proved with the ring library.

Originally created by @bluejekyll on GitHub (Aug 24, 2017). Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/180 As of now, all RSA and ECDSA proofs are performed with OpenSSL. It would be good to remove the dependency on OpenSSL entirely but allow RSA to be proved with the *ring* library.

kerem added the

enhance

trust

crate:client

labels

2026-03-15 22:13:08 +03:00

kerem commented

2026-03-15 22:13:19 +03:00

Author

Owner

@briansmith commented on GitHub (Sep 22, 2017):

I started working on this in #194, #195, #196, and #198.

I found that create_sig0_ready_client, test_rrset_tbs, create_secure_example, test_sign_and_verify_message_sig0(), and test_sign_and_verify_rrset() are still generating their own private keys, which makes it hard to adapt them to work with ring, since ring doesn't do keygen itself. keygen is really a server-side feature, not a client-side feature, so it would be better to eliminate the need for keygen in these client-side tests. However, I probably won't have time to do that conversion myself.

However, once that conversion is done, I will be able to finish the work to make the entire client side (verification side) work with ring, including RSA, ECDSA, Ed25519.

Note that ring will reject small public RSA keys (less than 2048 bits), but I think that this is the best behavior anyway. People who want legacy stuff to work can use legacy crypto libraries.

@briansmith commented on GitHub (Sep 22, 2017): I started working on this in #194, #195, #196, and #198. I found that `create_sig0_ready_client`, `test_rrset_tbs`, `create_secure_example`, `test_sign_and_verify_message_sig0()`, and `test_sign_and_verify_rrset()` are still generating their own private keys, which makes it hard to adapt them to work with *ring*, since *ring* doesn't do keygen itself. keygen is really a server-side feature, not a client-side feature, so it would be better to eliminate the need for keygen in these client-side tests. However, I probably won't have time to do *that* conversion myself. However, once that conversion is done, I will be able to finish the work to make the entire client side (verification side) work with *ring*, including RSA, ECDSA, Ed25519. Note that *ring* will reject small public RSA keys (less than 2048 bits), but I think that this is the best behavior anyway. People who want legacy stuff to work can use legacy crypto libraries.

kerem commented

2026-03-15 22:13:24 +03:00

Author

Owner

@briansmith commented on GitHub (Sep 22, 2017):

Also #199.

@briansmith commented on GitHub (Sep 22, 2017): Also #199.

kerem commented

2026-03-15 22:13:29 +03:00

Author

Owner

@briansmith commented on GitHub (Sep 22, 2017):

Removing key generation from the tests is already filed as a separate issue: #134.

@briansmith commented on GitHub (Sep 22, 2017): Removing key generation from the tests is already filed as a separate issue: #134.

kerem commented

2026-03-15 22:13:34 +03:00

Author

Owner

@briansmith commented on GitHub (Sep 23, 2017):

Now also RSA verification: PR #203.

@briansmith commented on GitHub (Sep 23, 2017): Now also RSA verification: PR #203.

kerem commented

2026-03-15 22:13:39 +03:00

Author

Owner

@briansmith commented on GitHub (Sep 24, 2017):

Also TrustAnchor: #204.

@briansmith commented on GitHub (Sep 24, 2017): Also TrustAnchor: #204.

kerem commented

2026-03-15 22:13:44 +03:00

Author

Owner

@briansmith commented on GitHub (Sep 24, 2017):

Ideally a ring-enabled client would build and be testable without OpenSSL. One way of accelerating that process is by implementing the change in #205, which proposes moving signing/private-key operations to the server crate and using pregenerated responses for testing signature verification in the client crate. IMO it makes more sense to do this now than to just fix #134, because keygen isn't the only server-specific functionality that has OpenSSL dependencies, and because #205 seems like the right thing to do, long-term.

@briansmith commented on GitHub (Sep 24, 2017): Ideally a *ring*-enabled client would build and be testable without OpenSSL. One way of accelerating that process is by implementing the change in #205, which proposes moving signing/private-key operations to the server crate and using pregenerated responses for testing signature verification in the client crate. IMO it makes more sense to do this now than to just fix #134, because keygen isn't the only server-specific functionality that has OpenSSL dependencies, and because #205 seems like the right thing to do, long-term.

kerem commented

2026-03-15 22:13:50 +03:00

Author

Owner

@briansmith commented on GitHub (Oct 24, 2017):

This was done and this should be closed. #134 can track making the tests work when ring is used and OpenSSL isn't available.

@briansmith commented on GitHub (Oct 24, 2017): This was done and this should be closed. #134 can track making the tests work when *ring* is used and OpenSSL isn't available.

kerem commented

2026-03-15 22:13:55 +03:00

Author

Owner

@briansmith commented on GitHub (May 31, 2018):

ring now has ECDSA signing support, so ECDSA signing should be made to use ring when ring is enabled: https://github.com/briansmith/ring/issues/207#issuecomment-393662940

@briansmith commented on GitHub (May 31, 2018): *ring* now has ECDSA signing support, so ECDSA signing should be made to use *ring* when *ring* is enabled: https://github.com/briansmith/ring/issues/207#issuecomment-393662940

kerem commented

2026-03-15 22:14:00 +03:00

Author

Owner

@bluejekyll commented on GitHub (May 31, 2018):

I just saw that land! Awesome!

@bluejekyll commented on GitHub (May 31, 2018): I just saw that land! Awesome!

kerem commented

2026-03-15 22:14:05 +03:00

Author

Owner

@bluejekyll commented on GitHub (Sep 23, 2018):

This should be relatively straightforward to implement now. I think it's just the RSA variants that need to be added to the KeyPair at this point.

@bluejekyll commented on GitHub (Sep 23, 2018): This should be relatively straightforward to implement now. I think it's just the RSA variants that need to be added to the KeyPair at this point.

kerem referenced this issue

2026-03-16 02:04:19 +03:00

[PR #384] [MERGED] upgrade toml to .4 #1400