My BLT
in [Cryptography]
|
From: WTShaw on 4 Mar 2010 06:32 On Feb 28, 11:13 pm, David Eather <eat...(a)tpg.com.au> wrote: > 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. Broken, not so. Fun, OK for less than the test. Autodictive ciphers are incestious puzzles at most, and in a unkosher parody of usefulness a replacement for wordfind at least.
From: bmearns on 4 Mar 2010 06:33 On Mar 4, 5:01 am, WTShaw <lure...(a)gmail.com> wrote: > For BLT, never forget brute force for searching all the possible > keys. That alone removes it for serious use beyond a certain number > of triads, whatever that is. Actually, there are 27! (more than 10^28) possible keys. Each is the same as 5 others, but that still leaves more than 10^27. I think it would likely hold up rather well to brute force attacks. -Brian
From: WTShaw on 4 Mar 2010 06:44 On Mar 1, 5:35 am, bmearns <mearn...(a)gmail.com> wrote: > On Mar 1, 12:11 am, David Eather <eat...(a)tpg.com.au> wrote: > [snip] > > > The part I personally don't understand is why, when almost everyone who > > has responded to you asks for clarifications, you still persist in > > gibberish? That does rather suggest that the point of your posts is to > > make yourself sound important rather than to do anything useful. > > If you really want to see some of his master work, check out the > thread "Extending the length of a key" from a few weeks ago. > > -Brian That thread is unfinished, did not run away, It's time to kill some more dragons methinks. Meanwhile, I'm really enjoying reading Thomas Hardy as his contrived studies in human nature apply even here. I like it...his sentences are so "flowery."
From: WTShaw on 4 Mar 2010 06:55 On Mar 4, 3:51 am, WTShaw <lure...(a)gmail.com> wrote: > On Feb 28, 7:57 am, bmearns <mearn...(a)gmail.com> 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, 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 > > If I don't get back on the group here, it's because of time > conflicts...but I do need to say more picking up at the tops posts. > We'll see how much time I can devote to this as I have a busy schedule > tomorrow. > > I've seen an error in my program that probably did not make too much > difference. The javascript version was taken in function from old > source circa 1995. Originally, I started with the straight generic > key to make things work and simply eliminated allowing the slant sign, > the last character in the key, to be accepted into ciphertext. > > I failed then to adjust the statements when I build a dynamic key > process, so the result was that the 27th character of the key was > nulled out. Now, that's fixed. I've also made a version that rejects > use of the original plaintext character in any triad that represents > it. > > That said, the distribution of ciphertext characters remain > essentially a random distribution that can change just on the picking > function with the pRCG alone. The advantage of the generator is that > it is directly character driven rather than with pRNG driven where > several additional steps are needed to get back to letters. > > The pseudo random results might look something like this from the > previous dumb ciphertext: > > Total Characters = 690 from 'abcdefghijklmnopqrstuvwxyz' > a 21 3.039073806078148% > b 22 3.183791606367583% > c 36 5.209840810419681% > d 23 3.3285094066570187% > e 24 3.4732272069464547% > f 41 5.933429811866859% > g 25 3.61794500723589% > h 19 2.7496382054992763% > i 37 5.354558610709118% > j 21 3.039073806078148% > k 15 2.170767004341534% > l 36 5.209840810419681% > m 27 3.907380607814761% > n 18 2.6049204052098407% > o 40 5.788712011577424% > p 25 3.61794500723589% > q 16 2.3154848046309695% > r 36 5.209840810419681% > s 27 3.907380607814761% > t 15 2.170767004341534% > u 32 4.630969609261939% > v 31 4.486251808972503% > w 28 4.052098408104197% > x 31 4.486251808972503% > y 23 3.3285094066570187% > z 21 3.039073806078148% > > The idea is to eliminate cribs, no, nada, none. In the known example, > you can work backwards but the unknown is another story. > > The idea of looking for a match between plaintext and ciphertext, or > total omissions is important because like the enigma, missing letters > were key, pardon the pun, to breaking it, and daily keys. > > Taking the above ciphertext and decrypting it, it's simple to see it > to be: > "it is rather simple to use the normal alphabet in standard form > chased by a slant sign as the key for blt x a dumb blt decoder is > rather limited but it does make its point as it easily hides > information j at least from the dumb x " > > Using the key "the /qu ick bro wnf xjm psv laz ydg" to encrypt to > shield plaintext letter us and running the frequencies, they are as > follows: > > a 25 3.61794500723589% > b 41 5.933429811866859% > c 28 4.052098408104197% > d 21 3.039073806078148% > e 15 2.170767004341534% > f 23 3.3285094066570187% > g 18 2.6049204052098407% > h 19 2.7496382054992763% > i 42 6.078147612156296% > j 16 2.3154848046309695% > k 15 2.170767004341534% > l 36 5.209840810419681% > m 19 2.7496382054992763% > n 27 3.907380607814761% > o 13 1.881331403762663% > p 36 5.209840810419681% > q 27 3.907380607814761% > r 27 3.907380607814761% > s 26 3.762662807525326% > t 37 5.354558610709118% > u 15 2.170767004341534% > v 19 2.7496382054992763% > w 39 5.643994211287988% > x 41 5.933429811866859% > y 49 7.091172214182344% > z 16 2.3154848046309695% > > and next pass: > > a 17 2.4566473988439306% > b 39 5.635838150289017% > c 25 3.6127167630057806% > d 27 3.901734104046243% > e 15 2.167630057803468% > f 17 2.4566473988439306% > g 18 2.601156069364162% > h 28 4.046242774566474% > i 39 5.635838150289017% > j 23 3.3236994219653178% > k 16 2.312138728323699% > l 39 5.635838150289017% > m 21 3.0346820809248554% > n 26 3.7572254335260116% > o 20 2.8901734104046244% > p 44 6.358381502890173% > q 19 2.745664739884393% > r 21 3.0346820809248554% > s 30 4.335260115606936% > t 34 4.913294797687861% > u 18 2.601156069364162% > v 13 1.8786127167630058% > w 36 5.202312138728324% > x 44 6.358381502890173% > y 47 6.791907514450866% > z 15 2.167630057803468% > > and will be different each time it is run. > > Rock climbing methods would probably work to break any text but double > encryption with a second key would present quite another problem and > words would disappear as cribs. The postings of frequencies are fodder for analysis, something you might not have in different forms. Different keys would produce greater variances. With more work, a technique might begin to develop, some sort of interference pattern of the trigraphs.
From: bmearns on 4 Mar 2010 08:48
On Mar 4, 6:33 am, bmearns <mearn...(a)gmail.com> wrote: > On Mar 4, 5:01 am, WTShaw <lure...(a)gmail.com> wrote: > > > For BLT, never forget brute force for searching all the possible > > keys. That alone removes it for serious use beyond a certain number > > of triads, whatever that is. > > Actually, there are 27! (more than 10^28) possible keys. Each is the > same as 5 others, but that still leaves more than 10^27. I think it > would likely hold up rather well to brute force attacks. > > -Brian Come to think of it, this cipher might be better suited to stego than crypto. There are 27! different keys, each being equivalent to 5 others. So there are effectively 27!/6 different messages that can be encoded in the choice of a key, which is just over 90.5 bits of information. An encoding system, using the factoradic number system for instance, could be used to encode a hidden message into a key. An innocuous message containing a crib would be encrypted using that key, and sent to your partner. With the crib, they could recover an equivalent key rather quickly and easily, and then recover the hidden 90 bits from that key. An enemy could easily do the same, but hopefully would think that the message was the important part, and forget about the key. -Brian |