Anyway, I think I've discovered a bug. At least by doing
a code review (refer to INCORRECT TYPECAST?? line in the following code
(found in rsa_lib.c)), it appears that ul will end up pointing somewhere
in the middle of the second BIGNUM block. If the typecast was corrected,
then the math would place the ul pointer to point directly AFTER all of
the BIGNUM blocks, which is presumedly where the 'digit data' would want
to live - that is, if the data were ever used. ;^)
int RSA_memory_lock(r)
RSA *r;
{
int i,j,k,off;
char *p;
BIGNUM *bn,**t[6],*b;
BN_ULONG *ul;
if (r->d == NULL) return(1);
t[0]= &r->d;
t[1]= &r->p;
t[2]= &r->q;
t[3]= &r->dmp1;
t[4]= &r->dmq1;
t[5]= &r->iqmp;
k=sizeof(BIGNUM)*6;
off=k/sizeof(BN_ULONG)+1;
j=1;
for (i=0; i<6; i++)
j+= (*t[i])->top;
if ((p=Malloc_locked((off+j)*sizeof(BN_ULONG))) == NULL)
{
RSAerr(RSA_F_MEMORY_LOCK,ERR_R_MALLOC_FAILURE);
return(0);
}
bn=(BIGNUM *)p;
ul=(BN_ULONG *)&(p[off]);
<<<<<======== INCORRECT TYPECAST ??
for (i=0; i<6; i++)
{
b= *(t[i]);
*(t[i])= &(bn[i]);
memcpy((char *)&(bn[i]),(char *)b,sizeof(BIGNUM));
bn[i].flags=BN_FLG_STATIC_DATA;
bn[i].d=ul;
memcpy((char *)ul,b->d,sizeof(BN_ULONG)*b->top);
ul+=b->top;
BN_clear_free(b);
}
/* I should fix this so it can still be done */
r->flags&= ~(RSA_FLAG_CACHE_PRIVATE|RSA_FLAG_CACHE_PUBLIC);
r->bignum_data=p;
return(1);
}
-- Allen Ellison Voice: (303) 444-9532 Sr. Software Engineer Email: [EMAIL PROTECTED] Compatible Systems Corp WWW: http://www.Compatible.COM/
