I strongly suggest to implement RSA-CRT hardening, by checking that RSA signature have not been miscomputed accidentally:
https://securityblog.redhat.com/2015/09/02/factoring-rsa-keys-with-tls-perfect-forward-secrecy/ https://people.redhat.com/~fweimer/rsa-crt-leaks.pdf
We did not see any key leaks which could be attributed to Nettle, but I think the added verification is still a reasonable precaution.
Thanks, Florian
Florian Weimer fweimer@redhat.com writes:
I strongly suggest to implement RSA-CRT hardening, by checking that RSA signature have not been miscomputed accidentally:
Thanks for the reminder. I'll add it to the rsa_pkcs1_sign_tr and rsa_decrypt_tr functions. For other RSA secret-key functions, interface issues makes it a bit more difficult.
I've updated the plan for a nettle-3.2 release, http://www.lysator.liu.se/~nisse/nettle/plan.html
Another recent change is that I'm disabling the use of ifunc linking, see https://sourceware.org/ml/libc-help/2015-06/msg00010.html. I hope glibc will be improved to make use of ifunc more reliable, but I haven't really investigated that.
Regards, /Niels
On Wed, Sep 2, 2015 at 4:05 PM, Florian Weimer fweimer@redhat.com wrote:
I strongly suggest to implement RSA-CRT hardening, by checking that RSA signature have not been miscomputed accidentally: https://securityblog.redhat.com/2015/09/02/factoring-rsa-keys-with-tls-perfect-forward-secrecy/ https://people.redhat.com/~fweimer/rsa-crt-leaks.pdf We did not see any key leaks which could be attributed to Nettle, but I think the added verification is still a reasonable precaution.
Unfortunately for most of the functions available in nettle this counter-measure cannot be implemented without changing the API. Said that, there is rsa_pkcs1_sign_tr() which is supposed to be the side-channel resistant version of rsa_pkcs1_sign() and can have this additional check with no changes. I attach a small patch which verifies the output of this signing function.
Niels, what about the rest of the functions? They can protect from neither timing nor fault attacks. I also attach the patch which marks them as such in the manual.
regards, Nikos
On 09/03/2015 11:56 AM, Nikos Mavrogiannopoulos wrote:
That verifies the output of the timing-resistant version of the signing function, to make it also fault-resistant.
Doesn't this leave the miscomputed signature in the output parameter, so that it would still be used by a caller which ignores the return value?
On Thu, Sep 3, 2015 at 12:48 PM, Florian Weimer fweimer@redhat.com wrote:
On 09/03/2015 11:56 AM, Nikos Mavrogiannopoulos wrote:
That verifies the output of the timing-resistant version of the signing function, to make it also fault-resistant.
Doesn't this leave the miscomputed signature in the output parameter, so that it would still be used by a caller which ignores the return value?
Correct, it would be better to set to zero on failure.
Nikos Mavrogiannopoulos n.mavrogiannopoulos@gmail.com writes:
Said that, there is rsa_pkcs1_sign_tr() which is supposed to be the side-channel resistant version of rsa_pkcs1_sign() and can have this additional check with no changes.
What about rsa_decrypt_tr? Does it also need this check? Attacks are a bit harder since even with known plaintext, there's padding that is supposed to be random. But I imagine it's possible with improved attacks that either work with partial knowledge, or exploit weeknesses in the randomness used for padding.
I attach a small patch which verifies the output of this signing function.
Thanks. Some comments below.
Niels, what about the rest of the functions?
Not sure, maybe we can try to deprecate the signing functions. I guess it's possible to "fix" them by recomputing the public key from the private key, but that's a bit awkward, and if the point is to guard against incorrect computations using secret data, maybe one shouldn't trust that computation either.
@@ -46,23 +66,31 @@ rsa_pkcs1_sign_tr(const struct rsa_public_key *pub, size_t length, const uint8_t *digest_info, mpz_t s) {
- mpz_t ri;
- mpz_t ri, m;
- int ret;
- mpz_init(m);
- if (pkcs1_rsa_digest_encode (s, key->size, length, digest_info))
- if (pkcs1_rsa_digest_encode (m, key->size, length, digest_info)) { mpz_init (ri);
_rsa_blind (pub, random_ctx, random, s, ri);
rsa_compute_root(key, s, s);
_rsa_unblind (pub, s, ri);
_rsa_blind (pub, random_ctx, random, m, ri);
rsa_compute_root(key, s, m);
mpz_clear (ri);
if (rsa_verify_res(pub, s, m) == 0)
ret = 0;
else
ret = 1;
return 1;
_rsa_unblind (pub, s, ri);
}mpz_clear (ri);
Maybe factor out a function rsa_compute_root_tr (in particular, that would be useful if we want the same check in rsa_decrypt_tr). And as Florian pointed out, it seems reasonable to set s = 0 on all failure cases.
I've consided if maybe we can just abort() if the check fails, but since we do have a return value, we can just as well use that. And the check can trigger also for an invalid private key, and in that case, an abort() is maybe a bit too unfriendly.
--- /dev/null +++ b/testsuite/rsa-sign-tr.c @@ -0,0 +1,137 @@ +#include "testutils.h"
+#define MSG1 ((uint8_t*)"None so blind as those who will not see") +#define MSG2 ((uint8_t*)"Fortune knocks once at every man's door")
[...]
- test_rsa_tr(&pub, &key, sizeof(MSG1)-1, MSG1, expected);
If this is the only use of test_rsa_tr, maybe put it directly in this file. And it's not obvious from the name if it tests signing or encryption or both.
--- a/testsuite/testutils.c +++ b/testsuite/testutils.c @@ -765,6 +765,48 @@ test_rsa_set_key_1(struct rsa_public_key *pub, }
void +test_rsa_tr(struct rsa_public_key *pub,
struct rsa_private_key *key,
unsigned di_length,
const uint8_t *di,
mpz_t expected)
+{
- mpz_t signature;
- struct knuth_lfib_ctx lfib;
- knuth_lfib_init(&lfib, 1111);
- mpz_init(signature);
- ASSERT(rsa_pkcs1_sign_tr(pub, key,
&lfib, (nettle_random_func *) knuth_lfib_random,
di_length, di, signature));
- if (verbose)
- {
fprintf(stderr, "rsa-pkcs1-tr signature: ");
mpz_out_str(stderr, 16, signature);
fprintf(stderr, "\nrsa-pkcs1-tr expected: ");
mpz_out_str(stderr, 16, expected);
fprintf(stderr, "\n");
- }
- ASSERT (mpz_cmp(signature, expected) == 0);
- /* Try bad data */
- ASSERT (!rsa_pkcs1_verify(pub, 16, "The magick words", signature));
- /* Try correct data */
- ASSERT (rsa_pkcs1_verify(pub, di_length, di, signature));
- /* Try bad signature */
- mpz_combit(signature, 17);
- ASSERT (!rsa_pkcs1_verify(pub, di_length, di, signature));
It would be good to also do a test with an invalid private key, e.g, using p+2 instead of p. That should trigger the new check, so that rsa_pkcs1_sign_tr returns failure and sets s == 0.
--- a/nettle.texinfo +++ b/nettle.texinfo @@ -3646,7 +3646,14 @@ There is currently no support for using SHA224 or SHA384 with @acronym{RSA} signatures, since there's no gain in either computation time nor message size compared to using SHA256 and SHA512, respectively.
-Creation and verification of signatures is done with the following functions: +Creation and verification of signatures is recommended to be done with the following functions. +They provide a side-channel (fault and timing) resistant implementation. +@deftypefun int rsa_pkcs1_sign_tr(const struct rsa_public_key *@var{pub}, const struct rsa_private_key *@var{key}, void *@var{random_ctx}, nettle_random_func *@var{random}, size_t @var{length}, const uint8_t *@var{digest_info}, mpz_t @var{s}); +@deftypefunx int rsa_pkcs1_verify(const struct rsa_public_key *@var{key}, size_t @var{length}, const uint8_t *digest_info, const mpz_t @var{signature});
I wasn't aware that these functions lacked documentation. Good catch. I think we need to say something about the digest_info argument.
I think the rsa_pkcs1_verify function should move to the other verify functions (and be at the top of that list, if it's the recommended one). Side-channel resistance isn't relevant for verify.
And there's an @end deftypefun missing, isn't it?
(We may also need some public functions for constructing digest_infos, a bit like pkcs1_rsa_sha256_encode. But the current internal functions don't fit well with rsa_pkcs1_sign_tr. So the "CRT-hardening" fixes shouldn't block on that).
+Other functions are also available but cannot be used by application that require +a side-channel silent implementation. These are listed below.
For improved side-channel silence, one could also let rsa_compute_root use mpz_powm_sec if available. But the current GMP plans are to not try to provide side-schannel silent functions on the mpz level (mpz_powm_sec is an exception), so to really take advantage of GMP improvements in side-channel silence, one would need to move to using the lower-level mpn interface.
Regards, /Niels
On Fri, Sep 4, 2015 at 8:49 AM, Niels Möller nisse@lysator.liu.se wrote:
Said that, there is rsa_pkcs1_sign_tr() which is supposed to be the side-channel resistant version of rsa_pkcs1_sign() and can have this additional check with no changes.
What about rsa_decrypt_tr? Does it also need this check? Attacks are a bit harder since even with known plaintext, there's padding that is supposed to be random. But I imagine it's possible with improved attacks that either work with partial knowledge, or exploit weeknesses in the randomness used for padding.
The issue with signatures is that you send or store the output once calculated and that can be observed by an adversary. When decrypting I don't think the threat model is the same. At least for the purposes of TLS protecting decryption wouldn't add anything.
Maybe factor out a function rsa_compute_root_tr (in particular, that would be useful if we want the same check in rsa_decrypt_tr).
I don't think that would be necessary (see above for the decrypt function).
- /* Try bad signature */
- mpz_combit(signature, 17);
- ASSERT (!rsa_pkcs1_verify(pub, di_length, di, signature));
It would be good to also do a test with an invalid private key, e.g, using p+2 instead of p. That should trigger the new check, so that rsa_pkcs1_sign_tr returns failure and sets s == 0.
Good idea.
--- a/nettle.texinfo +++ b/nettle.texinfo @@ -3646,7 +3646,14 @@ There is currently no support for using SHA224 or SHA384 with @acronym{RSA} signatures, since there's no gain in either computation time nor message size compared to using SHA256 and SHA512, respectively.
-Creation and verification of signatures is done with the following functions: +Creation and verification of signatures is recommended to be done with the following functions. +They provide a side-channel (fault and timing) resistant implementation. +@deftypefun int rsa_pkcs1_sign_tr(const struct rsa_public_key *@var{pub}, const struct rsa_private_key *@var{key}, void *@var{random_ctx}, nettle_random_func *@var{random}, size_t @var{length}, const uint8_t *@var{digest_info}, mpz_t @var{s}); +@deftypefunx int rsa_pkcs1_verify(const struct rsa_public_key *@var{key}, size_t @var{length}, const uint8_t *digest_info, const mpz_t @var{signature});
I wasn't aware that these functions lacked documentation. Good catch. I think we need to say something about the digest_info argument.
I think the rsa_pkcs1_verify function should move to the other verify functions (and be at the top of that list, if it's the recommended one).
Would that make sense if we deprecate everything else? I thought that everything else is deprecated first should be listed the recommended functions, rather than trying to look for them within a very long list of deprecated functions.
Side-channel resistance isn't relevant for verify.
I made that clear.
(We may also need some public functions for constructing digest_infos, a bit like pkcs1_rsa_sha256_encode. But the current internal functions don't fit well with rsa_pkcs1_sign_tr. So the "CRT-hardening" fixes shouldn't block on that).
That would be indeed useful (though unrelated with this patch set).
+Other functions are also available but cannot be used by application that require +a side-channel silent implementation. These are listed below.
For improved side-channel silence, one could also let rsa_compute_root use mpz_powm_sec if available. But the current GMP plans are to not try to provide side-schannel silent functions on the mpz level (mpz_powm_sec is an exception), so to really take advantage of GMP improvements in side-channel silence, one would need to move to using the lower-level mpn interface.
That's pretty sad. It means that applications couldn't take advantage of that without being rewritten.
In any case the attached patch set should address all your comments.
regards, Nikos
Nikos Mavrogiannopoulos n.mavrogiannopoulos@gmail.com writes:
In any case the attached patch set should address all your comments.
Thanks.
From 9a59ad5a3d96bde3be81c9542328403a958a442d Mon Sep 17 00:00:00 2001 From: Nikos Mavrogiannopoulos nmav@redhat.com Date: Thu, 3 Sep 2015 10:20:37 +0200 Subject: [PATCH 1/3] Enhanced rsa_pkcs1_sign_tr() to protect against HW/software errors
Applied (not yet pushed, though).
From 363c217483f7d92e77d251317642434b5e76e9f0 Mon Sep 17 00:00:00 2001 From: Nikos Mavrogiannopoulos nmav@redhat.com Date: Thu, 3 Sep 2015 10:43:13 +0200 Subject: [PATCH 2/3] testsuite: Added tests for rsa_pkcs1_sign_tr()
Applied with some tweaks, see below.
testsuite/Makefile.in | 2 +- testsuite/rsa-sign-tr.c | 194 ++++++++++++++++++++++++++++++++++++++++++++++++ testsuite/testutils.h | 7 ++ 3 files changed, 202 insertions(+), 1 deletion(-) create mode 100644 testsuite/rsa-sign-tr.c
diff --git a/testsuite/Makefile.in b/testsuite/Makefile.in index 426fe1a..6711628 100644 --- a/testsuite/Makefile.in +++ b/testsuite/Makefile.in @@ -35,7 +35,7 @@ TS_NETTLE_SOURCES = aes-test.c arcfour-test.c arctwo-test.c \ TS_HOGWEED_SOURCES = sexp-test.c sexp-format-test.c \ rsa2sexp-test.c sexp2rsa-test.c \ bignum-test.c random-prime-test.c \
pkcs1-test.c \
pkcs1-test.c rsa-sign-tr.c \ rsa-test.c rsa-encrypt-test.c rsa-keygen-test.c \ dsa-test.c dsa-keygen-test.c \ curve25519-dh-test.c \
This needs a make test-rules, to also update the included .test-rules.make.
I also renamed the file to rsa-sign-tr-test.c, for consistency with the other tests.
diff --git a/testsuite/rsa-sign-tr.c b/testsuite/rsa-sign-tr.c new file mode 100644 index 0000000..fbe8e5c --- /dev/null +++ b/testsuite/rsa-sign-tr.c @@ -0,0 +1,194 @@ +#include "testutils.h" +#include "knuth-lfib.h" +#include "nettle-internal.h"
+#define MSG1 ((uint8_t*)"None so blind as those who will not see") +#define MSG2 ((uint8_t*)"Fortune knocks once at every man's door")
[...]
- test_rsa_sign_tr(&pub, &key, sizeof(MSG1)-1, MSG1, expected);
sizeof here returns sizeof (uint8_t *), which isn't what you want... I'll fix (not done yet).
--- a/testsuite/testutils.h +++ b/testsuite/testutils.h @@ -190,6 +190,13 @@ test_rsa_set_key_1(struct rsa_public_key *pub, struct rsa_private_key *key);
void +test_rsa_tr(struct rsa_public_key *pub,
struct rsa_private_key *key,
unsigned di_length,
const uint8_t *di,
mpz_t expected);
+void
This looks like is a leftover from the previous version of the patch? I dropped this part.
From f932d48c010a0b87260df8757183f6f68b32a726 Mon Sep 17 00:00:00 2001 From: Nikos Mavrogiannopoulos nmav@redhat.com Date: Thu, 3 Sep 2015 11:55:19 +0200 Subject: [PATCH 3/3] doc: mention rsa_pkcs1_sign_tr() and rsa_pkcs1_verify()
I haven't gotten to the docs yet.
Regards, /Niels
Nikos Mavrogiannopoulos n.mavrogiannopoulos@gmail.com writes:
Niels, what about the rest of the functions? They can protect from neither timing nor fault attacks.
I'm considering adding _tr versions on all of them (currently 8 functions). They're going to be just a few lines each, if they use a common helper function like (untested)
int rsa_compute_root_tr(const struct rsa_public_key *pub, const struct rsa_private_key *key, void *random_ctx, nettle_random_func *random, mpz_t x, const mpz_t m) { int res; mpz_t t, c, ri;
mpz_init (t); mpz_init (c);
_rsa_blind (pub, random_ctx, random, c, t, m);
rsa_compute_root (key, c, c);
mpz_powm(t, c, pub->e, pub->n); res = (mpz_cmp(m, t) == 0);
if (res) _rsa_unblind (pub, x, t, c); else mpz_set_ui (x, 0);
mpz_clear (c); mpz_clear (ri);
return res; }
(possibly zeroing of x on failure could be left to the caller, current signature functions also have the error case of pkcs1_rsa_*_encode failing, and set the result to zero in that case. Another reasonable alternative could be to simply leave the result variable unchanged on failure, but I think that requires an additional mpz temporary).
To make it neater, the _rsa_blind and _rsa_unblind functions need an additional argument, but they are clearly marked as internal so I don't think that should cause any problems.
What do you think?
Regards, /Niels
On 09/10/2015 11:13 PM, Niels Möller wrote:
To make it neater, the _rsa_blind and _rsa_unblind functions need an additional argument, but they are clearly marked as internal so I don't think that should cause any problems.
Do you mean they are private because they have leading underscore?
They are listed in the installed header file, after all, and they are exported from the DSO as well.
Florian Weimer fweimer@redhat.com writes:
Do you mean they are private because they have leading underscore?
The leading underscore is a hint. They are private because they are not documented in the manual, and in the header file, they are clearly marked as internal functions.
They are listed in the installed header file, after all, and they are exported from the DSO as well.
There's no attempt to technically prevent applications from accessing internal functions (which might be a bit old fashioned).
Regards, /Niels
nisse@lysator.liu.se (Niels Möller) writes:
I'm considering adding _tr versions on all of them (currently 8 functions). They're going to be just a few lines each, if they use a common helper function
I've pushed ongoing work to the branch rsa-crt-hardening.
To make it neater, the _rsa_blind and _rsa_unblind functions need an additional argument, but they are clearly marked as internal so I don't think that should cause any problems.
And those two functions are now static (file-local) on that branch.
Regards, /Niels
nisse@lysator.liu.se (Niels Möller) writes:
I've pushed ongoing work to the branch rsa-crt-hardening.
And now I've added a couple of new functions. Any comments before I merge this to the master branch? ChangeLog entries below.
The idea is that when we add documentation for the new functions it is easier to discourage use of the old RSA signature functions, which date back to 2003.
Regards, /Niels
2015-09-17 Niels Möller nisse@lysator.liu.se
* rsa-md5-sign-tr.c (rsa_md5_sign_tr, rsa_md5_sign_digest_tr): New file, new functions. * rsa-sha1-sign-tr.c (rsa_sha1_sign_tr, rsa_sha1_sign_digest_tr): Likewise. * rsa-sha256-sign-tr.c (rsa_sha256_sign_tr) (rsa_sha256_sign_digest_tr): Likewise. * rsa-sha512-sign-tr.c (rsa_sha512_sign_tr) (rsa_sha512_sign_digest_tr): Likewise. * rsa.h: Added corresponding prototypes. * Makefile.in (hogweed_SOURCES): Added new files. * testsuite/testutils.c (SIGN): Extend macro to test new functions, and the rsa_*_sign_digest functions. Updated callers.
2015-09-14 Niels Möller nisse@lysator.liu.se
* rsa-sign-tr.c (rsa_blind, rsa_unblind): Moved here, made static, dropped leading underscore. * rsa-blind.c: Deleted file. * rsa.h: Deleted coresponding declarations.
* rsa-decrypt-tr.c (rsa_decrypt_tr): Use rsa_compute_root_tr. Mainly for simplicity and consistency, I'm not aware of any CRT fault attacks on RSA decryption.
* testsuite/rsa-encrypt-test.c (test_main): Added test with invalid private key.
* rsa-sign-tr.c (rsa_compute_root_tr): New file and function. * rsa.h: Declare it. * rsa-pkcs1-sign-tr.c (rsa_pkcs1_sign_tr): Use rsa_compute_root_tr. (rsa_verify_res): Deleted, replaced by rsa_compute_root_tr. * testsuite/rsa-sign-tr-test.c (test_rsa_sign_tr): Check that signature argument is unchanged on failure. * Makefile.in (hogweed_SOURCES): Added rsa-sign-tr.c.
2015-09-13 Niels Möller nisse@lysator.liu.se
* rsa-blind.c (_rsa_blind, _rsa_unblind): Separate source and destination arguments. Updated callers.
On Tue, Sep 15, 2015 at 9:13 PM, Niels Möller nisse@lysator.liu.se wrote:
nisse@lysator.liu.se (Niels Möller) writes:
I'm considering adding _tr versions on all of them (currently 8 functions). They're going to be just a few lines each, if they use a common helper function
I've pushed ongoing work to the branch rsa-crt-hardening.
To make it neater, the _rsa_blind and _rsa_unblind functions need an additional argument, but they are clearly marked as internal so I don't think that should cause any problems.
And those two functions are now static (file-local) on that branch.
I think the best approach is not to export such functions at all if they are not intended to be used. Now it is too late though for that. By the time functions are exported (via the map file), they are part of the ABI. Breaking the ABI it for a security fix is not that nice.
regards, Nikos
On 09/18/2015 11:42 AM, Nikos Mavrogiannopoulos wrote:
On Tue, Sep 15, 2015 at 9:13 PM, Niels Möller nisse@lysator.liu.se wrote:
nisse@lysator.liu.se (Niels Möller) writes:
I'm considering adding _tr versions on all of them (currently 8 functions). They're going to be just a few lines each, if they use a common helper function
I've pushed ongoing work to the branch rsa-crt-hardening.
To make it neater, the _rsa_blind and _rsa_unblind functions need an additional argument, but they are clearly marked as internal so I don't think that should cause any problems.
And those two functions are now static (file-local) on that branch.
I think the best approach is not to export such functions at all if they are not intended to be used. Now it is too late though for that. By the time functions are exported (via the map file), they are part of the ABI. Breaking the ABI it for a security fix is not that nice.
Yes, for distributions, it would be best if the functions remain exported until there is a soname bump for another reason.
Nikos Mavrogiannopoulos n.mavrogiannopoulos@gmail.com writes:
I think the best approach is not to export such functions at all if they are not intended to be used.
I can understand that point of view, but it's not going to happen to Nettle any time soon.
Breaking the ABI it for a security fix is not that nice.
It's possible to do a "security fix-only" release which only enables crt hardening for rsa_pkcs1_sign_tr (basically, your patch from a few weeks ago). Do you think that is motivated? In that case, I agree that we shouldn't make any incompatible changes to internal but visible functions.
My plan has been to *not* do any bug-fix-only relase, but do do a new regular release reasonably soon, including the crt-related improvements, the updated sha3, and possibly some other minor improvements.
As for _rsa_blind, my thinking is that it's a bit bad to change it's behaviour not because it will break applications that misuse internal functions, but because it might break such applications in unovious ways. So I'm now leaning towards simply removing those functions (making them static), which should offending applications fail obviously, with a link failure.
We made similar changes fairly recently (pkcs1_signature_prefix, dropped in the 2.5 release three years ago), and as far as I remember, there were no big problems with that.
Regards, /Niels
On Fri, Sep 18, 2015 at 1:18 PM, Niels Möller nisse@lysator.liu.se wrote:
Nikos Mavrogiannopoulos n.mavrogiannopoulos@gmail.com writes:
I think the best approach is not to export such functions at all if they are not intended to be used.
I can understand that point of view, but it's not going to happen to Nettle any time soon.
Breaking the ABI it for a security fix is not that nice.
It's possible to do a "security fix-only" release which only enables crt hardening for rsa_pkcs1_sign_tr (basically, your patch from a few weeks ago). Do you think that is motivated? In that case, I agree that we shouldn't make any incompatible changes to internal but visible functions. My plan has been to *not* do any bug-fix-only relase, but do do a new regular release reasonably soon, including the crt-related improvements, the updated sha3, and possibly some other minor improvements.
That seems reasonable, but still it doesn't change the fact that this will be a bug fix release, as it will include bug fixes :)
As for _rsa_blind, my thinking is that it's a bit bad to change it's behaviour not because it will break applications that misuse internal functions, but because it might break such applications in unovious ways. So I'm now leaning towards simply removing those functions (making them static), which should offending applications fail obviously, with a link failure.
Why break them at all? The issue is that if you don't bump the so version some programs will stop working in a distribution if nettle is upgraded. Why not make a new symbol which is kept internal, and the old symbol remains exported and is simply a wrapper to the new symbol that keeps compatibility?
We made similar changes fairly recently (pkcs1_signature_prefix, dropped in the 2.5 release three years ago), and as far as I remember, there were no big problems with that.
I think the usage and visibility of nettle has changed much since then. However, it can be that there is no user of this function, or there may be a single user of which you'll break his already shipped program. There is no way you can tell how may programs rely on that. That's why I don't see a reason to break the ABI within a non major release. You may mark this function (and all the other internals) as deprecated [0], and plan for retiring them in the next so version bump. Doing it earlier you take a bet which may or may not affect some users of nettle.
regards, Nikos
[0]. Using __attribute__ ((__deprecated__))
Nikos Mavrogiannopoulos n.mavrogiannopoulos@gmail.com writes:
Why break them at all? The issue is that if you don't bump the so version some programs will stop working in a distribution if nettle is upgraded. Why not make a new symbol which is kept internal, and the old symbol remains exported and is simply a wrapper to the new symbol that keeps compatibility?
I guess I could keep the old (now unused) functions around for backwards compatibility. You make a pretty good argument for that.
However, it can be that there is no user of this function, or there may be a single user of which you'll break his already shipped program. There is no way you can tell how may programs rely on that.
At least codesearch.debian.net indicates no use of nettle's _rsa_blind.
Regards, /Niels
I've haven't had much time for nettle hacking the last few weeks.
My plan now is to merge the changes on the "rsa-crt-hardening" branch, except that I will keep the old _rsa_blind and _rsa_unblind unchanged (and unused, since the new code uses slightly different and static versions), and clearly mark them as deprecated in the header file.
Regards, /Niels
On 10/13/2015 07:23 PM, Niels Möller wrote:
I've haven't had much time for nettle hacking the last few weeks.
My plan now is to merge the changes on the "rsa-crt-hardening" branch, except that I will keep the old _rsa_blind and _rsa_unblind unchanged (and unused, since the new code uses slightly different and static versions), and clearly mark them as deprecated in the header file.
Sounds good to me.
Florian
Florian Weimer fweimer@redhat.com writes:
On 10/13/2015 07:23 PM, Niels Möller wrote:
I've haven't had much time for nettle hacking the last few weeks.
My plan now is to merge the changes on the "rsa-crt-hardening" branch, except that I will keep the old _rsa_blind and _rsa_unblind unchanged (and unused, since the new code uses slightly different and static versions), and clearly mark them as deprecated in the header file.
Sounds good to me.
Done and pushed now.
Regards, /Niels
nettle-bugs@lists.lysator.liu.se