Mailing List Archive

On Tue, 30 Jun 2009 05:53, ueno@unixuser.org said:

> The attached patch adds OAEP padding support to libgcrypt.

Thanks.

> - Before encryption/decryption, it reads necessary parameters from
> `flags'. For example,
>
> (data
> (flags oaep hash sha1 label "test")
> (value #11223344556677889900AA#))

I would like to keep the flags list a real flags list without
parameters. Would anything speak against:

(data
(flags oaep)
(hash sha1)
(label "test")
(value #11223344556677889900AA#))

I can do this change if you agree.

> - After decryption, it stores the decoded value as a `decoded' token
> instead of `value', unlike other encodings (`raw' and `pkcs1'). This
> is for backward compatibility. For example,
>
> (decoded #11223344556677889900AA#)

That is so that the caller can easily see whether OAEP has been used and
that the code needs to be adjusted, right?

I'll look closer at the patch in the next days.



Salam-Shalom,

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

>>>>> In <87zlbqc8ny.fsf@wheatstone.g10code.de>
>>>>> Werner Koch <wk@gnupg.org> wrote:
> I would like to keep the flags list a real flags list without
> parameters. Would anything speak against:

> (data
> (flags oaep)
> (hash sha1)
> (label "test")
> (value #11223344556677889900AA#))

> I can do this change if you agree.

Yes, I would appreciate you making the interface more intuitive.

> > - After decryption, it stores the decoded value as a `decoded' token
> > instead of `value', unlike other encodings (`raw' and `pkcs1'). This
> > is for backward compatibility. For example,
> >
> > (decoded #11223344556677889900AA#)

> That is so that the caller can easily see whether OAEP has been used and
> that the code needs to be adjusted, right?

Not really. I just felt it unnatural to reuse the same `value' tag for
both padded and unpadded plaintexts since gcry_pk_decrypt currently does
not remove any paddings.

Regards,
--
Daiki Ueno

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

Hi,

The attached is the current version of the OAEP patch, reflecting your
suggestion for the interface. Since I think the patch still lacks
polish, further comments and suggestions are appreciated.

>>>>> In <87ab3prmgk.fsf@broken.deisui.org>
>>>>> Daiki Ueno <ueno@unixuser.org> wrote:
> > I would like to keep the flags list a real flags list without
> > parameters. Would anything speak against:

> > (data
> > (flags oaep)
> > (hash sha1)
> > (label "test")
> > (value #11223344556677889900AA#))

> > I can do this change if you agree.

Done. I renamed "hash" to "hash-algo" since "hash" is used in different
meaning. The current interface is as follows:

* gcry_pk_encrypt takes the following sexp:

(data
(flags oaep)
(hash-algo sha1)
(label "test")
(value #11223344556677889900AA#))

and returns:

(enc-val (rsa ...))

* gcry_pk_decrypt takes the following sexp:

(enc-val
(flags oaep unpad)
(hash-algo sha1)
(label "test")
(rsa ...))

and returns:

(data (value ...))

* Both functions do padding internally. Note that "unpad" in flags,
which indicates the output plaintext is un-padded, while the library
currently do not handle un-padding.

* Q: Can I implement PSS similarly? RFC3447 insists that, there is a
patent pending by the University of California, but they promises(?)
that they will freely license confirming implementation, once PSS is
standardised.