Re: [soapbuilders] Re: Super-Encryption AND Digital Signatures
RSA_Encrypt(SHA1(message) + key1) this looks promising. Also, doesn't
eliminate the need for a xml digital signature.
You see what I'm after, i.e., high security + scalable implementable features
+ compact wire format.
Quoting Rich Salz <rsalz@...>:
> A simpler fix is for the sender to do SHA1(message), and then
> encrypt (key1+digest) with their private key. That's simpler
> because it's a classic digital signature, and its properties are
> well understood.
> The two biggest problems with your current idea are that
> 1. "I" must be online and completely trusted for every single
> message exchange. This gives up all the benefits of public-
> key crypto.
> 2. There's no end-to-end security link. What prevents P from
> using his own keypair to forge a message that looks like
> A simpler fix for your first scheme might be for the sender to include
> RSA_Encrypt(SHA1(message)) alongside the encrypted key1. Then perhaps
> you include a timestamp, so adversaries can't capture and reply old
> I know you think that the standard mechanisms are expensive and full
> of overhead. There's a reason: without them, you leave yourself
> open to various attacks.
> Rich Salz Chief Security Architect
> DataPower Technology http://www.datapower.com
> XS40 XML Security Gateway http://www.datapower.com/products/xs40.html
> XML Security Overview http://www.datapower.com/xmldev/xmlsecurity.html
> You see what I'm after, i.e., high security + scalable implementable featuresYeah, there's no such thing as a free lunch. :)
> + compact wire format.
Folks often complain about how "big" SSL is, or how complicated
XML DSIG is, etc. Unfortunately, they are that way because they need
to be in order to be resistant to various threats. And then you have
to fight the deployment barriers: if SSL, PKCS#7 and/or XML DSIG are
already everywhere, what's the incentive to try something that hasn't
had the same level of analysis? Unless you're Ron Rivest (the R of RSA)
designing a new micro-payment protocol (www.peppercoin.com), you're
generally better off accepting the trade-offs of commodity security
Now, RSA_PublicKey_Encrypt(SHA1(message) + key1) seems reasonable
to me. But it's quite possible that there's some obscure corner of
crypto that makes this a bad idea. I still think it's worth
posting it to the cryptography mailing list.
Rich Salz Chief Security Architect
DataPower Technology http://www.datapower.com
XS40 XML Security Gateway http://www.datapower.com/products/xs40.html
XML Security Overview http://www.datapower.com/xmldev/xmlsecurity.html