From: Dane Smith on
Amitabh wrote:
> On Mar 9, 9: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.
>>
>> --
>> Kristian Gj�steen
>
> Out of curiosity, can there exist a probabilistic symmetric encryption
> scheme? (i.e. the IV need not be sent, some random number (IV) is used
> for encryption but discarded after that.. only the key is used for
> decryption.
>
Not that I know of in the sense that you use an IV and discard it. If
you dont mind some file size increase, there can be probabilistic
symmetric encryption with a single key.
From: Dane Smith on
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.
From: Dane Smith on
JR wrote:
> One could insert a random byte every n bytes. So it is possible. Is it
> useful?
>
> JR
>
> muCtvp/fr/lo
>
> "Will Dickson" <wrd(a)NOSPAM.glaurung.demon.co.uk> ???
> ??????:pan.2007.03.08.22.32.14.838283(a)NOSPAM.glaurung.demon.co.uk...
>> On Thu, 08 Mar 2007 16:36:23 -0500, 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?
>> How would you decrypt it?
>>
>>
>> Will.
>>
>
>

That is quite similar to my own idea, but I have the same question, is
it useful?
From: vedaal on
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

From: Dane Smith on
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