My BLT
in [Cryptography]
|
From: bmearns on 1 Mar 2010 06:35 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
From: David Eather on 1 Mar 2010 16:38 On 1/03/2010 9:35 PM, bmearns 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 Yes, amongst the best. I suspect that the general "problem" is that WTS doesn't have the tools / knowledge to properly use and evaluate computer based encryption and thus he confabulates comparisons between hand cipher complexity and computational complexity. At least that is what it is looking like to me.
From: WTShaw on 4 Mar 2010 04:51 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.
From: WTShaw on 4 Mar 2010 05:01 On Feb 28, 9:37 am, Mok-Kong Shen <mok-kong.s...(a)t-online.de> wrote: > 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 BLT was never expected to do so much, merely do a few choice things. I was surprised that it even worked, but time and work tends to reach most goals. Anyway, the program is much better at doing what it does than the poor clerk that I am also being that I can't really write these days more than a few characters at one sitting. I'm familiar with the detailed instructions of how to break various checkerboards and there is probably a best way to so attack BLT other than being a cryptogenie as ACA seems to have some of them. 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.
From: WTShaw on 4 Mar 2010 05:43
On Feb 28, 10:24 pm, David Eather <eat...(a)tpg.com.au> wrote: > 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. Anything is a factor, even as one area might not look so. Amongst goals of a cryptographer are to frustrate a hacker even to giving up, however. If my pRCG looks like overkill, so be it. BLT was an experiment, still is, subject to tweaking for what it is worth. Frankly, I prefer a counted hash for making the key but that can introduce clerical error faster than a pangram hash so I'll probably make both. For the pro's, it's run the possible keys and search for meaningful content. |