Re: Salmon magic signature implementations broken

[npena]

I can't reply in that thread (I don't know why) so I'm going to post
by starting a new one.

> Unfortunately, developers doing the "obvious" thing has led to the
> current situation. The openssl sign/verify exposed to PHP and Ruby
> doesn't have the emsa padding bytes. Neither does the PHPsec library -
> which we have been using in PHP to deal with modulus/exponent keys.

Bzzzt. Wrong. If those implementations didn't do the emsa padding
bytes they wouldn't be interoperable with anything. The PKCS
standards - http://tools.ietf.org/html/rfc3447#section-9.2 - mandate
they be used. And phpseclib, for example, does use them. To quote
from the source code:

$ps = str_repeat(chr(0xFF), $emLen - $tLen - 3);

$em = "\0\1$ps\0$t";

If you think phpseclib doesn't do emsa padding you're probably using
it incorrectly. It does PSS signatures by default because they offer
better security. To do PKCS#1 signatures you'll need to do the
following:

$rsa->setSignatureMode(CRYPT_RSA_SIGNATURE_PKCS)

On the subject of phpseclib, I saw http://macgirvin.com/display/mike/23816
. I think using openssl over phpseclib is a mistake. A lot of hosts
don't have openssl installed. phpseclib gives you portability. It
gives you a product that can be installed on any host under the sun.
And if you think phpseclib has a performance hit, might I suggest that
your analysis is just as fallacious as your assumption that phpseclib
(and everyone else) are doing it wrong?

phpseclib uses gmp, if available, bcmath if gmp isn't and it's own
internal implementation otherwise. gmp is the fastest, bcmath, the
second fast, and the internal implementation is the slowest. But all
the implementations are pretty darned fast, unless you're actually
generating keys.