Can anyone explain how genetic algorithms can be used in cryptography?
Genetic algorithms are optimizing problems, and they use some kind of pseudorandom code as key. How this key can be transferred to the receiver?
They are unlikely to be of much use in general. Genetic algorithms rely on a reasonably small change in output for a small change in input -- that allows them to close in on a good solution to the problem.
Cryptographic algorithms are designed to have a large change in output for a small change in input. A good hash algorithm will flip around half the output bits if a single input bit is changed.
That makes genetic algorithms in general little better than a brute force search.
Related
I am doing an extended essay in computer science and i am stuck on what to do. I am interested in the topic of the AES algorithm or any encryption algorithms. However as computer science is a science subject i must conduct an experiment. However i am unsure as to how i should test it.
I thought about encrypting different types of files eg. videos, photos and word files ect, and testing the data transmission speeds or encryption speeds compared to other encryption algorithms. I wondered if any of you could tell me how to do this or recommend a different experiment. It cannot be too difficult that i cannot do nor too easy that it is not worthy of a good grade. Thanks. P.S. I a 17 (Year 12)
Certainly there is a wealth of opportunity for research here. Good for you for being curious about this and looking into it. You will likely want to control for a few variables and test along the following lines:
symmetric vs. asymmetric encryption (i.e. AES vs. RSA)
different symmetric algorithms (i.e. Rijndael (current AES algorithm) vs. Blowfish, DES, TDES, etc.)
different block cipher modes of operation (i.e. CTR vs. CBC vs. GCM, etc.)
different data sizes (i.e. does it scale linearly? Does it take exactly 1000x as long to encrypt 16 bytes vs. 16_000 vs. 16_000_000?)
You'll want to run these experiments on the same hardware, under the same load, in the same language, many times in order to get decent data. Especially considering that modern CPUs have the AES-NI instruction set, and custom registers for encryption data, remember to seed your experiments, or subsequent runs could have different performance profiles.
If you do not have previous coding experience, Java, Ruby, and Python all have very popular cryptography libraries and a broad community which is happy to support you if/when you run into challenges. If you're already familiar with one or more specific languages, I'd suggest using one of those, as it will be tricky enough to learn the cryptographic-specific instructions; learning a new language is probably an unnecessary burden to add on at this time.
I think this is sufficiently vague that you will still have to do the research and investigation for your paper, but should provide a starting point. Feel free to follow up with specific questions if you need.
Cryptographic Mavens,
Would you be so kind as to offer a bit of background for a cryptographically-related scene in a novel?
Assume the good guy has to decrypt a dozen image files...yet does not know either the system used to encrypt the files, or their key(s).
Unlike the TV/Movie hackers who crack such files after ~5 seconds of furious keyboarding...what (in your opinion) would be plausible (not necessarily through or completely accurate) approaches to (1) determining how the files were encrypted (i.e., what encryption system was used?), and (2) how to attempt decrypting them for viewing?
Your suggestions...thoughts...ideas--maybe even a reference or two (Amazon?)--will be gratefully appreciated.
Thank you,
Plane Wryter
You can't. A reasonably good encryption algorithm will yield data that is statistically almost pure normally-distributed "random" data. (i.e. undecipherable, unrecognizable, high entropy)
The only way you could do this was to brute-force passwords through a brute-force list of password-derivation functions, into a brute-force list of crypto algorithms (i.e. really freaking hard).
I'm doing a IT diploma and Mathematics also be tought there.In these days, we have to learn Difference Equations(recurrence relations) and I'm confused with what are the usages of these concepts in different areas of IT like computing, algorithms and data structures, circuit analysis, etc.
Can someone please explain why we learn these concepts and usage of them. It will be helpful my learnings.
Unutbu has an excellent explanation and link to what is a recurrence relation. Here is a small window into the why.
Computer scientists need to know how algorithms compare to one another (in terms of speed or memory space). The Recurrence Relations help provide this comparison (on an order of magnitude).
Here is a general question: How many possible moves in chess are there? If there are 318 billion moves (for the first four), could you use an exhaustive algorithm to search for the best, first move? If that is impractical, what algorithms might trim that to a reasonable size? The complexity measures give us an insight into the difficulty of the problem and into the practicality of a given algorithm.
Recurrence relations come up in complexity theory. The number of steps performed by a recursive algorithm can be expressed as a recurrence relation, such as
The goal then is to express T as (or bound T by) a (hopefully simple) function of n.
The master theorem is one example of how this is done.
I am reading about cryptography I was thinking about these properties of AES (that I use):
same message = same ouput
no message length secrecy
possible insecurity if you know the messages (does this actually apply to AES?)
I hear that AES is secure, but what if I want to theoritcaly improve these properties?
I was thinking I could do this:
apply encryption algorithm A
XOR with random data D (making sure the output looks random in case of any cipher)
generate random data that are longer than the original message
use hashing function F to allocate slots in random data (this scrambles the order bytes)
Inputs: Encryption algorith A, Data to XOR with D and a hashing function F
My questions are
does the proposed solution theoreticaly help with my concerns?
is this approach used somewhere?
Possible enhancements to this approach
I could also say that the next position chosen by hashing function will be altered using a checksum of the last decoded byte after the XOR step (that way the message has to be decoded from beginning to end)
If I was to use this to have conversation with someone, the data to XOR with could be the last message from the other person, but thats probably a vulnerability.
I am looking forward to your thoughts!
(This is only theoretical, I am not in need of more secure encryption, just trying to learn from you guys.)
Yeah.
Look. If you want to learn about cryptography, I suggest you read Applied Cryptography. Really, just do it. You will get some nice definitive learnings, and get an understanding of what is appropriate and what is not. It specifically talks about implementation, which is what you are after.
Some rules of thumb:
Don't make up your own scheme. This is almost universally true. There may be exceptions, but it's fair to say that you should only invent your own scheme if you've thoroughly reviewed all existing schemes and have specific quantifiable reasons for them not being good enough.
Model your attacker. Find out what scenarios you are intending to protect against, and structure your system so that it works to mitigate the potential attacks.
Complexity is your enemy. Don't make your system more complex then it needs to be.
Stay up to date. You can find a few mailing lists related to cryptography and (and hashing) join them. From there you will learn interesting implementation details, and be aware of the latest attacks.
As for specifically addressing your question, well, it's confusing. I don't understand your goal, nor do I understand steps 3 and 4. You might like to take a quick look here to gain an understanding of the different ways you can use a given encryption algorithm.
Hope this helps.
You assumptions are incorrect.
same message != same output
The output will not be the same if you encrypt the same message twice.
This is because you are suppsed to use different IVs'.
Message length can be hidden by adding random data to the plaintext.
Attacks have been demonstrated against AES with lesser number of rounds.
Full-round AES has not been compromised in any way.
Other than that I suggest you follow Noon Silks recommendation and read Applied Cryptography.
What's the point of the random data XOR? If it's truly random, how will you ever decrypt it? If you're saying the random data is part of the key, you might as well drop AES and use only the truly random key - as long as it's the same length (or longer than) the data and is never used more than once to encrypt. It's called a one-time pad, the only theoretically unbreakable encryption algorithm I know about.
If the random bits are pseudo-randomly generated, it's highly unlikely that your efforts will yield added security. Consider how many talented mathematicians were involved in designing AES...
EDIT: And I too highly recommend Applied Cryptography, it's an actually very readable and interesting book, not as dry as it may sound.
Imagine I have this:
$cdata = AES_256($data, $pass);
AES_256 implements the AES algorithm.
If I know the content of $cdata and the content of $data and also have
the AES_256() code, can I reverse engineer and find $pass?
Simple answer: NO.
This has been tested, and mentioned in the Wiki link.
A related-key attack can break up to 9
rounds of 256-bit AES. A
chosen-plaintext attack can break 8
rounds of 192- and 256-bit AES, and 7
rounds of 128-bit AES, although the
workload is impractical at 2128 -
2119.
Or put it another way: you have a better chance of being struck by lighting... on the same day you win the Lottery, than breaking it!
This is called a known-plaintext attack. A good cipher like AES should be immune to it, as the others explained.
If $pass is actually a password and not a 256-bit key, you may be in luck.
While it is far from trivial to perform, a brute-force attack against a normal password is much faster than brute-forcing a 256-bit key.
So modify one of the many password-brute-forcing tools, and you have a attack that (depending on the strength of the password) might take weeks to several years - but that is fast compared to 3x10^51 years...
Another quote, from Wikipedia:
AES permits the use of 256-bit keys.
Breaking a symmetric 256-bit key by
brute force requires 2^128 times more
computational power than a 128-bit
key. A device that could check a
billion billion (10^18) AES keys per
second would require about 3 x
10^51 years to exhaust the 256-bit
key space.
Brute forcing when you know the original text might be faster but still, 3 x 10^51 years is a long time. Plus there's the problem of probably not having a device that can check a billion billion (10^18) keys/second.
In short: everything is possible, but this is not feasible in the world we are now living in.
You could brute force it, but it would take a long time. As in decades or even longer. That's the point of encryption algorithms like AES.
AES, like all good crypto algorithms, doesn't rely on security through obscurity.
In other words, there are no "secrets" in the code, so you having the code won't help you particularly.
Known plaintext is a separate issue, which I don't know much about so I'll leave that up to the other answerers.
Of course not - the only approach is brute force.
Do you really think NIST is so stupid as to choose a cipher that is so easily cracked for a new standard?
with the power of super computers the time to crash AES encryption with be dramatically shortened.... I heard...
2x2^256 possible combinations is a lot to bruteforce. But bruteforcing is the only way. It would actually take about 3 decades. AES is the best Encryption possible right now I'd say. But that would only take that much time using a CPU. Because GPU's (Graphic Processing Units) are strictly math based, people have been making programs that only use the GPU to crack math based algorithms much more quickly than a CPU could. In other words AES might not last 3 decades. If only eternity codes were possible. Well looks like dynamic encryption may be the only way people can really hide their information in the near future.