My BLT
in [Cryptography]
|
From: bmearns on 28 Feb 2010 08:57 On Feb 26, 5:32 pm, WTShaw <lure...(a)gmail.com> wrote: > On Feb 25, 11:38 am, bmearns <mearn...(a)gmail.com> wrote: > > > > > On Feb 25, 10:45 am, WTShaw <lure...(a)gmail.com> wrote: > > > > Now are you meaning an encrypted message which is also the source for > > > the key? It seems that if they are not the same that solution could > > > be less fun. > > > Are you asking what I attacked, or what I was jokingly suggested is > > posted in Sundays papers? For the attack, I had an encrypted message > > and a short crib for it. In other words, I had a matched pair of > > cipher text and the plain-text that generated it, from which I was > > able to deduce all three pools in their entirety, and was able to > > populate 15 entries in the table. In practice, this sort of partial > > solve would allow me to partially decrypt other messages for which I > > did not have a crib, and then using intelligent guesses about > > undeciphered characters, could create additional cribs to continue > > filling in the table. > > > For instance, if I my partial solution allowed me to decode "q?een of > > heart?", I could reasonably guess that the missing letters were u and > > s; and I could then use the corresponding trigraphs to fill in those > > two letters in the table. The point, of course, is that a partial > > solve can be quite effective, and I was able to get a partial solve > > using a relatively short crib. > > > -Brian > > You missed the difference between using BLT as a keyed cipher in which > there is no crib to use as an autodictive cipher which you chose to > solve. As an exercise, the later may be instructional, maybe. Well as we've well established, and as I freely admit, you seem to know a lot more about cryptography than I do, and at any rate I am very much an amateur in the field. What I "chose" to solve was the exactly problem that you posted: I attacked a plain-text/cipher-text pair generated exactly the way you described it in the original post. If there are stronger ways to use the cipher, it's probably worth your mentioning that. Perhaps it is simply my lack of experience and knowledge in the field, but I can't imagine how a certain type of cipher could be crib-free. Cribs---at least in the general meaning of the term that I'm using here, which is simply a sample of known plain-text and the matching cipher-text; if there is a more particular definition I'm unaware of, I would certainly love to know it---are not a feature of the cipher, they're the result of non-cryptographic activities carried out to learn more information about the communications being attacked. Certainly some ciphers are more resistant to a known-plain-text attacker, but that doesn't mean the crib doesn't exist. -Brian
From: Mok-Kong Shen on 28 Feb 2010 10:37 bmearns wrote: > WTShaw wrote: >> You missed the difference between using BLT as a keyed cipher in which >> there is no crib to use as an autodictive cipher which you chose to >> solve. As an exercise, the later may be instructional, maybe. > > Well as we've well established, and as I freely admit, you seem to > know a lot more about cryptography than I do, and at any rate I am > very much an amateur in the field. What I "chose" to solve was the > exactly problem that you posted: I attacked a plain-text/cipher-text > pair generated exactly the way you described it in the original post. > If there are stronger ways to use the cipher, it's probably worth your > mentioning that. [snip] With the kind help of one follow-up of yours, I understand that BLT consists of fractionalization in the way of trifid (but without the subsequent recombination to make the length of the ciphertext equal to that of the plaintext) followed by a homophonic transformation using a 3*9 matrix. WTShaw seems to have neglected (for no reasons apparent to me) the transposition processing that is ubiquitous in all fractional substitution schemes to my knowledge. If the stuff generated as you explained is followed by e.g. a keyed columnar transposition, then the analysis would be a lot harder, I surmise. (But maybe what I said is inappropriate, for I haven't very closely followed the course of your long discussion with WTShaw.) M. K. Shen
From: David Eather on 28 Feb 2010 23:24 On 26/02/2010 1:54 AM, WTShaw wrote: > On Feb 24, 7:00 pm, David Eather<eat...(a)tpg.com.au> wrote: > >> >> A nice proof that reasoning beats brute force. > > The question is beyond fun as to what can be learned from this cipher, > and as an interesting aside, from the program that implements it. To > part of that I offer the following which contains something that could > have another use, programming being sometimes an equally amusing > activity, sometimes not: > > BLT Repetition Inhibitor > > This is built around a pRCG, pseudorandom character generator, that > helps pick each allowed character from one of three pools except for > recently used six characters starting with those in an avoid string. > The slant sign is never used as a contender ciphertext letter. > > I have not gone so far as to actually prevent otherwise identical > trigraphs from being automatically avoided in a given ciphertext > output, but they should be rare. Humans could do better at avoiding > such duplications...or worse and in other details for sure. Now...on > with the show, no balloons however, and this should not leave you > light headed. > > Like for a pRNG, pseudorandom number generator, an initial seed is > required and stored as a global value. As the pRCG is called within > the encrypt function, the seed value changes. The global value is > updated at the end of the encrypt function to reflect the current > value and it is actively displayed. The current seed can be modified > for any special reason simply by changing that field, but otherwise it > should be left alone and be allowed to advance on its own. > > The heart of the pRNG is found in these most simple lines of Java > Script code in which the value of the seed is reiterated: > > newindex = (key$.indexOf(seed$.charAt(0)) + key$.indexOf(seed > $.charAt(1)) + adder) % 26; > > newchar$ = key$.charAt(newindex); seed$ = seed$.substring (1,lenseed$) > + newchar$; > > The seed$ is the current seed and should be at least several > characters long. > The newchar$ is the character just generated. > The adder is a constant to be in the range 0 to 25, best not as zero. > The key$ is a 27 character dynamic deranged alphabet, better than > plain a to z. > > The open source nature of Java Script allows custom setting of the > constants. > Three Major Functions in BLT deal with key setup, encryption, and > decryption. > Note that the pRCG is exercised in Encrypt and not needed in > Decrypt. > > It's all very simple with ciphertext selection aided by an extremely > long period pRCG. but this does not add any obstacles to the way the cipher was broken.
From: David Eather on 1 Mar 2010 00:13 On 26/02/2010 1:45 AM, WTShaw wrote: > On Feb 24, 2:09 pm, bmearns<mearn...(a)gmail.com> wrote: > >> >> A final note about the analysis: the exact order of the table doesn't >> necessarily have to match the original. The table I came up with >> through the analysis is actually different from the one that was used >> to encode the message originally, but as long as it is self consistent >> and consistent with the crib/ciphertext, it should work. > > Before I saw you posting, I had added to the thread this morning a > piece that said the same thing. With a suggested likely key, it > should be simple to check for the 6 possibilities where the indexes of > 1, 2, and 3 are rearranged. >> >> All in all, it was kind of a fun game, somewhat similar to soduko. >> Maybe they should start publishing these in the Sunday paper. >> >> -Brian > > Anything to keep the idle busy and amused...Ok, fun for all, at least > for some. > > Now are you meaning an encrypted message which is also the source for > the key? It seems that if they are not the same that solution could > be less fun. Why would that be? Bmearns has already broken that version of your cipher and described it as fun.
From: David Eather on 1 Mar 2010 00:22
On 28/02/2010 11:57 PM, bmearns wrote: > On Feb 26, 5:32 pm, WTShaw<lure...(a)gmail.com> wrote: >> On Feb 25, 11:38 am, bmearns<mearn...(a)gmail.com> wrote: >> >> >> >>> On Feb 25, 10:45 am, WTShaw<lure...(a)gmail.com> wrote: >> >>>> Now are you meaning an encrypted message which is also the source for >>>> the key? It seems that if they are not the same that solution could >>>> be less fun. >> >>> Are you asking what I attacked, or what I was jokingly suggested is >>> posted in Sundays papers? For the attack, I had an encrypted message >>> and a short crib for it. In other words, I had a matched pair of >>> cipher text and the plain-text that generated it, from which I was >>> able to deduce all three pools in their entirety, and was able to >>> populate 15 entries in the table. In practice, this sort of partial >>> solve would allow me to partially decrypt other messages for which I >>> did not have a crib, and then using intelligent guesses about >>> undeciphered characters, could create additional cribs to continue >>> filling in the table. >> >>> For instance, if I my partial solution allowed me to decode "q?een of >>> heart?", I could reasonably guess that the missing letters were u and >>> s; and I could then use the corresponding trigraphs to fill in those >>> two letters in the table. The point, of course, is that a partial >>> solve can be quite effective, and I was able to get a partial solve >>> using a relatively short crib. >> >>> -Brian >> >> You missed the difference between using BLT as a keyed cipher in which >> there is no crib to use as an autodictive cipher which you chose to >> solve. As an exercise, the later may be instructional, maybe. > > > Well as we've well established, and as I freely admit, you seem to > know a lot more about cryptography than I do Don't bet on it. Shaw claims, inter alia, to be a biologist - the science you do when you can't do maths. , and at any rate I am > very much an amateur in the field. What I "chose" to solve was the > exactly problem that you posted: I attacked a plain-text/cipher-text > pair generated exactly the way you described it in the original post. > If there are stronger ways to use the cipher, it's probably worth your > mentioning that. > > Perhaps it is simply my lack of experience and knowledge in the field, > but I can't imagine how a certain type of cipher could be crib-free. > Cribs---at least in the general meaning of the term that I'm using > here, which is simply a sample of known plain-text and the matching > cipher-text; if there is a more particular definition I'm unaware of, > I would certainly love to know it---are not a feature of the cipher, > they're the result of non-cryptographic activities carried out to > learn more information about the communications being attacked. > Certainly some ciphers are more resistant to a known-plain-text > attacker, but that doesn't mean the crib doesn't exist. > > -Brian |