Re: My BLT

On Feb 28, 7:57 am, bmearns <mearn...@xxxxxxxxx> wrote:
On Feb 26, 5:32 pm, WTShaw <lure...@xxxxxxxxx> wrote:

On Feb 25, 11:38 am, bmearns <mearn...@xxxxxxxxx> wrote:

On Feb 25, 10:45 am, WTShaw <lure...@xxxxxxxxx> 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.


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.


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

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

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

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.