Re: Signatures and encryption headers
- From: Fabrice <fabrice.gautier@xxxxxxxxx>
- Date: Wed, 5 Nov 2008 17:28:58 -0800 (PST)
On Nov 5, 2:29 pm, g...@xxxxxxxxxxxxx (Greg Rose) wrote:
In article <cddc5b77-291f-49eb-a004-d180ca2a1...@xxxxxxxxxxxxxxxxxxxxxxxxxxx>,
Fabrice <fabrice.gaut...@xxxxxxxxx> wrote:
On Nov 5, 10:53 am, g...@xxxxxxxxxxxxx (Greg Rose) wrote:
In article <8338d7c9-66c1-4ac6-a494-53f1b5d4a...@xxxxxxxxxxxxxxxxxxxxxxxxxx>,
Fabrice <fabrice.gaut...@xxxxxxxxx> wrote:
So the clear payload is signed, then its encrypted.
The encryption header, payload and signatures are sent to the
recipient.
Now the question is: should this header be signed too ? Or is it
unnecessary ?
There is a really simple and safe answer to this.
If you encrypt the payload, and then sign (I would
prefer to say MAC) the whole packet, you are
guaranteed to be safe from pretty much any
cryptographic[*] attacks. So why bother thinking
about it?
Why bother thinking about it ? Because of performance and other
implementation issues.
I could always do a sign-encrypt-sign scheme, but I dont want to be
overkill.
For example, checking the signature on the header and the ciphertext
as a whole, means that one needs to copy the whole ciphertext in
memory first: I cannot start decryption before I confirm the
signature.
No, that's not right. You could just as easily
start reading the input, and every time you have a
full block's worth, enter it into the hash. If it
was also encrypted, go ahead and decrypt it in
place. When you get to the end of the input,
finalize the hash and check the signature.
But then this mean you would be using the encryption header before you
authenticated it. Which was kind of the initial point: do not process
header before it is authenticated.
I confess I misread your initial scheme, and
thought you meant a message authentication code
and not a real signature. Any digital signature,
done in software, is orders of magnitude more
expensive than the kinds of operations you're
talking about to decrypt and hash here. So, I
would say, don't optimize out the correctness.
Actually, in my experience, the RSA signature verification itself is
actually pretty cheap. The expensive step is hashing the data. But
this is mostly due to low memory access speeds rather than
computational speed. This obviously varies a lot from platform to
platform.
If I do not require a signature on the header, then I can decrypt and
hash the data on the fly as it is received. Then verify the signature
on the final hash and I'm done.
I don't see any difference from what I propose.
Another issue is that I believe it's probably easy to implement side
channels attacks such as fault injections during the decryption of a
large payload (I'm thinking about file size from 10 KBytes up to
several MBytes, not of network packet size). So I would probably need
to a least perform another hash on the payload after decryption for
integrity.
Without having thought too much about this, my
initial reaction is that you're going to be hosed
either way, if your threat model includes things
like fault injection attacks. For example, there's
one class of fault attacks where all the attacker
needs to know is whether or not the fault he
injected made a difference or not, and you'd still
reveal that information to him.
Thats true, you can never be sure with side channels...
I'm trying to imagine the different attack scenarios that would apply
in both case. Then I can figure out how difficult those attacks would
be to implement and balance this against other implementation
considerations.
Another issue might be that the private key used for signature and the
keys used for encryption are held by different parties. In that case,
the one that is signing does not want to sign the encrypted payload,
as it has no way to know what it is that he is signing.
Well, if you're going to make up requirements on
the fly, I'll stop trying to give you
recommendations... I would rather wait for the
threat analysis and system design documentation to
stabilize. :-)
Well, thats a largely theoretical discussion here... so I'm coming up
with new scenarios all the time... and yes i'm currently biased in
favor of doing signature on plaintext. :)
Surprisingly, my first googlings about signing the ciphertext vs
signing the plaintext didnt return much information.
But I just found this: http://world.std.com/~dtd/sign_encrypt/sign_encrypt7..html
Didnt read it yet, but looks interesting....
Yet another issue is when there is one signing key, but multiple
encryption keys. The payload might be signed once by the author of the
payload, but it might be encrypted with multiple different keys for
various receivers. In that case I would rather sign once, encrypt n
times rather than encrypt n times then sign n times.
Does PGP or S/MIME sign the encryption headers ?
PGP does (don't know about S/MIME). In fact, this
was introduced precisely because failing to sign
the headers allowed an attack, but I can't
remember the details. It was something about
moving the boundaries described in the header to
allow malformed keys to be used. Whatever it was,
it was quite subtle, and goes a long way to
proving my point.
Do you have any reference about this attack?
This is precisely the kind of information I want to read up on to see
how it work (or does not work).
Greg.
--
Greg Rose
232B EC8F 44C6 C853 D68F E107 E6BF CD2F 1081 A37C
Qualcomm Australia:http://www.qualcomm.com.au
.
- References:
- Signatures and encryption headers
- From: Fabrice
- Re: Signatures and encryption headers
- From: Fabrice
- Signatures and encryption headers
- Prev by Date: Re: non linearity and randomness in block cipher
- Next by Date: Re: Variable / unlimited length block cipher algorithm
- Previous by thread: Re: Signatures and encryption headers
- Next by thread: filter-type encryption program for Unix
- Index(es):
Relevant Pages
|
