encryption

Started by
19 comments, last by Zahlman 18 years, 3 months ago
Quote:Original post by Scoob Droolins
'm thinking that people trying to crack encrypted files are not going to figure out how your encryption algorithm works. they're going to look for a 'black box' in your code that takes in an encrypted file, and spits out a decrypted file. then they will try to extract this code, and make it into a stand-alone app that decrypts your files. if so, then there are tactics one can do to make the job of extracting code more difficult. any validity to this notion?
No, they won't even bother extracting it, they'll just make a program that loads your program, sets up the right information (like putting a 'return' intruction at the end of the decrypt part if it doesn't have one, setting up the arguments to the function, etc), and jumps straight into your code.

Then later, the psuedo-encryption will be examined by somebody bored, and they'll write their own library that anybody can use to encrypt and decrypt using the right algorithm.

"Walk not the trodden path, for it has borne it's burden." -John, Flying Monk
Advertisement
Quote:Original post by Gorax
[...]It all depends on exactly how far you want to go with it. Mine's fairly simple, but also fairly effective.
[...]I can't name them because I only did it for something to do while I was bored, rather than actually studying cryptography to learn how to do it.[...]
So what you're saying is "I don't know anything about cryptography, but I made this great cryptographic algorithm!" ?

If you don't want much security, you can use a simple algorithm like the 'tiny encrypion algorithm'(TEA) that is something like 10 lines of very fast, freely available C code that uses 64 bit keys and works on 64 bits of data at a time.

If you want a decent amount of security, you need to use a well-known algorithm in the proper manner, which means you need to know what you're doing.

Neither option includes "make something up without knowing what you're doing." The only reason to do that is that you want to use something you fully understand without studying cryptography at all, but in that case the best option would be to just xor a psuedorandom number with each byte (starting with a seed that is the 'key').
"Walk not the trodden path, for it has borne it's burden." -John, Flying Monk
Hmm. The TEA variant I have has 128bit encryption by using two 64bit keys. TEA's a relatively trivial block cipher to implement, loads of good examples around the place.

If you're interested in encryption the things to start with are large integers and modulo arithmetic on them and (strong) pseudoprime generation (Rabin-Miller or Solovay-Strassen are easy enough to get your head round).

Writing your own classes to deal with these is a good learning experience - many people just say use Open SSL or some other crypto library, but if you don't need the code-bloat and are willing to do some head-scratching I'd vote roll your own.
Winterdyne Solutions Ltd is recruiting - this thread for details!
My mistake, I misremembered. TEA uses 128 bits of key material to encrypt 64 bits of data.
"Walk not the trodden path, for it has borne it's burden." -John, Flying Monk
Quote:Original post by u235
I was reading up on encryption algorithims and came across something that said 128-bit encryption is the best because with 128-bit you can't decode it simply by trying every key. First I would like to ask if this is true.


You can decode something encrypted in 128-bit by a brute force attack, but the time required to do so is measured in millions of years.

A more realistic expectation for having your data decrypted is someone breaking into your house, getting a copy of your secret key, and installing a key logger on your computer. See United States v. Scarfo for more info.
Quote:Original post by Gorax
It does have some flaws. For instance, I'm using an ints (32 bits) and chars (8 bits) instead of defining new types with the same sizes for different platforms. That and it can't encode or decode anything less than 32 bits (but then again, why in the hell would you want to encode anything less than 32 bits?).


It has some flaws...? Oh really.... well, the complete lack of a security track record seems like a major flaw, which makes your algorithm completely useless for any purpose what so ever. Wanna launch a new crypto algorithm? The first thing you should have ready is some experiments that demonstrate that your algorithm is not vulnerable to common cryptanalysis attacks. "Cryptography is easy" my ass.
Quote:Original post by Will F
You can decode something encrypted in 128-bit by a brute force attack, but the time required to do so is measured in millions of years.


Just so I am clear, this mean that there are (128!)*2 possible combinations for a 128-bit key? So for a n-bit key, the number of possible keys is (n!)*2? But if that were the case, why is 256-bit or even higher encryption not more popular. It seems every e-commerce website boasts about their 128-bit encryption. Is there something unique about 128 that makes it better than anything else?

-AJ
V/R,-AJThere are 10 kinds of people in the world: Those who understand binary and those who don't...
Quote:Original post by u235
Is there something unique about 128 that makes it better than anything else?


No, It's just that 128 is enough not to be crackable. That's it. Sure, you could use larger keys - but what would you gain?

Quote:Original post by u235
[...]Just so I am clear, this mean that there are (128!)*2 possible combinations for a 128-bit key? So for a n-bit key, the number of possible keys is (n!)*2? But if that were the case, why is 256-bit or even higher encryption not more popular. It seems every e-commerce website boasts about their 128-bit encryption. Is there something unique about 128 that makes it better than anything else?[...]
No, it's a standard number system problem: Bits are base 2 'digits', so N bits can store 2^N (^ meaning 'raised to the power of') values, which for 128 bits comes out to a 38-digit number.

If a computer could test 2^32 keys per second (which I don't think a consumer PC could), it would take 2^96 seconds (32+96=128), which is a LONG time.

For comparison, a year is almost 2^25 seconds (quite a bit less actually, but 2^24.911... isn't as nice a number). That means that 2^96 seconds is 2^71 years, which is 2361183241434822606848 years.
"Walk not the trodden path, for it has borne it's burden." -John, Flying Monk
Oh ok, cool. Thanks for the explanation.

-AJ
V/R,-AJThere are 10 kinds of people in the world: Those who understand binary and those who don't...

This topic is closed to new replies.

Advertisement