OSDev.org

Hey all, its me...

Another night when I cant sleep.
I have this crazy idea, for Symmetrical encryption.
(Yes, my slaughter of the English language continues,
but give me a break - I havent slept in over 73 hours.)

I wont go into details at the moment, simply because the concept
hasnt entirely solidified in my brain but regardless, the idea has
me all excited.

So, basically - Im just posting here to ask if Symmetrical encryption
is still useful and if any of you would benefit from a crazy encryptor
being written.

I think ill tell my Lecturer about my idea, see what he thinks.
Hes oldish and wise and and and knowledgable, so I figure if anyone will
burst my insomnia-powered bubble itll be him.

Anywho, thats my little mini-rant.
~Zeii.
PS: I may have my Buddy allocator finnished too in the near future.

Great idea. Publish it here with full description, a sample plaintext of 4-8 blocks and corresponding cryptotext and let at least some of us hack away at it. Been reading Applied Cryptography and I'm feeling like exercise

PS: This isn't in the middle of the night, I'm in Washington for the moment.

Im not sure when ill have to code done, or even if I have the skill.

But, ive been focussing on what the Key will do, Ive been spending time thinking of how I can 'morph' the key... and such.

Ill post the design when the concept is atlesat semi-coherent.

You guys rock!
~Zeii.

oh, and does it matter if the CIA or Governments of the world can break it?

Basically, as far as I know on my design - If you have the key, you can reverse the encryption on a file.

If you have the sourcecode for the encryptor and the file thats encrypted, you should be able to reverse engineer yourself a key - It just might take a long time.

Because youll see how the encryptor made the key and how the key relates to the scrambling?.

I know thats crap?.
But I dont think im ready for Assymetric Encryption yet.

~Z

What you are describing sounds just like any symmetric encryption which bases its strength on the key, not on the secretness of the algorithm... However, parts of what you said sound interesting, keep posting.

Candamir

Candy wrote: Great idea. Publish it here with full description, a sample plaintext of 4-8 blocks and corresponding cryptotext and let at least some of us hack away at it.
Been reading Applied Cryptography and I'm feeling like exercise
PS: This isn't in the middle of the night, I'm in Washington for the moment.

It is a salted hash. Uses a key that is varible in length and independant of the message length. The plain text was 42 characters long and contained A-Z, a-z, and spaces.

CRYPT:F78C0A880893C2A01A3111DB153E0EDC07FCC2A00CEF152FC3E014DA127917D911E20634
KEY:A397A255

It is not a hard one at all. I have no idea what it would be called since it is so simple it has to have already been done.

PLAIN-TEXT:This is a sample plain text
CRYPT:F78C0A880CEF152FC3E00BDD16D5C2A00437C2A016D50335\\
104B12300FB40789C3E012300FB403350CEF1086C3E0168408931AD8176C
KEY:A397A255
REVERSED:This is a sample plain text

(add) Oh, and to help out it can encrypt the entire ASCII range, not just letters and spaces.

Hmmm...

Rule #1 to tell an encryption algorithm is "good": Source code, or at least a detailed algorithm description, is public. As soon as you start circulating your decryption / encryption software around the web, it'll be reverse-engineered anyway.

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

Seconded, if an algorithm is worth the electrons used to display it then you should be able to distribute source and not worry about it being compromised. In general (with most key based algorithms currently), you can reverse-engineer how the key is generated as much as you want, but without the seed you've still got no way to figure out what came out of it.

Precisely what I meant.

If someone got their hands on the source, they would be able to understand how the encryption is done, aswell as how keys are generated.

Like you said, without the exact seed used in Key generation, the key they get will be bogus and thus decrypting using the bogus key will just end up with even more giberish.

The point is - If someone had a powerful enough computer and say, the Seed used was the time in seconds since 1970 - couldnt they just cycle from then to now, starting from seed 0, to seed whatever, decrypting over and over and over until they end up with something that doesnt result in giberish?

Eventually, the lock would crack open and the encrypted data would be decrypted?

Of course, you could always fry the encrypted file through decryption. So, that someone couldnt try and decrypt it again - since itd be all bjorked.

~Zeii.

You could try a brute-force approach, but with most modern schemes you're looking at longer than your lifetime (or at least the lifetime of the data being valuable) to be able to crack it. And you could do that without the source anyway (well, without the key generation source, you'd need to know how the decryption was performed at least)

ps: Probably easier to follow the conversation if you stick to one username

The point is - If someone had a powerful enough computer and say, the Seed used was the time in seconds since 1970 - couldnt they just cycle from then to now, starting from seed 0, to seed whatever, decrypting over and over and over until they end up with something that doesnt result in giberish?

Exactly why encryption, if it's important, should use the closest thing to random data that you can. If you can get a hold of a true random data source (decay of a radioactive source is a good common one - and one that can be relatively easily and legally). Number of seconds from 1970 is 1,166,832,000 (effectively a key length of 31 bits) at the start of 2007. You're right - this is really exceptionally easy (depending on the algorithm and implementation it'll vary, clearly) to simply brute force. Using pure random data with an algorithm that won't produce collisions and with a key length of only 256 bits then you have 2^256 possible combinations - a very, very, very big number indeed (~1.157x10^77 according to Windows calculator) and considerably harder to break (assuming a perfect algorithm that cannot be cracked in any other way).

As for whether or not you want to protect it from the government... A good methodology to stick to is that encryption will be cracked. Eventually. Even if it takes 15 years (a la DES) to be publicly known how to crack it. No matter how you feel about the security services, there is no doubt that NSA/GCHQ (Government Communication HQ - the UK SIGINT/cryptologic equivelant) have some very, very, very intelligent people working for them.

But sure, please post it up once you have the design 'finalised' in your head. I'm interested, if nothing else because of curiosity and challenge.

Most of the basic design is done in my head, Im just working on ideas I can use to distort data more .

The idea of a Polymorphic key is simple! (Probably already been done, but thats my name for it.)

I figure it like this : Why not make a key that works like a Guitar? .
A person plays aguitar by pressing frets and striking the string.

Why cant a key itself be hundreds, even thousands of other keys by screwing with its individual bits in certain ways.

If you can encode 64 characters securely (512bit cipher?) [before scrambling...], If you could mess with that 512bit cipher 512 times - you could encode 32kB of characters securely - without a repetition from the same key calculations used in distortion of said data.

You could do hundreds of bit manipulations on that 512bit key to create hundreds of other related keys - that are all needed to decrypt the file fully and correctly!

A different key used for each segment of the file - the key figures used in the most basic part of the scrambling, then a whole bunch of other crazy scrambling schemes are used, so that the data is hardcore gibberized!

Once the file is scrambled by information from the Key, its scrambled a few more times with a generic method, then scrambled again using Key data - of course, the key data being used isnt precisely the same key that is in the KEyfile or whatever, its a key related to that key, one of the keys that 'spawn' from the key in the file.

The key itself.. in the file will be statically encrypted too, just for a little extra fun.

*shrug* thats the basic gist of it?

~Zeii.
PS: Sorry if this is kinda.. unclear and babbly, I went for a walk, REALLY cold outside and now im all tired and numb.

I doubt that'll help too much as the method of spawning the extra keys will have to be public, so if they find the first key (which they would have to find to crack it without this) then they can generate the extra ones straight off anyway.

If all the extra keys were random in themselves (so having a new key for each xkb of data), it's pretty much that other technique that I forget the name of... scratchpad? Something like that.

Hmm...

Thats a good point.

However, How could you store the extra keys? without ... storing them .

Having a 64byte file to hold the key... which would start everything off, and different keys being generated somehow - which would be identical to the different spawned keys during encryption.

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

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. .

Although, If you used keys... that came from places no one would expect, wouldnt that help?

Like, making a recording of ambient sound in a city, scrambling it a little with music ... then selecting a random bunch of digits from the corresponding digitzed version of said recording?.

I dont know.

I do know that its fun to talk about this stuff though .

~Zeii.

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.

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"...

Although, If you used keys... that came from places no one would expect, wouldnt that help?

The strength of a cryptographic algorithm comes from "fast if key is known, slow if key is not known". Key width is simply scaling the quality of the algorithm, not a quality in itself. Key randomness doesn't come from "unknown source". Randomness is simply random, "unknown source" is simply obscurity, and there's no security in that.

Like, making a recording of ambient sound in a city, scrambling it a little with music ... then selecting a random bunch of digits from the corresponding digitzed version of said recording?.

Music is a very bad source for randomness, because it's highly structured, predictable and repetitive.

I do know that its fun to talk about this stuff though .

It is, as long as you are aware that you don't get security unless you learn the foundations and do it right. Everything less than that is toying around. If you are aware of that, everything's OK.