each time encryption gives different result......??

[sachin kataria]

hi,
i have one xml file , which i have encrypted using public key..
so, encryted result i store in another xml file.....

this is ok...

after some time again i encrypt same xml file using same public key,
so it is giving me different encrypted result...

so, i want to know , each time i execute same program, for xml encryption using same xml file and same public key... it will give me different result...?

pls, help me.......

[Ashish Chopra]

Yes, it is very much possible that the encrypted text is slightly different each time..

though the important question is, are you getting the same data back after you have decrypted the file you just encrypted by using the private key ( i am assuming that you are using public-key encryption algorithms, like RSA )?

[sachin kataria]

ya, i am getting same data back in both encrypted xml file
(both encryped xml file is encrypted using same public key...?

ya.....i am using RSA algo.

[Tony Morris]

I have always argued that software developers often forget about a dimension that we conveniently called 'time'. Time is mutable. Mutable time is an axiom of software. If time were immutable, software would cease to exist since computational progression would cease to exist.

You expect referential transparency from your encryption function, yet you failed to acknowledge that you passed time as an argument to that function - therefore, it *did* produce the same result (from that perspective) for its given arguments.

Here's something for you to ponder: Is System.currentTimeMillis() referentially transparent?

Here's a related puzzle:
http://www.travelfurther.net/fun/fsquad.htm

[Henry Wong]

It's actually interesting that certain encryption algorithms generate different values with the same input. What is happening is that a random seed is generated (and used) with the encryption keys to encrypt the data. The seed is actually part of the cipher data -- and not encrypted -- so that the decrypt algorithm can work.

Not sure of the main reason why it was invented, but I can envision it being very good for small packets. If the encryption wasn't random, it is possible to easily figure out if two small packets are the same -- generating some sort of pattern (infering from the unknown data).

Henry
[ September 07, 2006: Message edited by: Henry Wong ]

[Ashish Chopra]

Well, as far as I know, RSA does not involve any time based computation(, so the reasoning given that the encryption algorithm could have a time-based function to provide randomness in the generated cipher-text is incorrect.

RSA encryption is a deterministic encryption algorithm-- i.e., has no random component-- an attacker can successfully launch a chosen plaintext attack against the cryptosystem, building a dictionary by encrypting likely plaintexts under the public key, and storing the resulting ciphertexts. When matching ciphertexts are observed on a communication channel, the attacker can use this dictionary in order to learn the content of the message.

This is practical RSA implementations typically embed some form of structured, randomized padding before encrypting. This padding ensures that the message does not fall into the range of insecure plaintexts, and that a given message, once padded, will encrypt to one of a large number of different possible ciphertexts. The latter property can increase the cost of a dictionary attack beyond the capabilities of a reasonable attacker.

I hope this clears up all queries you had.