Actually you are wrong about that, as one of the jobs of a cryptananlist is doing exactly such discovery, since the enemy will not always provide you with the algorithm they use.
And knowing the algorithm would not aid you in any way. I don't reveal it because it is a trade secret and posting it on a forum where foreign nationals are KNOWN to frequent would be a felony.
Last edited by abachler; 09-01-2009 at 12:49 PM.
unless I'm wrong, that is what he meant... merely cracking the code IS important, but discovering the algorithm that generates it is far more important, since later messages in the same algorithm might as well be plaintext.
It does if you know the key though, which kalor seems to take to be part of knowing the algorithm. In a sense it is.
It is too clear and so it is hard to see.
A dunce once searched for fire with a lighted lantern.
Had he known what fire was,
He could have cooked his rice much sooner.
I take it you mean because in order to know the algorithm, one would have to break the cypher.
I think IceDane made a distinction that doesn't apply. In the absence of an algorithm, the problem that is presented to a cryptanalyst is that of solving the cypher. The distinction between algorithm and plaintext is blurred in the methods used to achieved this, assuming no further knowledge can be gained. Probably -- this is my guess -- under many circumstances one can even only construct the algorithm after they solved the cypher. If it can be constructed at all... (edit: incidentally this last statement does give IceDane some credit. hmm...)
I believe abachler to be quite right in that not knowing the algorithm is a strong weapon. Today we do have algorithms that give away nothing; AES, Blowfish, etc. So this isn't such an important issue anymore. In any case, for weaker algorithms this can still be an important concept.
Last edited by Mario F.; 09-01-2009 at 10:00 PM.
Originally Posted by brewbuck:
Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.
I did mis-state myself earlier... I did imply that the key is part of the algorithm, which in a wierd sense, it is, but it wasnt really what I meant. I meant more (and was looking the wrong way at it, and my approach wouldnt have worked well) like, in attempting to break the cipher, one could attack the algorithm itself, using it to produce a key, testing against the encrypted text, repeat as necessary. A faulty approach, now that I think more about it.
Could it, in theory, be possible to use a key as a weapon against the same algorithm? This is more what I had in mind. With both the plaintext and encrypted text in hand, together with a key (which you successfully broke, so you know that it is genuine), would it be possible to perhaps, use the data to generate other keys, regardless of strength? Especially if you could then encrypt the plaintext you had before, compare for similarities and patterns, and start compiling methods to come to the same result? I wouldn't expect it to be done in a person's lifetime against a REAL encryption system, but it would eventually yield results, right? (long after the entire system was trashed for the new version, but still).
I guess it would be like trying to reproduce a door key for every house in the world, and then some, based off the information gleaned from ONE house key... but is it possible?
Well, if you are going to claim success because you completely fail to comprehend the subject matter then there's no point in continuing the discussion.
But yes, if I tell you how to decrypt it and then tell you the key, its trivial to crack, and there isn't a single useful algorithm in the world that would provide the least bit of security in that case.
Generally no, given a plaintext, key and ciphertext and the algorithm, it is not possible to instantly read ciphertext created with other keys.
Last edited by abachler; 09-02-2009 at 12:27 AM.