Prev: My attempt to break Rijndael (SAT-attack)
Next: RSA-1024 verilog
From: Dane Smith on 9 Mar 2007 11:20
Dane Smith wrote:
> vedaal wrote:
>> On Mar 9, 3:04 am, Kristian Gj�steen <kristiag+n...(a)math.ntnu.no>
>> wrote:
>>> Dane Smith <dasmi...(a)cse.buffalo.edu> wrote:
>>>
>>>> This is true. The IV would have to be sent or stored, so there could be
>>>> some increase there though it would be constant while the other would be
>>>> proportional. Is that little bit of extra space necessarily bad though?
>>> Unless there is some benefit, it is bad.
>> there would be a very large benefit,
>> if this could be utilized to solve a somewhat restated problem:
>>
>> is there a way to have two different plaintexts encrypt to the same
>> ciphertext, by using different IV's and storing/sending them
>>
>> the only way (afaik) that this can be done now,
>> is to create an OTP that transforms the second plaintext into the
>> ciphertext produced by the first (decoy) plaintext, and store/send the
>> OTP
>>
>>
>> tia,
>>
>> vedaal
>>
> Well, if one plaintext has many possible ciphertexts, and the number of
> possible ciphertexts is limited by the 2^blocksize then there would have
> to combinations of plaintexts that would encrypt to the same ciphertexts.
>
> Dane
In response to myself...
However, to do this with no IV there is expansion, so based on the
number of possible ciphertexts, which would be length 2^blocksize+some
it would possible to have two plaintexts encrypt to the same ciphertext
if each plaintext had enough possible ciphertexts that there would have
to be some overlap. Sorry for the mistake.

Dane

Dane
From: Dane Smith on 9 Mar 2007 11:50
Sebastian Gottschalk wrote:
> Dane Smith wrote:
>
>> arsonperbuilding(a)gmail.com wrote:
>>> On Mar 8, 5:17 pm, Dane Smith <dasmi...(a)cse.buffalo.edu> wrote:
>>>
>>>> But, assuming you have the same IV, then you still have the same output.
>>>> IV's are normally associated with CBC mode in block ciphers, assuming Im
>>>> not mistaken. What I am trying to describe is something that with the
>>>> same exact input, key, IV, plaintext, would still be able to vary in output.
>>>>
>>>> Dane
>>> Say you had an encryption function E(K,IV,m)=c and a decryption
>>> function D(K,IV,c)=m.
>>> If E(K,IV,m1)=c1 and E(K,IV,m1)=c2, where c1 != c2, how would your
>>> decryption function know how to properly turn the ciphertext back into
>>> proper plaintext?
>>>
>> I dont know that there would be any way to do this using an IV.
>
> Maybe you don't even understand how an IV works?
>
> E(K,IV1,m1)=(IV1||c1)
> E(K,IV2,m1)=(IV2||c2)
>
> D(K,IV1,c1)=m1
> D(K,IV2,c2)=m1
Perhaps I am confused. I thought an IV was used like this:
First input block = E(k, B1) XOR IV = C1
E(k, B2) XOR C1 = C2... And onward in CBC mode.
Am I wrong on this? Or is there another way of using an IV that I dont
know of?

Dane
From: Peter Pearson on 9 Mar 2007 12:08
On 9 Mar 2007 07:02:16 -0800, vedaal <vedaal(a)gmail.com> wrote:
[snip]
>
> is there a way to have two different plaintexts encrypt to the same
> ciphertext, by using different IV's and storing/sending them

It's useful to stipulate that the decryption process takes
as input (1) a key, and (2) some ciphertext, and produces
plaintext. Introducing categories beyond key and ciphertext
only impedes thought.

If the additional information you propose (IV or whatever)
is considered part of the ciphertext, then a given ciphertext
decrypts to only one plaintext. On the other hand, if the
additional information is considered part of the key, then
you're just exchanging messages over the key-distribution
channel.

--
To email me, substitute nowhere->spamcop, invalid->net.
From: Douglas A. Gwyn on 9 Mar 2007 13:13
Dane Smith wrote:
> Just out of my own curiosity, how do people feel about a block cipher
> which encrypts the same message using the same key to any one of many
> possible ciphertexts. I'm not entirely sure this has ever been done to
> any great length, though, it is quite possible I have missed something.
> Does anyone believe that it is even necessarily possible?

Even the old Unix password encryption did that.
From: rossum on 9 Mar 2007 14:22
On Fri, 09 Mar 2007 11:13:25 -0500, Dane Smith
<dasmith6(a)cse.buffalo.edu> wrote:

>vedaal wrote:
>> On Mar 9, 3:04 am, Kristian Gj�steen <kristiag+n...(a)math.ntnu.no>
>> wrote:
>>> Dane Smith <dasmi...(a)cse.buffalo.edu> wrote:
>>>
>>>> This is true. The IV would have to be sent or stored, so there could be
>>>> some increase there though it would be constant while the other would be
>>>> proportional. Is that little bit of extra space necessarily bad though?
>>> Unless there is some benefit, it is bad.
>>
>> there would be a very large benefit,
>> if this could be utilized to solve a somewhat restated problem:
>>
>> is there a way to have two different plaintexts encrypt to the same
>> ciphertext, by using different IV's and storing/sending them
>>
>> the only way (afaik) that this can be done now,
>> is to create an OTP that transforms the second plaintext into the
>> ciphertext produced by the first (decoy) plaintext, and store/send the
>> OTP
>>
>>
>> tia,
>>
>> vedaal
>>
>Well, if one plaintext has many possible ciphertexts, and the number of
>possible ciphertexts is limited by the 2^blocksize then there would have
>to combinations of plaintexts that would encrypt to the same ciphertexts.
Alternatively, the cyphertext blocks could be bigger than the
plaintext blocks, so there would be 2^(c-p) possible cyphertext blocks
for each plaintext block with a unique decoding for each cyphertext
block. Here c = bits in a cyphertext block, p = bits in a plaintext
block.

rossum


>
>Dane

First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5
Prev: My attempt to break Rijndael (SAT-attack)
Next: RSA-1024 verilog