Loading ...
Sorry, an error occurred while loading the content.

Re: [soapbuilders] Re: Super-Encryption AND Digital Signatures

Expand Messages
  • mlong@bridgetonconsulting.com
    Rich, 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
    Message 1 of 22 , Dec 9, 2003
    • 0 Attachment
      Rich,

      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.

      Thoughts!?!

      -Thx,

      -Matt



      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
      > I-on-behalf-of-C?
      >
      > 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
      > messages.
      >
      > 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.
      > /r$
      >
      > --
      > 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
      >
      >
      >
    • Rich Salz
      ... Yeah, there s no such thing as a free lunch. :) Folks often complain about how big SSL is, or how complicated XML DSIG is, etc. Unfortunately, they are
      Message 2 of 22 , Dec 9, 2003
      • 0 Attachment
        > You see what I'm after, i.e., high security + scalable implementable features
        > + compact wire format.
        >
        > Thoughts!?!

        Yeah, there's no such thing as a free lunch. :)

        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
        mechanisms.

        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.

        /r$

        --
        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
      Your message has been successfully submitted and would be delivered to recipients shortly.