* Marek Marcola <[EMAIL PROTECTED]> wrote: > > Maybe I do not understand this correctly, but if you want to > encrypt some data with RSA 1024 bit key then you will get 128 > bytes of output ciphertext. It is not important what padding > scheme you will use (or even no padding at all) you should > get 128 bytes output from modular exponentation process. So > you will not be able to store this on your token. Or I > really miss something :-)
Okay, I have to use a RSA 928 bit key, then I will get 116 bytes of output ciphertext. > Ok, but in this case token can be copied without problem. Yes, I know. That's a big problem, but I _must_ use this "token"! > Or maybe token has some unique information (like serial number > stored in not writable memory) which can be inserted in user > authentication data (which is signed) to limit copying. Yes, this token has a not-writeable serial number, which are stored in ROM. And yes - because of the copying-problem - I centrally want to sign every user authentication data (stored in 116 byte writeable EEPROM) with one RSA (private) key. Decentrally (in form of an Linux-PAM module), I want store the public key, which can verify this signed user authentication data. But moreover, I not want to sign a cryptographic hash value of this information, I want to encode (sign) the complete plaintext information: [CUT=user001 authentication data on token] my_system_user_name group_of_my_system_user_name 2010-12-31 [CUT] [CUT=signed authentication data of user001 (116 byte) uses PKCS#1] 0x0000 4fb4 f1b3 d6b8 55ab 0a1d dd75 07e8 8039 O.....U....u...9 0x0010 07b6 6d77 b54d 370c eee9 ab7c 0fdf 760c ..mw.M7....|..v. 0x0020 5425 00c8 80ba 74ff 4168 2aa1 d47f 0c4a T%....t.Ah*....J 0x0030 085c 4d00 4baf 8e67 9cc7 a345 276c b790 .\M.K..g...E'l.. 0x0040 d829 1dbf 26ba ea23 57b2 40a6 c265 33b8 .)..&[EMAIL PROTECTED] 0x0050 5add 948f 4cca 3d20 f7c8 490b 6de2 923b Z...L.= ..I.m..; 0x0060 3afc f44b 3b0b 8bb6 cfcf b3e1 3af3 d03e :..K;.......:..> 0x0070 61e0 8e22 a.." [/CUT] Is that another problem, not to sign the hash value of this information? > In this case I think this is not a problem because this is data > signing process. In PKCS1 when you sign data with private key > there is NO random information generated. All message that is > encrypted with private key is known. For example if you want to sign > some message you calculate its digest (hash, SHA1 for example), > next you build ASN.1 DigestInfo structure, and pad this with PCKS1. > But this padding only adds in front of DigestInfo known block and > you get something like that: > 0x0001FFFF.....FF00DigestInfo > and this is encrypted with private key. > As you see, there is no random information in this case. That means, that padding didn't solve the problem of known-plaintext-, chosen-plaintext-, chosen-cyphertext- or adaptive-chosen-plaintext-attacks? What about OAEP padding? In my point of view, if I use padding (e.g. PKCS#1 v1.5) every chiffertext of the _same_ plaintext looks _different_?!?! Regards, Philippe ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
