4 ms·

I flat out don't trust AWS SIG; It falls into the classic encryption antipattern of signing the meaning and not the bytes - Anytime a transformation of the data

I flat out don't trust AWS SIG; It falls into the classic encryption antipattern of signing the meaning and not the bytes - Anytime a transformation of the data is required before or after the signature is applied, you open up a hole for attackers to exploit. See V1 and V3, which were flat out insecure and have been abandoned. Sign the bytes, not the meaning.

tptacek 5y ago
You often can't sign the meaning, because the systems handling the request can reorder the bytes, and there are unbounded number of byte sequences mapping to a given meaning. That's the whole reason we have canonicalization. Canonicalization is treacherous and generalist developers shouldn't freelance their own formats. Canonicalization problems are one of the reasons we're at SIGV4 and not just, like, SIG. But Amazon has at this point thought about this as carefully as any organization in the Internet. Which is why it's good advice to, if you're going for a signed-request API, just shoplift SIGV4 from them.
- OJFord 5y ago
  Could you explain (even just a link if you have one) what you and GP mean by 'bytes vs. meaning'? I can't really imagine what the latter is, other than perhaps signing byte values within a structure rather than the structure as a whole, and if that's it I don't understand how it's a non trivial difference, or what you mean by 'byte sequences mapping to a given meaning'. Not looking to roll my own, just curious!
  - tptacek 5y ago
    The parent is noting that what actually gets signed in SIGV4 isn't the raw request, but a pseudo-request derived from the raw; the pseudo is the "meaning" (in their terminology); a cryptography engineer would call it the "canonicalized" request. What they'd like instead is a signature format that simply signed the raw request, the "bytes".
    - OJFord 5y ago
      Ah! Got it, thanks.
- tedunangst 5y ago
  I think you meant to say can't sign the bytes?
  - tptacek 5y ago
    I did. Thanks!

tptacek 5y ago

You often can't sign the meaning, because the systems handling the request can reorder the bytes, and there are unbounded number of byte sequences mapping to a given meaning. That's the whole reason we have canonicalization. Canonicalization is treacherous and generalist developers shouldn't freelance their own formats. Canonicalization problems are one of the reasons we're at SIGV4 and not just, like, SIG. But Amazon has at this point thought about this as carefully as any organization in the Internet. Which is why it's good advice to, if you're going for a signed-request API, just shoplift SIGV4 from them.

OJFord 5y ago
Could you explain (even just a link if you have one) what you and GP mean by 'bytes vs. meaning'? I can't really imagine what the latter is, other than perhaps signing byte values within a structure rather than the structure as a whole, and if that's it I don't understand how it's a non trivial difference, or what you mean by 'byte sequences mapping to a given meaning'. Not looking to roll my own, just curious!
- tptacek 5y ago
  The parent is noting that what actually gets signed in SIGV4 isn't the raw request, but a pseudo-request derived from the raw; the pseudo is the "meaning" (in their terminology); a cryptography engineer would call it the "canonicalized" request. What they'd like instead is a signature format that simply signed the raw request, the "bytes".
  - OJFord 5y ago
    Ah! Got it, thanks.
tedunangst 5y ago
I think you meant to say can't sign the bytes?
- tptacek 5y ago
  I did. Thanks!