Well, I never thought I would find myself in this forum, but I realize that more and more protections use cryptography, so I need to learn as least some of it. Please don't flame me, I have some basic questions just to know if I'm on the right track of thinking at least. For some reason I love programming and computer code but math usually bores the hell out of me, why is that ? LOL Encryption uses math theories, so that's why it takes me a little longer to absorb it.

SO without further ado, some basic questions:

1. Ok. Bruteforcing. How do you go about this in a practical way? In a real target, say you have the following info:

a. Encryption method
b. Ciphertext (of course)

Now, wouldn't you either have to also at least find part of the key or some plaintext to attack it?


2. I've noticed in some crypto systems, like the crypto used in Ryan's Code-Lock, which I am looking at for fun, use random numbers (well , actually psuedo random). How exactly does this random number tie in with the whole crypto process ? for example, I've seen keygens that produce a different key each time you press the button, but every key will work the same i.e, they allow you to register. So there must be some sort of constant relationship going on.

Well I guess that's all for now. I'm sorry if these questions are so basic you want to slap me I have yet to find a "Crypto for dummies"

-nt20

Hi there nikola

I'm starting in crypto too (same thing with the math), ended up on a target with encrypted keys and was wondering the same thing about bruteforcing.

I have the encoded string (duh...)
The encrypted string contains a first name, last name and a serial which I have too (about box for names and Hardcoded "decrypted" keys).

What do you do next ?
Else, if(how?) you find the encrypt/decrypt routines, how do you use it to create other encrypted keys ?

Coersum

OK for code-lock:

you get code-lock create.exe, used to encrypt your full version program. it takes:

1. "Program code". This is a code you make up as a "password"
2. The program itself.

It then compresses the program and encrypts it.


you also get code-lock keygen.exe. Used to generate a key for a particular user. it takes:

1. User ID. "Unique" for each machine you are on.
2. User Name.
3. Program Code.

It generates a registration key from these.

Now finally you have the protected app. The reg box on this takes:

1. User ID. It's given to you automatically.
2. User Name
3. Reg key

So my thoughts are, the encrypted program uses the "program code" as its private key? .. ah too late tonight to think clear..



-nt20

Some statistical property of the plaintext is usually enough; for example, in text, the high bits are all zero. If you decrypt something wrong (and the encryption algorithm isn't a toy) then you'll get pure random noise, which is very easy to distinguish from structured data.

The simplest thing you can do is a chi-squared test: you expect all the bytes to occur with about the same frequency if the key is wrong. So for each character c, let N(c) be the number of times c occurs in the decrypted message you're testing and L be the length of the message. Find

(N(c)- L/256)^2

and sum them all up. Anything with a distribution other than random will stick out like a sore thumb.

You have to have a lot of text for chi squared to work, though, like 2K or so.

I've been wondering, what do you do when the plaintext is compressed? ie. how would you go about attacking a file that has been encrypted after it was zipped/rarred/aced/etc ? Are there any other statistical methods you would use in this case?

If you know the format of the compressed file, then you have some known plaintext to check for. Often a simple thing to do is to get the source to the decompressor and run whatever you decrypt though it. If the decompressor returns an error, your password is wrong.

If the decompressor is the kind that can decompress even random garbage, then you do the statistical test on the output.