[Botan-devel] Thanks, minor issues & questions on RSA sign/verify padding, binary size
lloyd at randombit.net
Tue Oct 13 13:04:50 EDT 2009
On Tue, Oct 13, 2009 at 04:23:59PM +0100, Paul Clark wrote:
> Here's the same from a Botan EMSA1(SHA1) signature of the same document:
> 0000: 48eb9f15 47e25122 74a8d501 b80b3903 | H...G.Q"t.....9.
> 0010: 97a3cee2 | ....
> Note that when it's an EMSA1(SHA1) signature, RSA_PublicKey::verify()
> seems to 'unpad' it itself. Is that expected? I guess it's just
> suppressing leading zeros?
Yes, on the decoding side leading zeros will get stripped from an RSA
operation. (I actually can't claim that makes any sense, but it works;
a lot of this code is 5+ years old and was written when I didn't
really know what I was doing (not that I necessarily know what I'm
doing now, of coures).
> Again, the last 20 bytes are the same, but we seem to have gained
> another 15 bytes, which from the code I see (as through a glass, darkly)
> is the SHA-160 PKCS#1 'hash ID'. It looks like the OpenSSL version
> doesn't have this - but I got as far as actually reading PKCS#1 section
> 9.2 (EMSA-PKCS1-v1_5) and it looks like this 'AlgorithmIdentifier' is
Yup - looking at the OpenSSL code, it seems to assume that the
algorithm id was already prepended to the hash before calling the RSA
function; it just adds the outer 01FFFF... block.
> If this is right, it looks like I might have to revert to my low-level
> RSA operations and implement the (broken? hash-identifier-less) PKCS#1
> padding myself - no big deal, but it would be nice to know if I've
> understood it roughly right. I do of course agree that if it weren't for
> the legacy problem, we should be doing it properly with EMSA-PSS!
I think your interpretation of the situation is correct.
> OK, that's great. Actually I was using the configure.pl script because
> the configure.py failed on first attempt - this lead me to work out why.
> It's because I've imported Botan into our CVS and there are CVS
> directories in the build-data/arch (etc.) directories. I guess the
> script is wildcarding the directory and gets confused by the CVS subdir.
> For now I just deleted the CVS dirs and it works fine, but it would be
> good if it could ignore them (maybe wildcard on [a-z]*?)
Thanks for mentioning - should be fixed in the next release by only
looking at files named *.txt in those directories, which shouldn't
cause any confusion with CVS droppings or suchlike.
> With the library cut down like this Botan is adding about 1MB to the
> app. Much better than 2MB, but still quite a lot. But I can live with
> that, this isn't really a space-sensitive application, I was just
> surprised... There doesn't seem to be enough code in the stripped down
> library to fill it - maybe there's a lot of template expansion going on?
Probably so. The most likely culprit being the *Vector
types. Unfortunately it's hard to profile code size and I haven't had
much luck in my attempts to reduce it so far.
> Unfortunately it won't run like this! First it complained about no
> thread mutex, so I added back 'pthread' - thats fine. Now it's
> complaining that "No usable RNG found enabled in build". I tried adding
> 'dev_random' and 'x931_rng' but no luck. Which are the minimum modules
> you need to use AutoSeededRNG?
Ah right I had missed that you are using the thread safe option.
x931_rng isn't necessary unless you really want it - it is only used
as a paranoid PRNG post-processor (basically, it takes the output of
the 'real' PRNG and runs it through the stock X9.31 PRNG (except using
AES instead of 3DES, which I believe is allowed by at least NIST, if
not the ANSI standard - not sure about them), so even if it turns out
that the HMAC_RNG or Randpool implementations are thoroughly broken
somehow, the PRNG will still produce cryptographically random outputs.
You'll need at least hmac_rng and auto_rng, I think - the dependencies
of those should be loaded automatically.
More information about the botan-devel