RSA PKCS#1 compliant signature

views:

130

answers:

RSA PKCS#1 compliant signature

I am using PKCS#1 2.0 (OAEP) standard (signature with appendix), but there are some issues not clear to me.

What is the physical object that is beeing signed? I know it's hash function value and so on (I do know the algorithm), but is it calculated from the binary fform of the file, no matter what is the content?
What is the physical result of signing? A file containing the signed hash? Should this file be placed in a specified location? What is the format or extension of such thing?
If I have several files that I want to sign, should this operation be performed separately for each of them? Or should they be concatenated? Once again - what is the result of such operation (file?) ?

PKCS#1 is sometimes called 'raw RSA' and is a low-level cryptographic primitive: it doesn't work on files and doesn't produce files, it works on raw data: input is a number smaller than the public key and output is a number of the size of the public key (e.g. 1024 bit for RSA-1024).

If you want a signature file, you probably want to use PKCS#7/CMS format, as that's the most used signature format both for attached and detached signatures (even signatures in PDF files are usually PKCS#7 envelopes actually).

PS: I don't know much about OAEP, but from what I read it seems to be a padding scheme (something you do to data before the raw signature) so my argument should be still valid.

lapo 2010-07-23 15:14:22

I add that a PKCS#7 signature is an object much more complex (and bigger) than a bare PKCS#1 signature and involves using X.509 certificates among other things, so it might not be what you're looking for, depending on circumstances. OTOH is a complete format that lots of program support and can correctly verify, while if you use bare PKCS#1 it's mostly up to you what you do with it.

lapo 2010-07-23 15:21:24

Your formulation "input is a number smaller than the public key" is quite unclear. The input is either an almost arbitrarily long byte array which is first hashed and then signed or it is already the hash digest which is then directly signed. Which one it is depends of course on the interface of the crypto lib that is used.

Accipitridae 2010-07-24 10:50:11

No it is not, PKCS#1 includes padding to make input "just big enough" but does not include hashing or the distinction between attached and detached signature, that's something managed at a higher level, as in PKCS#7.

lapo 2010-07-26 07:46:38

This is silly. On the one hand you have no clue what OAEP is on the other hand you stubbornly insist that PKCS #1 signatures use no hash function. That earns you a well deserved down-vote.

Accipitridae 2010-07-26 18:50:00

That's not silly, that's simply because in the timeframe between my first to my second message, I read the documentation on OAEP and verified the information I was giving.Yes, OAEP does use an hash internally, but *not* to hash the input file; in fact, it specifies the maximum input size is strictly smaller than the RSA size by a fair amount (section 7.1.1 of PKCS#1v2.1 official documentation): M ≤ k - 2 hLen - 2.

lapo 2010-07-28 13:37:09

You are reading the wrong section. OAEP = "Optimal asymmetric encryption padding". The third word is crucial. OAEP is about encryption not signatures.

Accipitridae 2010-07-28 17:41:45

ansaurus

tags:

views:

answers:

RSA PKCS#1 compliant signature

related questions