diff options
author | levitte <levitte> | 2004-07-12 12:49:28 +0000 |
---|---|---|
committer | levitte <levitte> | 2004-07-12 12:49:28 +0000 |
commit | 8a9b6e7fa676e96877eb6db6ba7741b2d4bae12a (patch) | |
tree | 3af1d994da15dbb9c534ec9d8f99f951e499b1f7 | |
parent | be3cf274758b6c96a2befe735b2e74a6590127b1 (diff) | |
download | openssl-OpenSSL-engine-0_9_6-stable.tar.gz |
Recent changes from 0.9.6-stable.OpenSSL-engine-0_9_6-stable
-rw-r--r-- | README | 16 | ||||
-rw-r--r-- | doc/crypto/BN_num_bytes.pod | 57 |
2 files changed, 68 insertions, 5 deletions
@@ -173,11 +173,17 @@ textual explanation of what your patch does. Note: For legal reasons, contributions from the US can be accepted only - if a TSA notification and a copy of the patch is sent to crypt@bis.doc.gov; - see http://www.bis.doc.gov/Encryption/PubAvailEncSourceCodeNofify.html [sic] - and http://w3.access.gpo.gov/bis/ear/pdf/740.pdf (EAR Section 740.13(e)). - - The preferred format for changes is "diff -u" output. You might + if a TSU notification and a copy of the patch are sent to crypt@bis.doc.gov + (formerly BXA) with a copy to the ENC Encryption Request Coordinator; + please take some time to look at + http://www.bis.doc.gov/Encryption/PubAvailEncSourceCodeNofify.html [sic] + and + http://w3.access.gpo.gov/bis/ear/pdf/740.pdf (EAR Section 740.13(e)) + for the details. If "your encryption source code is too large to serve as + an email attachment", they are glad to receive it by fax instead; hope you + have a cheap long-distance plan. + + Our preferred format for changes is "diff -u" output. You might generate it like this: # cd openssl-work diff --git a/doc/crypto/BN_num_bytes.pod b/doc/crypto/BN_num_bytes.pod new file mode 100644 index 000000000..a6a2e3f81 --- /dev/null +++ b/doc/crypto/BN_num_bytes.pod @@ -0,0 +1,57 @@ +=pod + +=head1 NAME + +BN_num_bits, BN_num_bytes, BN_num_bits_word - get BIGNUM size + +=head1 SYNOPSIS + + #include <openssl/bn.h> + + int BN_num_bytes(const BIGNUM *a); + + int BN_num_bits(const BIGNUM *a); + + int BN_num_bits_word(BN_ULONG w); + +=head1 DESCRIPTION + +BN_num_bytes() returns the size of a B<BIGNUM> in bytes. + +BN_num_bits_word() returns the number of significant bits in a word. +If we take 0x00000432 as an example, it returns 11, not 16, not 32. +Basically, except for a zero, it returns I<floor(log2(w))+1>. + +BN_num_bits() returns the number of significant bits in a B<BIGNUM>, +following the same principle as BN_num_bits_word(). + +BN_num_bytes() is a macro. + +=head1 RETURN VALUES + +The size. + +=head1 NOTES + +Some have tried using BN_num_bits() on individual numbers in RSA keys, +DH keys and DSA keys, and found that they don't always come up with +the number of bits they expected (something like 512, 1024, 2048, +...). This is because generating a number with some specific number +of bits doesn't always set the highest bits, thereby making the number +of I<significant> bits a little lower. If you want to know the "key +size" of such a key, either use functions like RSA_size(), DH_size() +and DSA_size(), or use BN_num_bytes() and multiply with 8 (although +there's no real guarantee that will match the "key size", just a lot +more probability). + +=head1 SEE ALSO + +L<bn(3)|bn(3)>, L<DH_size(3)|DH_size(3)>, L<DSA_size(3)|DSA_size(3)>, +L<RSA_size(3)|RSA_size(3)> + +=head1 HISTORY + +BN_num_bytes(), BN_num_bits() and BN_num_bits_word() are available in +all versions of SSLeay and OpenSSL. + +=cut |