My BLT
in [Cryptography]
|
From: WTShaw on 25 Feb 2010 10:45 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.
From: WTShaw on 25 Feb 2010 10:54 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.
From: bmearns on 25 Feb 2010 12:38 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
From: WTShaw on 26 Feb 2010 17:32 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. And, in reference to David Eather's frequency tables, such an application as BLT, inductive encryption, makes skewing occurances of ciphertext letters in spite of plaintext rather much of a possibility than much help in decryption. spaces could be entirely ignored and particular ciphertext letters could be encouaged or even eliminated. In the case if a pangram key, much of it is not in clear words. The challenge in the first posting remains unsolved regardless of hand waving to the contrary. For those that can't take a real challenge, I offer the following: The Dumbest Alternative for BLT It is rather simple to use the normal alphabet in standard form chased by a slant sign as the key for BLT. A Dumb BLT Decoder is rather limited but it does make its point as it easily hides information, at least from the dumb, dumber, and dumbest. yuxra tofuv lixjs cuoef rapvu dbyon shwki forux vpacr qwvno abpls eqocr lptbq fxolc pridy vbefx crpwg itjeb foihz wekct rfhqg yvpns rulxg pjzso wldpi emjga stywq lvbcx fyloe qzxfc igjla evsgq hzanj pvdtl iskpr xomwf qbrzx oewmc ildsu vcwyj sfpad thmqp ofryg bicmf lrvay ouxld gwmry vabzw idkfu rljdv fopry ekhuc xpdao vguci lsnvx wjzbl orkmn sqzof vlrxp eftwu bolcf rvsbt ycumn fxoie uclrm agocl dzjfm xthgs vqico gjhkd fumbr ilyzm vbeds fwzlm hyaek niolu xacri dvofx zicds povtg uzmbe ncxui obsfp lxwzg jrics qgznm hpuof yvkls xogzi lrpuc fvwri umesn wiakz cdmui fewgm ydqvb jhkxc idoul ynrsj coizf atwcg xiqhe lpwfo umvjl ygrfo jicum qrlfj tevdy cmgpl fbjcu xslif vrqso uykad ewfjg colpf izkev wxnhi bcrtw mgdax yhmrf wtihb kourw vsxiu agycm efrun vomzw jdgia ylmhc frpbu noxhw iknsc oxljn afesb hrixm wsldo zevpg hfuir noxfc Of course you could rot13 the ciphertext and really upset the unwashed. LOL
From: WTShaw on 26 Feb 2010 17:46
On Feb 24, 7:00 pm, David Eather <eat...(a)tpg.com.au> wrote: > On 25/02/2010 6:09 AM, bmearns wrote: > > > A nice proof that reasoning beats brute force. Bad logic does no good here as while a pile of numbers may look impressive, it means little. You can be careful to avoid certain letters in plaintext and watch BLT put them in ciphertext anyway. Skewing can be conscious to lead attackers to chase rabbits. However: Making BLT Stronger BLT ciphertext is in alphabetic letters of course. And, the usual method is to use some sort of random like alphabet for a key, not like the message at all. Ciphertext can be encrypted a second time, perhaps with any spaces between groups removed. Or another key could be used in the second encryption. However, after two encyptions the ciphertext would be about nine times the length of the original plaintext, really disgusting. There are better and more efficient ways. |