Mailing List Archive: GnuPG: gcrypt

[PATCH] OAEP support

Index | Next | Previous | View Threaded

ueno at unixuser

Jun 29, 2009, 8:53 PM

Post #1 of 4 (1067 views)
Permalink

[PATCH] OAEP support

Hi,

The attached patch adds OAEP padding support to libgcrypt.

Here are some notes:

- Before encryption/decryption, it reads necessary parameters from
`flags'. For example,

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

for encryption and,

(enc-data
(flags oaep hash sha1 label "test")
...)

for decryption.

- 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#)

Attachments:

oaep.diff (24.4 KB)

wk at gnupg

Jun 30, 2009, 3:34 AM

Post #2 of 4 (993 views)
Permalink

Re: [PATCH] OAEP support [In reply to]

On Tue, 30 Jun 2009 05:53, ueno [at] unixuser 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 [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gcrypt-devel

ueno at unixuser

Jun 30, 2009, 10:39 PM

Post #3 of 4 (991 views)
Permalink

Re: [PATCH] OAEP support [In reply to]

>>>>> In <87zlbqc8ny.fsf [at] wheatstone>
>>>>> Werner Koch <wk [at] gnupg> 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 [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gcrypt-devel

ueno at unixuser

Aug 24, 2009, 4:15 PM

Post #4 of 4 (826 views)
Permalink

Re: [PATCH] OAEP support [In reply to]

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 [at] broken>
>>>>> Daiki Ueno <ueno [at] unixuser> 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.

Attachments:

oaep-2009-08-25.diff (26.4 KB)

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads