Mailing List Archive

> What I don't know now is how to correctly create this 'context'? Everywhere
> this is a 'pointer to void', and I cannot read the how.

Why are you trying to fiddle around with Libgcrypt internals instead of
using the exported programing interface as it is documented in the manual?

Have a look at the manual and the included test programs.

To answer your specific question about the origin of the hash context:
the gcry_md_spec_t structure contains the info about the required size
for the context buffer. This is allocated in md.c and then initialized
with the algorithm-specific initialization function (also contained in
that struct).

Hope that helps,
moritz

On Thursday 01 January 2009 20:44:01 Moritz Schulte wrote:
> > What I don't know now is how to correctly create this 'context'?
> > Everywhere this is a 'pointer to void', and I cannot read the how.
>
> Why are you trying to fiddle around with Libgcrypt internals instead of
> using the exported programing interface as it is documented in the manual?

Yes, probably I am try from the wrong way. I'm writting in the libgcrypt the
elliptic curve encrypt algorithm from the 'ECC in OpenPGP' internet draft. By
the way this code is in, also I can write the methods from module to module
as an external view.

> Have a look at the manual and the included test programs.
>
> To answer your specific question about the origin of the hash context:
> the gcry_md_spec_t structure contains the info about the required size
> for the context buffer. This is allocated in md.c and then initialized
> with the algorithm-specific initialization function (also contained in
> that struct).

I found this, are you talking about the 'gcry_md_context' struct? You answer
more than you think because I was declaring the buffer as a byte array, and
it must be a gcry_md_hd_t? I'm checking it.

> Hope that helps,
> moritz

To avoid future questions and wrong way coding I like to explain what I did by
now. In the cipher/ecc.c, the interface methods ecc_encrypt and ecc_decrypt
are add also with the 'gcry_pk_spec_t', 'pk_extra_spec_t' and the aliases.
Internally also exists the encrypt and decrypt methods but some auxiliaries
are need.

>From the standard I said a 'key derivation function' has to be implemented.
Also in the document is explained, it comes from the Nist SP800-56A. Next
step will be the AESkeyWrap (and the unwrap) from the rfc3394. But this will
be further discussion.

Using this moment, I like to prepare a patch that disturbs yous work at the
minimum. Not like it was on ecdsa, when hundreds of things needs to be
rewritten (not by me). Which communication can be the best?

Really thanks!

/Sergi.

_______________________________________________
Gcrypt-devel mailing list
Gcrypt-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gcrypt-devel

Hi,

Understood, and also I feel little silly, the way is so similar to what was
write for the gnupg-1.4 patch. The encrypt ecc algorithm is very similar to
what we did, but with a couple of details different.

What I write now is similar. I avoid here error checks and memory wipes.

gcry_md_hd_t hd;
int algo;

if (kek_len == 128) algo=GCRY_MD_SHA256;
else if (kek_len == 192) algo=GCRY_MD_SHA384;
else if (kek_len == 256) algo=GCRY_MD_SHA512;
else return GPG_ERR_NOT_SUPPORTED;

err = gcry_md_open(&hd,algo,GCRY_MD_FLAG_SECURE);
err = gcry_md_enable(hd,algo);

Then the buffer can be a 'byte array', and after the values concatenation, the
hash calculation can be called like:

gcry_md_write(hd, buffer,sizeof(buffer));
HB = gcry_md_read(hd,algo);

Could be this the way you said?

Thanks

/Sergi.

On Friday 02 January 2009 01:21:27 Sergi Blanch i Torné wrote:
> On Thursday 01 January 2009 20:44:01 Moritz Schulte wrote:
> > > What I don't know now is how to correctly create this 'context'?
> > > Everywhere this is a 'pointer to void', and I cannot read the how.
> >
> > Why are you trying to fiddle around with Libgcrypt internals instead of
> > using the exported programing interface as it is documented in the
> > manual?
>
> Yes, probably I am try from the wrong way. I'm writting in the libgcrypt
> the elliptic curve encrypt algorithm from the 'ECC in OpenPGP' internet
> draft. By the way this code is in, also I can write the methods from module
> to module as an external view.
>
> > Have a look at the manual and the included test programs.
> >
> > To answer your specific question about the origin of the hash context:
> > the gcry_md_spec_t structure contains the info about the required size
> > for the context buffer. This is allocated in md.c and then initialized
> > with the algorithm-specific initialization function (also contained in
> > that struct).
>
> I found this, are you talking about the 'gcry_md_context' struct? You
> answer more than you think because I was declaring the buffer as a byte
> array, and it must be a gcry_md_hd_t? I'm checking it.
>
> > Hope that helps,
> > moritz
>
> To avoid future questions and wrong way coding I like to explain what I did
> by now. In the cipher/ecc.c, the interface methods ecc_encrypt and
> ecc_decrypt are add also with the 'gcry_pk_spec_t', 'pk_extra_spec_t' and
> the aliases. Internally also exists the encrypt and decrypt methods but
> some auxiliaries are need.
>
> From the standard I said a 'key derivation function' has to be implemented.
> Also in the document is explained, it comes from the Nist SP800-56A. Next
> step will be the AESkeyWrap (and the unwrap) from the rfc3394. But this
> will be further discussion.
>
> Using this moment, I like to prepare a patch that disturbs yous work at the
> minimum. Not like it was on ecdsa, when hundreds of things needs to be
> rewritten (not by me). Which communication can be the best?
>
> Really thanks!
>
> /Sergi.



--
“Success is not the key to happiness. Happiness is the key to success. If you
love what you are doing, you will be successful” – Albert Schweitzer.

_______________________________________________
Gcrypt-devel mailing list
Gcrypt-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gcrypt-devel

On Fri, 2 Jan 2009 11:36, sergi@calcurco.cat said:

> err = gcry_md_open(&hd,algo,GCRY_MD_FLAG_SECURE);
> err = gcry_md_enable(hd,algo);

The gcry_md_enable call is superfluous because you enabled algorithm
ALGO already with gcry_md_open.

> Then the buffer can be a 'byte array', and after the values concatenation, the

I don't understand why you insist on a byte array; you may pass any
memory block to gcry_md_write. Given that you know the hash algorithm
in advance and that there is just one contiguous memory range to hash, I
suggest to use gcry_md_hash_buffer instead. This has the advantage that
it can be highly optimized on some CPUs (modern VIA CPUs ferature a
SHA-1 and a SHA-256 implementation which work on an entire buffer and
return the finalized hash).


Shalom-Salam,

Werner

--
Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz.


_______________________________________________
Gcrypt-devel mailing list
Gcrypt-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gcrypt-devel