RSA // linking plaintext to ciphertext

vedaal_at_hush.com
Date: 09/08/04 

Date: 8 Sep 2004 14:53:15 -0700

Tom St Denis <tomstdenis@iahu.ca> wrote:
>vedaal@hush.com wrote:

>> if a message is encrypted to an RSA key,
>> and someone 'suspects' having recovered a 'complete' copy of the
>> plaintext
>> (assume, for purposes of the question, that it is an 'exact' copy
of
>> the plaintext),
>>
>> then,
>>
>> is it possible to 'prove' that that plaintext was encrypted to that
>> ciphertext,
>> if one does not have the private key?
>
>You can show that plaintext^e == ciphertext.

is it, though?

isn't this what it 'really' is :

plaintext^e == ciphertext (without padding)

which is not not the same as the known ciphertext when padding is
used.

if it were, then how would padding would protect against the following
situation?:

[1] question is sent unencrypted
[2] assume that the rsa encrypted answer is either yes or no
[3] attacker computes plaintext-yes^e
and also plaintext-no^e
and compares ciphertexts against the intercepted ciphertext

here is the practical background application that i'm really
interested in, and why i'm asking the question:

i'm interested in a simple method of signing and encrypting, where the
receiver cannot prove that the sender signed the message without
either giving up the key, or actually decrypting in front of
witnesses.

gnupg/pgp cannot currently do this, because,

[1] ordinary signed and encrypted messages can easily be separated
into freestanding verifiable clearsigned messages

[2] even if encrypt, then sign or sign&encrypt, is used,
the receiver can release the session keys and prove that the sender
signed it.

what i was hoping 'would' work,
would be to
[1] encrypt directly to the rsa key
[2] add a line of plaintext to the end of the ciphertext
saying,
"this message is encrypted to rsa public key (whatever the key id /
fingerprint/ keysize is"
[3] sign the [ciphertext + plaintext]
(this avoids a Ross Anderson type attack on signed ciphertexts)

so, the question again is,

if enough padding is used,
can it prevent the receiver from releasing the plaintext and proving
that it encrypts to that ciphertext,
(and thereby 'proving' that the sender signed it) ?

tia,

vedaal

Relevant Pages

  • Re: Basic File Encyption
    ... If you gave the right key, you get plaintext. ... If I encrypt a plaintext with a password, I get a ciphertext: ... $> ./foo aliqrfnue password d ...
    (sci.crypt)
  • Re: Need secure block cipher for 96 bits of block size
    ... the first block to give the overall 96 bits of ciphertext. ... then the first 32 bits of the ciphertext will match. ... plaintext space), this can leak information to an adversary. ... If the OP needs to send a 64-bit plaintext using 96 bits, and he can establish an implicit IV, then he could just encrypt 64 bits using CTR mode and apply a 32-bit MAC to the ciphertext. ...
    (sci.crypt)
  • Re: Crypto problems in Vista
    ... Calling CryptGetKeyParam() was revealing... ... The ciphertext is ALWAYS longer than the plaintext. ... If the plaintext I encrypt is always 128 bits, ... for padding, but I cannot switch it off. ...
    (microsoft.public.platformsdk.security)
  • Re: Data Compression Before or After Encryption ?
    ... Encrypt the same block twice and you get the same ciphertext. ... With simple I mean 'good enough' so that it isn't easy to get the plaintext ... or anything else like blocking packets etc. ...
    (sci.crypt)
  • Re: research into modern computer-based one-time pad implementations?
    ... doesn't know any plaintext, and cannot affect choices of or changes to ... A trial decryption of the pad ciphertext can ... the cipher used to encrypt the pads. ...
    (sci.crypt)
Loading