Loading README +11 −5 Original line number Diff line number Diff line Loading @@ -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 Loading doc/crypto/BN_num_bytes.pod +23 −3 Original line number Diff line number Diff line Loading @@ -16,8 +16,14 @@ BN_num_bits, BN_num_bytes, BN_num_bits_word - get BIGNUM size =head1 DESCRIPTION These functions return the size of a B<BIGNUM> in bytes or bits, and the size of an unsigned integer in bits. 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. Loading @@ -25,9 +31,23 @@ BN_num_bytes() is a macro. 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<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 Loading Loading
README +11 −5 Original line number Diff line number Diff line Loading @@ -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 Loading
doc/crypto/BN_num_bytes.pod +23 −3 Original line number Diff line number Diff line Loading @@ -16,8 +16,14 @@ BN_num_bits, BN_num_bytes, BN_num_bits_word - get BIGNUM size =head1 DESCRIPTION These functions return the size of a B<BIGNUM> in bytes or bits, and the size of an unsigned integer in bits. 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. Loading @@ -25,9 +31,23 @@ BN_num_bytes() is a macro. 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<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 Loading