XOR Encryption, how safe is it?

[Sensei]

Setting the clock, now from Java? It doesn't look very complicated.

http://www.java-tips.org/other-api-tips/jni/set-the-computer-clock.html

Above code uses

Win32 API SetLocalTime() function:

https://msdn.microsoft.com/en-us/library/windows/desktop/ms724936(v=vs.85).aspx

 

Quote from MSDN (Microsoft Developers Network):

"Remarks

The calling process must have the SE_SYSTEMTIME_NAME privilege. This privilege is disabled by default. The SetLocalTime function enables the SE_SYSTEMTIME_NAME privilege before changing the local time and disables the privilege before returning. For more information, see Running with Special Privileges."

 

Not to mention you are mixing "Java run in web-browser", with "Java real application"..

 

http://abeytom.blogspot.de/2012/12/set-system-time-from-java.html#!/2012/12/set-system-time-from-java.html

Quote

"This command can only be executed as an administrator. So we have to start an 'Administrator: Command Prompt' and execute the program from it.To 'Start a Command Prompt as an Administrator' on windows 7 use Start -> type 'cmd' -> hit 'Ctrl+Shift+Enter'. Please refer to Microsoft Technet for detailed steps on how to start an 'Administrator: Command Prompt'"

 

Edited May 21, 2015 by Sensei

[John Cuthber]

to be fair, this bit is true or reasonable hyperbole

"Any encryption software that takes the clock to start a pseudo-random sequence is at obvious risk of running always the same sequence.

This is basics about cryptography. Not using pseudo-random sequences as one-time pads, too. Doing both results in the crypto code having zero strength."
The strength isn't zero- that's sending plain text- but it's poor practice.
I'm unconvinced that the issue is the use of the clock to seed the RNG. The problem is using a pseudo-random sequence in the first place.

If there is a seed and an algorithm for generating the numbers then Eve can steal it or guess it.

However, I'm waiting (with rapidly diminishing patience) for an example of a website that can mess up the clock on my PC without asking me.

(And I am running this machine as an admin)

[Thorham]

Any encryption software that takes the clock to start a pseudo-random sequence is

at obvious risk of running always the same sequence.

No. It depends on the system. In situations where the clock can't be set by some

external means using a time stamp as a nonce is fine.

 

This is basics about cryptography.

You shouldn't see everything so black and white, and instead look at a crypto

system's requirements, which will partially depend on the system it has to run

on.

 

Not using pseudo-random sequences as one-time pads, too. Doing both results in

the crypto code having zero strength.

So, basically you're saying that every block cipher is completely broken?

Do you have any proof for this?

 

The best to do now is give up the arguments, remove the faulty crypto software,

It's absolutely astonishing that you still refuse to see the point. I gave an

example of how you can construct a nonce for AES-CTR. I used a time stamp in the

example to show that the nonce only has to be unique. That was the whole point

of the example. That the security of using a time stamp as a nonce depends on

certain factors isn't relevant (it can, of course, be secure, but that wasn't

the point).

 

Nowhere did I recommend using time stamps as a nonce for AES-CTR. I said that

you could, because for AES-CTR a nonce only needs to be unique for each file

you encrypt with the same key. That this is only a good idea in certain specific

system setups is blatantly obvious.

 

You've also mentioned several times that you shouldn't use PRNGs for encryption. Why?

What's so bad about using cryptographic PRNGs?

 

The problem is using a pseudo-random sequence in the first place.

If there is a seed and an algorithm for generating the numbers then Eve can steal it or guess it.

Stealing the seed means that you're stealing the encryption key. As for guessing it, good luck with that,

unless someone used a weak key without a salt. Doesn't matter though. Secure cryptographic PRNGs have to

be brute forced, or in the best case you can do a little bit better than that. Not practical.

Edited May 21, 2015 by Thorham

[John Cuthber]

There is, in principle, a difference between pseudo-, and real- random number generation.

If the sequence is truly random (and only known to the two participants) then you can use OTP and get provable security.

If you use a PRNG then, because the repeat length is finite, you can, in principle, hack it- as long as the message is long enough.

So, from a theoretical stand point, PRNG is "broken".

In practical terms the brokenness is too small to worry about unless you are sending huge amounts of data (or, equivalently, using too short a sequence).

 

Stealing the seed (and knowing the algorithm) isn't quite the same as stealing the key.

The key- the pseudorandom sequence- has to be at least as long as the message (since we are talking about XOR as an encoding method).

The seed might be 22:01:05

And, if you know roughly what time I sent this message then guessing it isn't that difficult.

 

But I'm sure we would all like to see this magic trick that resets the clock on my PC without asking me.

[Thorham]

Stealing the seed (and knowing the algorithm) isn't quite the same as stealing

the key.

Actually, it is, because the key functions as the crypto PRNGs seed. For example,

with AES-CTR you encrypt a nonce and a counter, the resulting block is XORed

over a plaintext block. One AES block is 16 bytes. 12 of those are used for the

nonce, the remaining four for the block counter. The seed is now a combination

of the encryption key, the nonce and the counter. Since the nonce and counter

are known, stealing the unknown part of the seed is the same as stealing the key.

 

The key- the pseudorandom sequence- has to be at least as long as the message

Yes, but not the key. The key length isn't relevant for the length of the

pseudo random sequence. The length of the sequence depends on the algorithm

that's used and the size of the internal state of the generator. For example,

the non-cryptographic PRNG 32 bit XOR shift has an internal state of 32 bits,

and a seed size of 32 bits (seed is state in this case). The length of the

sequence is 2^32-1 32 bit numbers (all unique).

 

The seed might be 22:01:05

And, if you know roughly what time I sent this message then guessing it isn't that difficult.

Of course, but in practice you'd use a proper encryption key (with salt), and

the time stamp may be safe to use as a nonce. The seed is now made up of a salted

key and a nonce. The nonce is known, but the key isn't. Any very weak, unsalted

key has a good probability of being guessed.

 

But I'm sure we would all like to see this magic trick that resets the clock on

my PC without asking me.

Indeed.

[John Cuthber]

The problem there is that 2^31 isn't very many combinations to try.

Also AES CTR isn't just XOR.

If you use a "proper" key then you are not using the time as that key.

[Thorham]

The problem there is that 2^31 isn't very many combinations to try.

(2^32)-1, sorry. No, that's not a problem, because XOR shift isn't a cryptographic

PRNG. I used this as an example for something. I also said it's not cryptographic.

 

Also AES CTR isn't just XOR.

In AES-CTR mode AES is used as a block cypher. It's output is simply XORed over

the plain text. So, yes, it's just XOR, because nothing else is done with the

plain text. This, in fact, creates a weakness to tampering: If I change bit 123

in the cypher text, then bit 123 will also be changed in the plain text once the

data has been decrypted. It's just XOR.

 

If you use a "proper" key then you are not using the time as that key.

I never said you should use time as a key