>I implemented the SET Reference Implementation using BSAFEeay and
>SSLeay 0.8.1 quite some time ago. This required the RSA_NO_PADDING
>option. A patch for SSLeay_0.8.1 was available for this.
The RSA_NO_PADDING code in 0.9.x is not equivalent to the 0.8.1
nopadding patch, and indeed is broken.
RSA_padding_check_none refers to a "type" byte and replaces it with
0. But obviously when you do no padding, there is to type byte to
replace. As a result, RSA_padding_check_none destroys the data. That
did not happen in 0.8.1.
For the 0.8.1 functionality, the functions should look like this (with
a check for flen < tlen, which would result in undefined behaviour and
might be caused by chosing the wrong padding mode):
int RSA_padding_add_none(to,tlen,from,flen)
unsigned char *to;
int tlen;
unsigned char *from;
int flen;
{
if (flen > tlen)
{
RSAerr(RSA_F_RSA_PADDING_ADD_NONE,RSA_R_DATA_TOO_LARGE_FOR_KEY_SIZE);
return(0);
}
if (flen < tlen)
{
RSAerr(RSA_F_RSA_PADDING_ADD_NONE,RSA_R_DATA_TOO_SMALL_FOR_KEY_SIZE);
return(0);
}
memcpy(to,from,(unsigned int)flen);
return(1);
}
int RSA_padding_check_none(to,tlen,from,flen,num)
unsigned char *to;
int tlen;
unsigned char *from;
int flen;
int num;
{
if (flen > tlen)
{
RSAerr(RSA_F_RSA_PADDING_CHECK_NONE,RSA_R_DATA_TOO_LARGE);
return(-1);
}
memset(to,0,tlen-flen);
memcpy(to+tlen-flen,from,flen);
return(tlen);
}
Another difference between 0.8.1 and 0.9.x is that
RSA_padding_add_none in 0.9.x prepends a null byte first.
If you want that, the code would look like this:
int RSA_padding_add_none(to,tlen,from,flen)
unsigned char *to;
int tlen;
unsigned char *from;
int flen;
{
if (flen+1 > tlen)
{
RSAerr(RSA_F_RSA_PADDING_ADD_NONE,RSA_R_DATA_TOO_LARGE_FOR_KEY_SIZE);
return(0);
}
if (flen+1 < tlen)
{
RSAerr(RSA_F_RSA_PADDING_ADD_NONE,RSA_R_DATA_TOO_SMALL_FOR_KEY_SIZE);
return(0);
}
*(to++)=0;
memcpy(to,from,(unsigned int)flen);
return(1);
}
int RSA_padding_check_none(to,tlen,from,flen,num)
unsigned char *to;
int tlen;
unsigned char *from;
int flen;
int num;
{
if (flen > tlen)
{
RSAerr(RSA_F_RSA_PADDING_CHECK_NONE,RSA_R_DATA_TOO_LARGE);
return(-1);
}
if (flen == tlen)
{
RSAerr(RSA_F_RSA_PADDING_CHECK_NONE,RSA_R_BAD_ZERO_BYTE);
return(-1);
}
tlen--;
memset(to,0,tlen-flen);
memcpy(to+tlen-flen,from,flen);
return(tlen);
}
Note that the length of the output is tlen-1 a.k.a. num-1 (would be
tlen if we were to return the leading 0 byte). It does not depend on
flen. If flen < tlen, then there are legitimate 0 bytes at the left
of the data, which we must insert so the user can do his own decoding
operation.
[I didn't test the C code in this message.]
[The C code in this message is not tested.]
As far as I can see, there is no point in making a difference between
the tlen and num arguments of the RSA_padding_check functions. I plead
for removing num.
And the comment in rsa_eay.c:
j=BN_bn2bin(&ret,p); /* j is only used with no-padding mode */
is wrong.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
