OSDev.org

Applied Cryptography, gotcha .

Oh man - Im saving up to buy Tannenbuams OS book... How much will the Encryption one cost

Damn NZ skyrocketing prices.

And yes,I figured music would be a bad source, since its so repetitive and hiding parts of a key inside of the encrypted file was dumb too, sicne I mean - ITS RIGHT THERE.

As for no security with obscurity, I think thats not entirely correct.
Just its a crappy method for security. That I will agree on .

Erm - heres the stupidest question of the night..
:S Will I have to be really, really good at Mathematics to stand a chance and making anything slightly neat?

Mathematics isnt exactly my strong point. *sigh*

Well, I feel like an idiot now. HURRAH!
Hehehe, regardless - its still fun. .

~Zeii.

I do not know enough to know how much math you really need, but I would expect you do - and think it would be very helpful to be fluid in math.

@Solar:
You mean my encryption is not h8ckor 3lit3? You have hurt my h8ckor feelings, and since I have no girlfriend I am going to write a virus called "solar32.destroyer" and p@wn you. You dirty curry dog.

Solar wrote: I strongly suggest you start with the book "Applied Cryptography" and continue from there. You're collecting all the beginners mistakes in this single thread.

zeii wrote: I dont suppose generating the other keys from the encrypted file itself would help much? *shrug*

Actually that would be among the stupidest things to do.

That's called making a key schedule from your key. It doesn't directly increase security but if you do it right, you won't remove security. DES weak keys are based on the DES key schedule (just read that in Applied Cryptography *cough*).

As for truly random key generation, I have no real idea how to do that and I dont happen to have a tasty Plutonium shop nearby. .

In a stock desktop? You don't, full stop. You can get close to true randomness by collecting entropy. I won't start explaining this, as you have to have understood the foundations to stand any chance of getting it right. You should be able to find appropriate papers by googling for "entropy randomness"...

The idea is that you have unpredictable events, of which you take a number of bits that can't be predicted. If you read from a harddisk, you'll have a delay between the issuing of the command and reading of data. That delay is on average between 1 and 20 milliseconds. If you then take the millisecond-modulus of that, you'll have a number between 0 and 999 that's pretty much unrelated to anything else happening.

I'm thinking of using rdtsc to come up with a random bit of data belonging to a clock or hardware timing that's completely unsynced from the cpu. So, you could use the lowest few bits for network traffic (although I'm not sure how many bits are actually entropic enough), some bits for harddisk interfacing etc.

FYI, /dev/random is a random entropy source that can be exhausted (and will then block on reads). /dev/urandom is a pseudo-random number generator that will never block but that also doesn't contain much true entropy.

Here is my publish for thy encryption KME1.

This is a detailed document explaining the algorithm for the encryption and decryption of digital data. This document uses the ANSI C Standard for the C language to explain the algorithm where not explained by english. If you have any relavent messages such as but not limited to questions and comments; you may send them by internet mail to the address "[email protected]". You may also send relavent messages via the United States Post Office to:
"Leonard Kevin McGuire Jr.
366 East Skipper Road
Eclectic, Alabama 36024"


The encryption process is done in blocks. Each plain text block is one forth the size of the encrypted block, and one eighth the size of the key block. There may be one to ~ key blocks. Each plain text block is applied with the key block of current key block index, then the key block index is advanced. The key block index will be repeated from the beginning once it reaches the end. This causes the key blocks to roll like a circular chain over the plain text blocks producing the encrypted blocks.

This is the process of a text block applied to a key block. Let A and B be a thrity-two bit value. Let X be a eight bit value. Let E be a thrity-two bit value.
E = ((X + A) * (X + A)) + B

At random events one or more fake encrypted blocks will be inserted using the current key block index for all in sequence for this event.
W != Q
E = ((W + A) * (Q + A0)) + B

The decryption process is the reverse of the encryption except: All encrypted blocks must:
P = sqrt(E - B)
And, P must have no fractional part. If P has a fractional part the block must be ignored, and the current key block index must not be incremented.

A fix for some unexpected results.

@Solar:

And, analysis of the algorithm is done on the source level, not on the plaintext / cyphertext level...

This is correct? I attached it.

[edit]
Apparently - the board does not like attachments from me. So, I tried renaming the attachment. Then deleting the attachment from the previous post, and finaly attaching either of them to either post using the modify button.. >:(

Once more.. Trying to attach the file.