q not derived from d in gcry_pk_sign

[Werner Koch]

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.  */
  struct gcry_context
  {
    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. */
    PROPERLY_ALIGNED_TYPE u;
  };

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
interface.

> 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.


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.