* Marek Marcola wrote:
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?
Can I use the public key as secret key and backwards? Then I can
use OAEP for "signing" with the secret public key :-) and use the
public secret key in Linux-PAM for "verify the signature". The
advantage therefor is that I can use OAEP random(?) padding to get
of the _same_ plaintext different chiffertexts.
If you want to use OAEP in signing then you can first add OAEP
to your data with RSA_padding_add_PKCS1_OAEP() and next use
RSA_private_encrypt() with padding flag equal to RSA_NO_PADDING.
When verifying you first call RSA_public_decrypt() with
padding flag equal to RSA_NO_PADDING and next remove OAEP
padding with RSA_padding_check_PKCS1_OAEP() to get real data.
Oh yes, this looks like what I want. But, isn't it better to use a
probabilistic
encryption (signing) system. The problem of Elgamal is, that (1)
encryption/signing needs more CPU time as by RSA and (2) the
length of ciphertext is ˜ the double length of the plaintext.
Thanks.
Philippe______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
