q not derived from d in gcry_pk_sign
wk at gnupg.org
Fri Mar 22 20:20:31 CET 2013
On Fri, 22 Mar 2013 17:26, grothoff at in.tum.de said:
> You might even require the caller to take care of the locking
> (i.e. you must only use each context in one thread at a time).
Yeah sure, that is the nice thing with a contexts (or anchors as IBM
used to call them in the past).
> I like the idea, but I'm not sure about why you'd risk breaking the API;
> in my experience that causes Debian to not update your package for about
> a decade, and that would be unfortunate. Introducing a
The macros will take of most cases except for rare usages, say, using
gcry_pk via dlopen and own prototypes. And even, then we will still
export the old functions for these cases. The just won't have a
prototype in gcrypt.h.
> without causing too much bloat. The existing ABI changes for 1.6 seemed
> minor (i.e. didn't touch GNUnet at all, and we use libgcrypt a lot);
It is a major change, for example the entire _ac_ interface has been
dropped. We have a new SO number and thus you need to re-compile all
software anyway. The advantage is that the rest of the API is mostly
compatible to the old one.
> I'd personally not use a generic context but one specific to the
> primitive and then it would be gcry_ec_sign (gcry_ec_ctx_t, ...),
> even if the interface would not be as generic. If we later need
We already do that:
/* The definition of the generic context object. The public typedef
gcry_ctx_t is used to access it. */
char magic[CTX_MAGIC_LEN]; /* Magic value to cross check that this
is really a context object. */
char type; /* The type of the context (CONTEXT_TYPE_foo). */
void (*deinit)(void*); /* Function used to free the private part. */
The internal function checks that the right context version has been
passed. Sure there is no way for static type checking, but we don't
have this for the s-expression based interface anyway. The nice thing
with the generic context is that we can add more features over time,
even those which are not directly related to a specific context. For
example, it might be useful to have an MPI interface which returns an
error instead of calling the fatal handler. Setting a flag in a context
would allow to change this on a case by case base. And we won't run
into an incompatible API break.
> not sure that'll ever be needed; and if it is, I'd still want the
> low-level EC primitives to not use the generic pk_ctx as then the
> compiler wouldn't bark at passing an RSA ctx to a low-level
You may want to use the same context for both types, they could even be
linked to gether. As I said, it is the same as with the s-expression
> internal. The only visible change to the outside is that ECC calls
> with d and without q would work instead of fail, whereas previously
> they'd fail. So that's pretty much just a bugfix, as no application
> should *rely* on that failure.
It is a grey area. Magically computing missing values often comes to a
surprise for the caller. But, yeah, here we can change it. While
thinking about it, there is another fix due: D is usually in the secure
memory area. Now, by computing Q the MPI subsystems puts Q also into
secure memory, because it can't know that Q is not anymore a sensitive
value. This could easily exhaust the secure memory without a fix.
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
More information about the Gcrypt-devel