Ulf Moeller wrote:
>
> On Tue, Oct 03, 2000, Tom Biggs wrote:
>
> > I have so many questions, but this one is most pressing -
> > Is there a reasonable upper limit on the size in bits of a BN?
> > For various HW reasons we were hoping we could cap BNs
> > at 4096 bits for ModExp functions and the like. Is this possible?
> > Or is there some operation that might require more? The BN
> > docs imply that the software-implemented BNs can be any
> > arbitrary size.
>
> As a matter of fact, BIGNUMs can't be larger than INT_MAX bytes.
> In practice you'll rarely see numbers larger than 2048 bits, and
> it would make sense to fall back to the software implementation at
> say 2049 or 4097 bits.
>
> > format I need. It seems to me that using the BN_ULONG
> > type gets me mired in all sorts of endian and other
> > machine-dependent problems. Is that true or can the BN
> > be treated as a byte array of bits? (yes, I know, read the
> > source, study the generated code... I will... but sometimes
> > a quick comment is worth hours of code study.)
>
> The BIGNUM type is supposed to allow efficient operations on the
> host machine, it is not meant to be portable. See man BN_bn2bin
> for the conversion functions, and man bn_internal for some information
> on the BIGNUM format.
I'll wager they're talking about programmable hardware, in which case,
ordering isn't a major problem, so long as it is known what it is when
the toughware (I'm searching for a term that's a bit firmer than firm,
but not as hard as hard :-) is loaded. BIGNUMs behave in a way that is
mostly pretty compatible with hardware apart from this.
Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html
Coming to ApacheCon Europe 2000? http://apachecon.com/
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
