From: Dane Smith on 9 Mar 2007 08:55 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 9 Mar 2007 08:56 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 9 Mar 2007 08:58 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 9 Mar 2007 10:02 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 9 Mar 2007 11:13 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
First
|
Prev
|
Next
|
Last
Pages: 1 2 3 4 5 Prev: My attempt to break Rijndael (SAT-attack) Next: RSA-1024 verilog |