|
Assuming that most of you reading this have read my previous article, or haven't, but know the information that I covered there, I think it's safe to move on to some more advanced, and probably much more interesting topics.
Though my previous article did not get too technical, you can expect this one to be a bit mathematically involved, and by all means more difficult to understand, confusing, and maybe even a bit dull, but please, be patient.
Now, we all know what an algorithm is, and we all know some of its most common and basic functions, and finally we know its 3 most common uses in cryptography and security.
More advanced cryptographic security protocols.
A. Asymmetric encryption -
Now, symmetric encryption, which I covered in my previous article, is all well and good, but it has its downsides.
The largest and most noticeable one is that distributing the keys to the right people, at the right time, is extremely difficult, and tricky. There is always the chance somebody stupid will leak it, if it were said in words it could be overheard, or recorded. If it were written on paper and distributed who knows if this paper gets disposed of in the proper manner? And I can't even begin to stress the danger of distributing the keys electronically. Asymmetric encryption, also known more commonly as public-key encryption, takes care of this problem in a fairly secure and efficient manner. It allows messages to be sent in full safety whether electronically or otherwise.
There was a time, and many people may still believe this to be true, that it was thought this kind of protocol of encryption was simply impossible. Not because the technology was impossible, as it obviously isn't, but because such a widespread level of communication (i.e. the internet) did not exist. Also because people felt that other people, some which they barely knew, couldn't be trusted (of course once I describe asymmetric encryption in detail, you'll see why that makes no sense).
The idea is just like all cryptographic ideas that came before it, and most that came after, use a mathematical algorithm that is easy to compute, but hard to reverse-engineer. You could imagine the length of such algorithms, including exponentially larger and larger numbers with each line, prime factorization, the list goes on and on. Simple math in moderation, but you get it long enough, and perhaps have whole algorithms x other algorithms, and you have yourself a practically unsolvable problem, unless a computer is involved, but even then, it could take days, weeks even to compute. And that isn't a reasonable speed.
In symmetric encryption, person A, and person B share one key, this isn't the way asymmetric encryption works. The keys are both very different, and you cannot deduce one key, just by having the other and reverse-engineering it.
Person B for instance, can create these keys for any given cryptographic algorithm he chooses, he can publish the encryption one, but keep the decryption one secret. person A can then encrypt the message, send it to person B, and person B never has to share the decryption key. He keeps his messages secret, and he also keeps other people from being able to read them. Asymmetric encryption is the standard protocol for just about any sensitive information sent electronically, as it should be.
It does get more complex, for one thing, person B is unlikely to be able to remember his key, as for true security it needs to be extremely long. I'll get to this soon. But that aside, it all works out well.
B. Digital Signatures -
These are the most splendid and useful of all cryptographic protocols, in my opinion. Digital signatures are very similar to MACs, which I covered in my previous article, but are also different for certain reasons I'll get to shortly.
Digital signatures use their own pairs of keys (differently derived than those used in asymmetric encryption, but similar enough to be talked about in laymen's terms).
Once again, you cannot come upon one key, by reverse-engineering the other, this is important.
It goes like this. Person A has a message, she encrypts it with his private key. Because his key is private, and does not change without notifying person B, the message is encrypted in a certain, ideally unique, way. The way the cyphertext looks is his signature. Person B then uses his key to decrypt the message, if it works, then he can assume the message is really from person A, and not forged, and that the digital signatures worked properly. The decryption key, in this case, is the public one, and anyone therefore can verify that it is indeed a message from person A. This is roughly how certificates, and other security protocols, work during data transfer online.
An important thing to not is, by the nature of the encryption, nobody can copy/paste or in any other way forge the signature. This happens because the signature is, in a way, an operation that depends upon the content of the message, and since the message is in cyphertext, the algorithm for the public key cannot even begin to be reverse-engineered.
There is something to note. Digital signatures do not actually encrypt the message, rather calculations are made based on the length of the message (as well as other variables) and it is replaced with the correct signature. Then the receiver makes calculations, and uses the public key to replace (or, in a sense, decrypt) the message. This seems complicated, and it is, and that's why computers generally do it for you...
C. Random Number Generators and Brute-forcing -
Firstly, random numbers for certain, theoretical, reasons are regarded as impossible to formulate, but a level of randomness can be achieved (if this makes no sense to you, I apologize).
Random numbers, and brute-force methods of breaking them, are considered to be the most time-consuming, and primitive, cryptographic function. Though they are just as widespread and important as anything.
Every system depends on codes that are usually consistent, at least partially, of numbers. The "randomness"�, and length (once again I'll get there) is what the security of some systems practically solely depends on.
People have varying opinions on this, but it is most widely accepted that it is impossible to be truly random (in the most pure sense of the word). Because there is a certain scope of possibility, and since it's impossible to make this scope infinite, it is believed that within an acceptable amount of time, every future "random"� number can be derived in advance. This is very iffy, and has not been proved well enough to be a fully credible theory, but we'll accept it for now.
What we must ask is, what is random exactly? Well, for security's sake I believe that in this case it speaks of numbers being produced that cannot be formulated in advance, and within the next reboot of the generator cannot be reproduced at an equivalent time (i.e. after the same amount of numbers). There are other definitions, and other people might expect different things, but I think for this article, the above standards are acceptable.
There are many interesting ways that certain real-life events can be analyzed and then reproduced to create an algorithm for random numbers. For instance, it is known that one can use diodes in hardware circuits, and measure the noise they make to determine their random numbers. Other even more interesting ways exist, and natural, or anomalistic events are the best way to determine them. Because it is literally impossible by today's and the near future's standards to be able to conceive of an algorithm that can determine the results ahead of time (if such a thing is even possible at all). Some programs compute them by analyzing user input. We all know that the human is the most random of all existing creatures, or, one might say, natural processes.
It is relatively simple to break through random number generators. One is to take a large scope, of say 3, to some exponent, of possible lengths, and compute every single possibility. This can take impossibly long periods of time, and for that reason random numbers are secure, and without the algorithm with which they are produced, are almost impossible to crack.
D. The Importance of Key Lengths -
This is going to be a very short, and very simple section. Firstly I'd like to state, that assuming the same types of symbols are used (i.e. all numbers, or all ASCII symbols, or all letters + numbers, etc.) the longer the key the better. This is true 95% of the time, approximately.
The reasons for this are pretty obvious, one that most readily available brute-force programs begin with shorter codes and work up towards the longer ones, this is not always true, but generally it is. And even in the case that it's reverse, it would still take longer to compute the longer strings of numbers.
The other reason that it's exponentially more difficult to find a key per each digit/letter/symbol of the key. This is pretty self-explanatory. You might ask, why not use a key consisting of millions of digits? This is because it would also be too large to reasonably use when decrypting/encrypting, it would take too long to be reasonable. But a compromise can be reached, so that the key is long enough to be relatively secure vs. brute-force, and still be short enough to be efficient enough in data transfer.
There isn't much more to say on key lengths really, just keep in mind, within moderation, the longer the key, the better the security.
E. Pseudocode -
Algorithms are written and displayed in mathematically-oriented code known as "pseudocode"�. This code is not particularly similar in many ways to C, Java, and other large-scale computer languages.
What is different about pseudocode is that in pseudocode any protocol can be displayed, or expressed, in any means that are most efficient for the specific case. I.e. it could be displayed mathematically with variables or without, in plaintext english, or even in a foreign language if that is the case.
The way this works is that a section of pseudocode can be embedded in a section of true, computer code. Of course the computer doesn't understand it unless it is programmed to, but it is useful for describing the algorithms processes in full.
The other difference is that pseudocode and true computer code, is that pseudocode has nothing to do with software. Computers do not except plaintext in the midst of code, so unless the computer is programmed to, pseudocode only concerns peoples' understanding of algorithms, and when they are written out and analyzed by people, they are written partially in pseudocode.
I should note that pseudocode, as I had said earlier, that if a computer is programmed to understand it (when it's written in the proper format) it can also be used in conjunction with the true code. Of course, the point of doing so is beyond me.
This relates mostly to the human factor. Pseudocodes are used so that people better undestand algorithms, and often, when packages of security programs are sold, pseudocodes (whether people realize it or not) are provided so people better understand what's going on, and they are also used in analyzing algorithms.
These are some of the slightly more advanced concepts in cryptography and algorithms, I hope you enjoyed the article, and hopefully you learned something too...
source: http://neworder.box.sk/newsread.php?newsid=4973
|
Subscribe to this comment's feed
Show/Hide comments
Show/Hide comment form