Keypair generation, storage

[Sergi Blanch i Torné]

Hi,

I did something similar in my research project, if you like you can
reuse it. Now, we continue with the development, and we will release a
new patch shortly:
http://alumnes.eps.udl.es/%7Ed4372211/index.en.html

El dj 20 de 01 del 2005 a les 14:22 +0100, en/na Pierre Doucy va
escriure:
> Hi all,
> 
> as part of a school project, I'm implementing the X9.62 (ECDSA)
> algorithm into gnupg.
> I've done quite well until now, but I have a few questions now :
> 
> 1) I'va had segfaults in the do_fingerprint_md function (which does
> something with the public key) for quite a while, until I realised
> that the "public key" it uses is retrieved that way :
> 
>     for( i=0; i < npkey; i++ )
>         pk.pkey[i] = sk->skey[i];
> 
> which I thought was a little bit silly at first. Then I realised that
> all the other algorithms constructed their private keys as an array
> containing all the public parameters, then the private parameters.
> Can anyone explain me the rationale for this ?

Explain why the private key have the public parameters? For me is easy.
For example, when your funtion 'sign()' are called, only need to use one
struct. Over Elliptic Curves you could have a cryptosystem setup
{p,a,b,G,n,h}, a secret key {d}, and public one {P=[d]G}; it will have
sense to save separatelly in the smardcards case (other way the struct
will be huge).

It's an answer for your, or it say a delirium.
> 
> 2) Now that I've corrected the last problem, my key generation
> routines seem to work well, but when
> $ gpg --gen-key
> [...]
> 
> I get the following error :
> 
> gpg: Ohhhh jeeee: can't encode a 160 bit MD into a 255 bits frame
> secmem usage: 2304/3232 bytes in 7/11 blocks of pool 3328/32768
> Abort trap
> 
> Can anyone give me a hint on what this means and how I can correct
> this ? I know it happens in do_encode_md :
> 
> do_encode_md( MD_HANDLE md, int algo, size_t len, unsigned nbits,
>               const byte *asn, size_t asnlen, int v3compathack )
> {
>     int nframe = (nbits+7) / 8;
>     [...]
> 
>     if( len + asnlen + 4  > nframe )
>         log_bug("can't encode a %d bit MD into a %d bits frame\n",
>                     (int)(len*8), (int)nbits);
> 
> 
> but I really don't understand what's going on here. Any idea ?

I had the same problem and i find the solution in the function
'encode_md_value()', in the same file 'g10/seskey.c'. This one call your
problematic 'do_encode_md()'. There are an if/else for DSA algorithms,
and you can add your ECDSA.

> 
> Thanks very much in advance.
> 
> Pierre DOUCY

Remember one important think: your algorithm number must be between 101
and 110.

/Sergi.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 202 bytes
Desc: =?ISO-8859-1?Q?Aix=F2?= =?ISO-8859-1?Q?_=E9s?= una part
	d'un missatge, signada digitalment
Url : /pipermail/attachments/20050120/f44db634/attachment.pgp