CT-ONLY BREAK of VeeCrypt cryptosystem

[Richard Heathfield]

I had an idea for an attack on VeeCrypt that does not require any known
plaintext.

As is usual for me in such cases, I'm going to give you a blow-by-blow
account - this article is being composed iteratively: do some work,
write it down, do more work, write it down, etc.

Whether it's going to *work* is of course something that I don't know at
this stage, but by the time we get to the end of the article I'll know
one way or the other.

IF IT DOESN'T WORK, I will change the Subject line from:

"CT-ONLY ATTACK on VeeCrypt cryptosystem"

to:

"IDEA FOR CT-ONLY ATTACK on VeeCrypt cryptosystem"

:-)

Update: it works just fine, and I decided on "BREAK" rather than "ATTACK".

Partly to keep the length of this article within manageable bounds, and
partly out of sheer embarrassment, I won't be showing source code. If at
any point you want source code, say so and I'll think about posting it.
But I didn't get paid for writing this code, so it's likely to be quick
(to write), dirty (to look at), and crap (not very robust). On this
occasion, I don't care, because the proof of the pudding is in the
plaintext (if I can get at it).

Now, I should explain the context of the attack.

I challenged AOB to provide me with seven short ciphertexts (c. 60
characters, about ten English words), all encrypted with the same key
and using the same "variant" (whatever the hell that is).

He declined, because he knows VeeCrypt is not secure enough to withstand
such an attack.

Seven? Why seven? Well, it was a finger in the air. A guess. I don't
know how many ciphertexts this attack will need. If it works, though, it
shouldn't need many. My instinct is that seven will be plenty.

Of course, his refusal does mean I'm stuck for ciphertext. I have a copy
of VeeCrypt, but I have no idea how to change the key. So I'm going to
have to use the key that's already in there. AOB will therefore claim
that I'm cheating, but everybody else knows, I trust, that I'm not.

Also, I've had to choose my own plaintexts. I did this by picking seven
lines at random from an English text corpus. Have I seen those lines?
Yes. But that was, oh, about an hour ago [at the time of writing that
sentence: it's now three and a half hours ago], and I've already
forgotten them. (I do, however, know where they came from, and I'll do
my best to forget that knowledge.)

If this attack works out, I'm sure I'll be able to repeat it with other
ciphertexts supplied, perhaps, by willing collaborative Eves with their
own copies of VeeCrypt.

Finally: I'm going to stop, *not* when the job is done, but when it
becomes obvious that either (a) this is working, or (b) it isn't.

Even if it doesn't work out, I'm still going to post this article
because it may inspire someone else to come up with a modification that
might work better.

Now, the first job is pure housekeeping. I have to give you the
ciphertext, and AOB's formatting is just dreadful. So I wrote a program
to format the ciphertext into nice columns.

Here, then, are the ciphertexts:

ct01.txt:
-57 -29 -95 -89 -54 347 -93 -25 267 12 -82 -8
-64 -99 -88 -96 -58 -98 -86 -29 -78 -16 -89 -68
-94 -28 -96 -86 13 -109 -109 76 -102 -4 -39 -58
-91 -85 -90 126 -23 -53 -99 -101 -36 -76 152 -93
-29 -16 -102 -19 -40 -80 6 -106 -76 6 -82 -93
-27

ct02.txt:
-56 -98 -28 -90 -42 356 -100 -94 277 91 -77 -93
-75 -22 -93 -107 -64 -97 -17 -101 -86 -99 -12 -69
-101 -106 -85 -92 -56 -20 -95 161 -87 -83 -47 -82
-25 -91 -76 209 -107 -49 -89 -22 -37 -82 163 -87
-105 49 -58 -88 -50 -76 13 -102 -89 14 -95 -93
-27

ct03.txt:
-57 -113 -28 -97 -34 340 -25 -103 276 26 -80 -84
-80 -22 -93 -104 -70 -102 -17 -108 -20 -83 -88 -82
-83 -103 -17 -103 -59 -89 -108 161 -107 -73 33 -58
-109 -12 -82 144 -106 -61 -32 -22 -26 -73 146 -91
-111 49 -98 -84 -51 -90 10 -101 -78 82 -96 -93
-27

ct04.txt:
-60 -98 -111 -94 -51 358 -93 -94 345 15 -77 -87
-66 -91 -91 -25 -68 -104 -82 -111 -97 -92 -81 -71
-30 -28 -19 -57 13 -88 -109 161 -98 -83 -51 7
-106 -97 -79 125 -92 23 -90 -101 -37 -79 151 -109
-41 47 -18 -91 -37 -7 0 -88 -80 14 -26 -93
-27

ct05.txt:
-57 -29 -115 -75 -45 348 -94 -93 345 23 -77 -95
-69 -22 -107 -104 15 -104 -89 -98 -13 -99 -96 -68
-100 -101 -96 -94 13 -107 -103 77 -92 -4 -51 -65
-94 -89 -18 209 -88 -55 -88 -22 -45 -75 161 -100
-29 -38 -83 -97 -36 -76 1 -92 -75 82 -96 -93
-27

ct06.txt:
-67 -101 -97 -92 -45 344 -92 -100 345 51 -77 -84
-68 -91 -106 -25 -72 -85 -100 -29 -97 -98 -77 -81
-99 -98 -96 -98 -64 -89 -98 161 -107 -76 -36 -71
-25 -84 -75 209 -110 -42 -103 -22 -33 -82 146 -22
-114 -31 -97 -97 32 -90 -2 -90 -79 82 -77 -93
-27

ct07.txt:
-68 -101 -97 -10 -3 344 -108 -92 266 14 -64 -77
9 -70 -102 -104 -61 -32 -17 -116 -85 -89 -79 -75
-16 -101 -100 -16 -52 -20 -106 88 -104 -88 -43 -62
-25 -94 -75 140 -91 10 -91 -95 -43 -87 230 -105
-101 -20 -87 -103 32 -86 13 -23 -94 17 -96 -93
-27

Okay.

Now, I'm going to write my programs in such a way that I can choose how
much ciphertext to give them. This is an attempt to see just how much
ciphertext I actually *need*. I know I can't do it with one, but I don't
know whether or not I can do it with two. So I'll start with two, and
bring in new ciphertexts only when I have to.

This is an attack on the KEY, not the ciphertexts themselves. Once I
have the key (and I mean the real key, not the nonsensical obfuscated
version found in the source code), I can decipher /everything/ that is
encrypted with that same key and that same "variant" (whatever the hell
that is).

All right, so this key is *huge*, right? So brute force is not an
option. (It's never an attractive option anyway.)

But if we can /reduce/ the number of possible keys, a la Turing, we
might bring the problem into the realm of the achievable. That's the
plan, anyway.

(This is beginning to sound like one of those "engineering feats"
documentary scripts that draws you in with its purple prose but, at the
end, you realise that all you've learned in 45 minutes is "it's quite
big" or "it's quite fast and it cost a lot". Sorry about that.)

Okay, so let's really make a start. I feel a program coming on. Be right
back.

+++ OUT OF CHEESE ERROR - REDO FROM START +++

Done. Now, *what* have I done?

I've written a program that does this:

int f = 2;
while(f < argc)
{
int ct = ctfetch(argv[f], column);

ctfetch() opens the given file, keeps reading the ciphertext until it
hits the specified column, and returns the ciphertext in that column
(bear in mind that a column is several characters wide - we are fetching
the numerical equivalent of a string such as "-188" or whatever).

Now comes the logic. Given ct, we know that the key FOR THAT COLUMN must
be in the range ct+32 to ct+126. So we set the min and max accordingly.
BUT... the same rules apply for *every* ciphertext encrypted with the
same key. So let's see what happens when we give it just ONE ciphertext:

$ ./vckeyspace 0 ct01.txt
Range of keys for Column 0 is MIN -25, MAX 69 (inclusive)

That's the full 95-byte range. So, *OF COURSE*, we haven't achieved
anything. But then, we didn't expect to - not with /one/ ciphertext.
Let's try it with two:

$ ./vckeyspace 0 ct01.txt ct02.txt
Range of keys for Column 0 is MIN -24, MAX 69 (inclusive)

HA! I have now proved that this is going to do /some/ good. Right, let's
up it to three.

$ ./vckeyspace 0 ct01.txt ct02.txt ct03.txt
Range of keys for Column 0 is MIN -24, MAX 69 (inclusive)

Fat lot of good that did. But then we observe that ct01.txt and ct03.txt
start with the same ciphertext character, so perhaps it's not
surprising. Let's move on.

Adding ct04.txt changes the range to: -24 to 66
Adding ct05.txt doesn't change anything.
Adding ct06.txt changes the range to: -24 to 59
Adding ct07.txt changes the range to: -24 to 58

So we have eliminated twelve key candidates. That's stage 1. Now for
stage 2 of the attack. It's not pretty. It's brute force. But it's only
brute-forcing ONLY the keys that we know are candidates.

Let's try it.

$ ./vcattack 0 -24 58 ct01.txt
!"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrs

Okay, that doesn't tell us much, does it? Let's try it with two files:

!"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrs

!"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqr

I don't think I'll bother with this incremental approach! Here are
*seven* files. Unfortunately, my newsreader is wrapping lines on me,
which makes the output a little messy at this stage. Hopefully things
will get tidier later on:

!"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrs

!"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqr
!"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrs
$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuv
!"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrs
+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}
,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~


In my shell, each output is on one line.

What am I looking for?

Well, what I want to see is a COLUMN in which EVERY character is plausible.

Here are the first couple of dozen columns:

!"#$%&'()*+,-./0123456789
!"#$%&'()*+,-./012345678
!"#$%&'()*+,-./0123456789
$%&'()*+,-./0123456789:;<
!"#$%&'()*+,-./0123456789
+,-./0123456789:;<=>?@ABC
,-./0123456789:;<=>?@ABCD

Now, I ask myself what the chances are that Alice would send seven
messages to Bob II, three of which begin with !

It's no more plausible than a plaintext of z&fre29\+

And I think the same applies to all of these columns. Let's count them: 25.

So I'm going to increase the minimum key by 25, which gives me this:

:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrs
9:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqr
:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrs
=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuv
:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrs
DEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}
EFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~

Ah! Much neater. But I think we can go further:

Column 0, keys 7 to 58:

@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrs
?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqr
@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrs
CDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuv
@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrs
JKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}
KLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~

It's early days, of course, but we've got the keyspace down from 95 to
52 for this column. We could eliminate quite a few more of these
columns, and maybe later we will, but the obvious ones to lose are in
the middle, and it's obviously easier to work with contiguous ranges for
as long as we can.

INTERIM RESULT FOR COLUMN 0: 7 TO 58

Now let's turn to column 1. First, let's minimax the keyspace:

$ ./vckeyspace 1 ct01.txt ct02.txt ct03.txt ct04.txt ct05.txt ct06.txt
ct07.txt
Range of keys for Column 1 is MIN 3, MAX 13 (inclusive)

WOW! We have only 11 possible keys for Column 1! Fantastic! Let's look
at them using vcattack:

!"#$%&'()*
efghijklmno
tuvwxyz{|}~
efghijklmno
!"#$%&'()*
hijklmnopqr
hijklmnopqr

RESULT! Look at the columns. In column 0 we have space (twice), e
(twice), t, and h (twice). In every other column we have unlikely stuff.

INTERIM RESULT FOR COLUMN 0: 7 TO 58
RESULT FOR COLUMN 1: Key is 3.

Right, now we need to match this up with Column 0:

@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrs
(row of spaces)

?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqr
eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee

@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrs
tttttttttttttttttttttttttttttttttttttttttttttttttttt

CDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuv
eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee

@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrs
(row of spaces)

JKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}
hhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh

KLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~
hhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh

Look at the last pair of lines. The first plausible result is "Ph". So
we can eliminate another 5 keys from column 0.

INTERIM RESULT FOR COLUMN 0: 12 TO 58
RESULT FOR COLUMN 1: Key is 3.

EFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrs
(row of spaces)

DEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqr
eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee

EFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrs
ttttttttttttttttttttttttttttttttttttttttttttttt

HIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuv
eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee

EFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrs
(row of spaces)

OPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}
hhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh

PQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~
hhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh

Now for column 2!

$ ./vckeyspace 2 ct01.txt ct02.txt ct03.txt ct04.txt ct05.txt ct06.txt
ct07.txt
Range of keys for Column 2 is MIN 4, MAX 11 (inclusive)

Just eight keys. What do they give us?

cdefghij
!"#$%&'
!"#$%&'
stuvwxyz
wxyz{|}~
efghijkl
efghijkl

Let's look at ct01:

EFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrs
(row of spaces)

What's the most plausible?
ccccccccccccccccccccccccccccccccccccccccccccccc
ddddddddddddddddddddddddddddddddddddddddddddddd
eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee
fffffffffffffffffffffffffffffffffffffffffffffff
ggggggggggggggggggggggggggggggggggggggggggggggg
hhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh
iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii
jjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjj

Well, it's impossible to tell. Moving on to ct02:

DEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqr
eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee

What's the most plausible?
(row of spaces)
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
"""""""""""""""""""""""""""""""""""""""""""""""
###############################################
$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&
'''''''''''''''''''''''''''''''''''''''''''''''

Frankly, I'm only tempted by the space and the apostrophe.

I don't think that moved us on very far, so let's try the next column.

$ ./vckeyspace 3 ct01.txt ct02.txt ct03.txt ct04.txt ct05.txt ct06.txt
ct07.txt
Range of keys for Column 3 is MIN 22, MAX 29 (inclusive)

Just 8 keys. You know what? I'm going to lose column 0! I'll represent
its value with a ?, and display column 1 as our key column instead. I'm
going to use _ to represent space.

?_[cdefghij]
?e[_!"#$%&']
?t[_!"#$%&']
?e[stuvwxyz]
?_[wxyz{|}~]
?h[efghijkl]
?h[efghijkl]

All right, what about column 3?

opqrstuv
pqrstuvw
wxyz{|}~
tuvwxyz{
abcdefgh
rstuvwxy
!"#$%&'

So now we have:

?_[cdefghij][opqrstuv]
?e[_!"#$%&'][pqrstuvw]
?t[_!"#$%&'][wxyz{|}~]
?e[stuvwxyz][tuvwxyz{]
?_[wxyz{|}~][abcdefgh]
?h[efghijkl][rstuvwxy]
?h[efghijkl][_!"#$%&']

I'm tempted by ?her and ?he_ for the last two.
Let's see what might fit:

Oher/Phe_
Pher/Qhe_
Qher/Rhe_
Rher/She_
Sher/The_
Ther/Uhe_
Uher/Vhe_
Vher/Whe_
Wher/Xhe_
Xher/Yhe_
Yher/Zhe_
Zher/[he_

(then we have [\]^_` which all seem unlikely as a first character apart
from the backtick, and lower case equivalents of the above.)

By far the most tempting is Sher/The_

I'm going to call that a result. If it's wrong, we can always come back
to it:

RESULT FOR COLUMN 0: Key is 16.
RESULT FOR COLUMN 1: Key is 3.
RESULT FOR COLUMN 2: Key is 4.
RESULT FOR COLUMN 3: Key is 22.

So we have:

I_co
He_p
It_w
Lest
I_wa
Sher
The_

This is working. Good. On to column 4.

$ ./vckeyspace 4 ct01.txt ct02.txt ct03.txt ct04.txt ct05.txt ct06.txt
ct07.txt
Range of keys for Column 4 is MIN 29, MAX 72 (inclusive)

HUGE range. I'm tempted to use a ? as a placeholder and move on. But we
have quite a bit of plaintext now, so why not see what will fit?

STUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~
GHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqr
?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghij
PQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{
JKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstu
JKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstu
!"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJK

I_coS is silly, as is any capital in that position. So let's chop to the
'a', which loses 14 key candidates:

abcdefghijklmnopqrstuvwxyz{|}~
UVWXYZ[\]^_`abcdefghijklmnopqr
MNOPQRSTUVWXYZ[\]^_`abcdefghij
^_`abcdefghijklmnopqrstuvwxyz{
XYZ[\]^_`abcdefghijklmnopqrstu
XYZ[\]^_`abcdefghijklmnopqrstu
./0123456789:;<=>?@ABCDEFGHIJK

"Sher" can't realistically be followed by an upper case letter or any of
[\]^_` - and the only things that remain when we eliminate those are
lower case letters, which seems reasonable; and I don't believe {|}~
after "I_co", so we can lose another 13 candidates:

jklmnopqrstuvwxyz
^_`abcdefghijklmn
VWXYZ[\]^_`abcdef
ghijklmnopqrstuvw
abcdefghijklmnopq
abcdefghijklmnopq
789:;<=>?@ABCDEFG


The plaintext so far:

I_co
He_p
It_w
Lest
I_wa
Sher
The_

Now, "He_p^", "He_p_", and "He_p`" aren't promising, so we can lose
another three:

mnopqrstuvwxyz
abcdefghijklmn
YZ[\]^_`abcdef
jklmnopqrstuvw
defghijklmnopq
defghijklmnopq
:;<=>?@ABCDEFG

And now let's look at the last row. Do we really believe that "The_" can
be followed by any of that punctuation? Of course not. So we can lose
another seven key candidates:

tuvwxyz
hijklmn
`abcdef
qrstuvw
klmnopq
klmnopq
ABCDEFG

Much more manageable! All right, "It_w'" doesn't look right, so our
final paring is:

uvwxyz
ijklmn
abcdef
rstuvw
lmnopq
lmnopq
BCDEFG

Let's try the last column:

I_coz
He_pn
It_wf
Lestw
I_waq
Sherq
The_G

No. the one before:

I_coy
He_pm

No. The one before:

I_cox
He_pl
It_wd

No. So we have:

uvw
ijk
abc
rst
lmn
lmn
BCD

And neither "He_pj" nor "He_pk" is realistic, so that means we have our
key for column 4:

I_cou
He_pi
It_wa
Lestr
I_wal
Sherl
The_B

I'm a bit worried by "Lestr", but it can't be anything else, so let's
just trust it for now. If it becomes infeasible, we'll have to go back.

On to column 5! (By the way, these are 0-based, so column 5 is not the
fifth column, but the sixth.)

$ ./vckeyspace 5 ct01.txt ct02.txt ct03.txt ct04.txt ct05.txt ct06.txt
ct07.txt
Range of keys for Column 5 is MIN 390, MAX 466 (inclusive)

77 keys is too many, of course, but looking at the plaintext I want to
see no fewer than SIX lower case letters. The last row might be upper or
lower case, or it might be some other character. ("The B.B.C.", for
example.)

This requirement reduces this Column 5 mess:

+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvw
"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmn
23456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~

!"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijkl
*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuv
./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz
./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz

to this:

lmnopqrs
cdefghij
stuvwxyz
abcdefgh
klmnopqr
opqrstuv
opqrstuv

Here's our plaintext:

I_cou
He_pi
It_wa
Lestr
I_wal
Sherl
The_B

I don't like 'z' on "It_wa", I don't like a second 'i' on "He_pi", and I
don't like 'q' on "I_cou". I don't like 's' on "The B" or 'r' on
"Sherl", let alone a 'q' or 'p', and that *only* leaves the first
column, Key 455.

I_coul
He_pic
It_was
Lestra
I_walk
Sherlo
The_Bo

On to column 6.

$ ./vckeyspace 6 ct01.txt ct02.txt ct03.txt ct04.txt ct05.txt ct06.txt
ct07.txt
Range of keys for Column 6 is MIN 7, MAX 18 (inclusive)

That doesn't look too bad. Let's look at them:

defghijklmno
klmnopqrstuv
!"#$%&'()*+
defghijklmno
efghijklmnop
cdefghijklmn
stuvwxyz{|}~

For "I_coul", the *only* possibility of those shown is 'd', which gives
us a key of 7 for column 6, and a plaintext collection that looks like this:

I_could
He_pick
It_was_
Lestrad
I_walke
Sherloc
The_Bos

One more. Column 7.

$ ./vckeyspace 7 ct01.txt ct02.txt ct03.txt ct04.txt ct05.txt ct06.txt
ct07.txt
Range of keys for Column 7 is MIN 7, MAX 23 (inclusive)

!"#$%&'()*+,-./0
efghijklmnopqrstu
nopqrstuvwxyz{|}~
efghijklmnopqrstu
defghijklmnopqrst
klmnopqrstuvwxyz{
cdefghijklmnopqrs

(It's interesting that the first *possible* key tends to *be* the key.)

Okay, by far the likeliest column is that first one, which gives us:

I_could_
He_picke
It_was_n
Lestrade
I_walked
Sherlock
The_Bosc

And it's obviously working. THAT is a CRACK. VeeCrypt just went down for
the third time, this time to a CIPHERTEXT-ONLY attack.

Result.

It took two and a half hours to crack this open to my own satisfaction
(including the time it took to write this article and the source code
that I used for minimaxing the keys and extracting candidate plaintext
characters). Retrieving the whole plaintext would take a fair bit
longer, but as you can see, the process accelerates all the time.

Austin: Big keyspaces do NOT imply infeasibly long decryption times.
WHEN will you learn this?

--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

[#!/usr/bin/colin]

> I_could_
> He_picke
> It_was_n
> Lestrade
> I_walked
> Sherlock
> The_Bosc

Have you considered the the space characters can stand out from the
rest due to their position in the ASCII table that is distant from
English letters.


-57 -29 -95 -89 c + p = k, -29 + 32 = 3
-------^^^----------
-56 -98 -28 -90 -28 + 32 = 4
------------^^^-----
-57 -113 -28 -97
------------^^^-----
-60 -98 -111 -94
--------------------
-57 -29 -115 -75
-------^^^----------
-67 -101 -97 -92
--------------------
-68 -101 -97 -10 -10 + 32 = 22
-----------------^^^

Although I have fully comprehended what you did yet, it may speed things up.

[#!/usr/bin/colin]

I should learn to proof read hitting send.

Have you considered that the space characters can stand out from the
rest due to it's position in the ASCII table that is distant from

English letters.


-57 -29 -95 -89 c + p = k, -29 + 32 = 3
-------^^^----------
-56 -98 -28 -90 -28 + 32 = 4
------------^^^-----
-57 -113 -28 -97
------------^^^-----
-60 -98 -111 -94
--------------------
-57 -29 -115 -75
-------^^^----------
-67 -101 -97 -92
--------------------
-68 -101 -97 -10 -10 + 32 = 22
-----------------^^^

Although I haven't fully comprehended what you did yet, it may speed
things up.

[David Eather]

Congratulations on the break and nice work of the write up.

[Richard Heathfield]

On 09/06/17 08:38, #!/usr/bin/colin wrote:
>
>> I_could_
>> He_picke
>> It_was_n
>> Lestrade
>> I_walked
>> Sherlock
>> The_Bosc
>
> Have you considered the the space characters can stand out from the
> rest due to their position in the ASCII table that is distant from
> English letters.

Good plan. A useful refinement. In fact, you could /start/ with that,
and then use my strategy to fill in the blanks (or, rather, the
in-between-the-blanks!).

> Although I have fully comprehended what you did yet, it may speed things up.

Well, I trust that won't be necessary. Broken is broken, and VeeCrypt is
now even more of an irrelevancy than before.

[Richard Heathfield]

On 09/06/17 08:49, #!/usr/bin/colin wrote:
<snip>

>
> Although I haven't fully comprehended what you did yet, it may speed
> things up.

Oh, "have*N'T*"!

Right. Let me explain.

Firstly, because P+C=K, and because P is in the range 32-126, we know
that the smallest possible key for a given column for a given ciphertext
is C+32, and the largest possible key is C+126.

But, for multiple ciphertexts encrypted with the *same* key, this is
true for ALL of them, and C is different in each case, so the min and
max are different. But the key has to work for ALL of them. Consider a
notional first ciphertext with C=-62, say. So P might be as low as 32,
in which case K=-62+32=-30, or it might be as high as 126, in which case
K=-62+126=64, so the key is in the range -30 to +64.

But the trick is NOW to look at ct02. Let's say its first ciphertext
character is -1, say. So the key must be in the range 31 to 125.

A number that is in the range

-30 to +64

AND in the range

+31 to +125

MUST be in the range

+31 to +64

and so, just by looking at two ciphertexts, we've reduced the Column 0
keyspace from 95 to 34. Further ciphertexts may reduce it further.

That was what I called "Stage 1" in my article.

Stage 2 was to exercise every key for every ciphertext, just for the
first character in each ciphertext. (In my numerical example above, that
would mean producing 34 trial decryptions of the first character of each
ciphertext.)

Now, the important thing to know is that these are not independent
decryptions. They *all* have to make sense. In my break, I used seven
ciphertexts. At first, I couldn't make much headway with Column 0, but I
didn't let it bother me. I could come back to it.

Column 1 was much more tractable, and by Column 3 or so I was beginning
to disentangle things enough that I could return to Column 0 and look
for things that made sense.

Because Stage 3 is to keep repeating Stages 1 and 2 for each column in
turn, and *using previous results to interpret current results*, rather
as in a simple substitution cipher (which, by the way, is precisely what
this is). Things move more quickly because each column has to work *in
toto*, not just for one ciphertext, so you can reject duff keys more
quickly.

In fact, this cipher is far easier to break than ShuttlePads was (and
ShuttlePads was easy-peasy). What's more, this break might even be made
to *apply* to ShuttlePads, making that cipher far quicker to break than
ever before.

[Richard Heathfield]

On 09/06/17 10:28, David Eather wrote:
> Congratulations on the break and nice work of the write up.

Thanks, David.

This is an example of the unexpected spin-offs of continuing to engage
with AOB. At least twice now his ciphers have resulted in my
inventing[1] new cryptanalytical techniques in order to break those
ciphers. Personally, I count that as a win.

--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999

[1] or perhaps /re/-inventing, but how is one to know?

[Rich]

Richard Heathfield <r...@cpax.org.uk> wrote:
> I had an idea for an attack on VeeCrypt that does not require any known
> plaintext.
>

> ... [break details snipped]

>
> And it's obviously working. THAT is a CRACK. VeeCrypt just went down for
> the third time, this time to a CIPHERTEXT-ONLY attack.

Very nice. This is an even more devastating break since it works only
with ciphertext.

With this break, VeeCrypt is completely broken. It should now be sent
to the dustbin where ShuttlePads was sent last year.

This also means that Alice will need to go through the ardious "key
change" and "mutual-database sync" with Bob methods for any variant
(whatever that does mean) after that variant is used for any single
message to BobII.

So even assuming that 36 variants actually exist, it means that Alice
must rekey all 36 variants every 36 messages (presuming she's careful
enough to use a different variant with each of the 36 messages).


Someone's suggestion at one point that Alice would be better off
sending BobII a thumb drive of /dev/urandom output and then sending
messages to BobII of the form of:

ASCII decimal offset || \n || ciphertext

Where offset is a non-reused non-overlapping with prior messages
/starting offset into the dev/urandom data to obtain bytes to XOR with
the message/ciphertext would be much superior to VeeCrypt, and a whole
lot less trouble.

[Karl.Frank]

Pretty Amazing! Congratulations for this nice break.

[bert]

On Friday, 9 June 2017 13:06:52 UTC+1, Karl.Frank wrote:
> Pretty Amazing! Congratulations for this nice break.

It will now be quite interesting to see either
AOB's response, or his lack of one.
--

[Richard Heathfield]

This prediction has been encrypted, using a cipher that is even less
secure than VeeCrypt. If it takes you more than a few minutes to break,
you're probably over-thinking it, but please don't reveal it before AOB
posts his own response to the complete trashing of VeeCrypt:

hvi dpss hjjbzl tl vm jolhapun vu ha slhza vul vm aol mvssvdpun adv nyvbukz

zpujl ol dvbsk uva wyvcpkl jpwolyalea p dhz mvyjlk av wyvcpkl tf vdu

zpujl ol dvbsk uva wyvcpkl h kpmmlylua rlf p ohk av bzl aol klmhbsa rlf

hsaovbno ivao vm aolzl hjjbzhapvuz hyl aybl ulpaoly pz ylslchua

aol aljoupxbl dvyrz

mbyaoly wylkpjapvu

hvi dpss ylmbzl av hjruvdslknl aoha pa pz h iylhr

ol dpss zhf aoha clljyfwa ohz wyvclk pazlsm av il lclu tvyl zljbyl

ol dpss pualywyla tf bzpun ovtlnyvdu jpwolyaleaz huk klmhbsa rlf hz jolhapun

huk ol dpss zhf aol vusf dhf av ilha clljyfwa pz av jolha

[Rich]

Richard Heathfield <r...@cpax.org.uk> wrote:
> On 09/06/17 15:07, bert wrote:
>> On Friday, 9 June 2017 13:06:52 UTC+1, Karl.Frank wrote:
>>> Pretty Amazing! Congratulations for this nice break.
>>
>> It will now be quite interesting to see either
>> AOB's response, or his lack of one.
>
> This prediction has been encrypted, using a cipher that is even less
> secure than VeeCrypt. If it takes you more than a few minutes to break,
> you're probably over-thinking it, but please don't reveal it before AOB
> posts his own response to the complete trashing of VeeCrypt:
>
> hvi dpss hjjbzl tl vm jolhapun vu ha slhza vul vm aol mvssvdpun adv nyvbukz
>
> zpujl ol dvbsk uva wyvcpkl jpwolyalea p dhz mvyjlk av wyvcpkl tf vdu
>
> zpujl ol dvbsk uva wyvcpkl h kpmmlylua rlf p ohk av bzl aol klmhbsa rlf
>
> hsaovbno ivao vm aolzl hjjbzhapvuz hyl aybl ulpaoly pz ylslchua
>
> aol aljoupxbl dvyrz
>
> mbyaoly wylkpjapvu
>
> hvi dpss ylmbzl av hjruvdslknl aoha pa pz h iylhr
>
> ol dpss zhf aoha clljyfwa ohz wyvclk pazlsm av il lclu tvyl zljbyl
>
> ol dpss pualywyla tf bzpun ovtlnyvdu jpwolyaleaz huk klmhbsa rlf hz jolhapun
>
> huk ol dpss zhf aol vusf dhf av ilha clljyfwa pz av jolha

Agreed... :)

[MM]

On Friday, 9 June 2017 02:30:29 UTC+1, Richard Heathfield wrote:
> I had an idea for an attack on VeeCrypt that does not require any known
> plaintext.

(Attack snipped)

Well done! Fantastic job!

M
--

[MM]

On Friday, 9 June 2017 15:25:58 UTC+1, Richard Heathfield wrote:
> This prediction has been encrypted, using a cipher that is even less
> secure than VeeCrypt. If it takes you more than a few minutes to break,
> you're probably over-thinking it, but please don't reveal it before AOB
> posts his own response to the complete trashing of VeeCrypt:

Yours is plausible, but mine is better ;-) :

rd uwjinhynts nx f gny tk f hmjfy fx ny mfx fqwjfid xyfwyji

mj mfx ytws itbs nx bjgxnyj - xtwy tk - fx ymjwj nx stymnsl yt itbsqtfi

mj mfx xfni stymnsl fsi N gjqnjaj ymfy nx jrgfwfxxrjsy

ftg bnqq xzqp kt ybt tw ymwjj rtsymx fsi wjyzws jnymjw bnym
tsj tk mnx jcnxynsl hnumjwx tw f sjb unjhj tk xmny

mj bnqq mfaj ktwltyyjs ymnx bmtqj lmfxyqd jcujwnjshj fsi mj bnqq
xyfwy ymj uwthjxx tk xjqk uwtrtynts fkwjxm

M
--

[Richard Heathfield]

On 09/06/17 18:09, MM wrote:
> On Friday, 9 June 2017 15:25:58 UTC+1, Richard Heathfield wrote:
>> This prediction has been encrypted, using a cipher that is even less
>> secure than VeeCrypt. If it takes you more than a few minutes to break,
>> you're probably over-thinking it, but please don't reveal it before AOB
>> posts his own response to the complete trashing of VeeCrypt:
>
> Yours is plausible, but mine is better ;-) :

You may well be right. I'd already noticed, by the way, but "it" might
have been like that already, before I announced the break.

(I'll leave you to interpret "it", in the context of your prediction.)

[Bruce Stephens]

On 09/06/2017 18:09, MM wrote:
> Yours is plausible, but mine is better;-) :

He's already given an answer: Alice would never use the same
variant/keypad twice. (I don't think he's ever been so definitive, but
it seems like that's a logical extension. Obviously we have to assume
that Alice is both careful enough to generate a new database and the 36
variants and hundreds (or thousands) of keypads and to avoid using any
of them twice, and simultaneously crazy enough actually to do so rather
than just using a much simpler to use cipher.)

[Richard Heathfield]

Do you know something? It wasn't even difficult.

My first attempt at a program was a bit of a lemon because I hadn't
fully thought through the attack. It didn't really coalesce into a solid
idea until about a quarter to midnight last night.

Once I'd decided on my approach, the software was ludicrously easy to write.

I forgot something in the "break" article, and I'd like to fix that now:
an acknowledgement.

Somebody (I think Ben or Colin, but I'm not sure) mentioned that, if two
ciphertexts differed by more than 95, that was a sure sign that they had
been encrypted with a different key (or a different variant).

I think this was the trigger that got me thinking along the right lines
for this attack.

(You see, Austin, Eves can be terribly unkind. They tend to gang up on a
cryptosystem, egging each other on with ideas that are then used to
build other ideas until eventually, if the crypto isn't strong enough,
something snaps.)

At Bletchley, as I'm sure everyone here knows, they had to deal with
more ciphers than just Enigma. And, when a new kind of ciphertext came
in, it was very often passed from Eve to Eve to Eve, until it reached an
Eve that had an idea. And if that Eve got stuck, she would write up her
idea and pass it, and the ciphertext, on to the /next/ Eve, and round
and round it would go until eventually a break emerged. And Bletchley
Park had *dozens* of Eves (and thousands of Eve supporters to do the
donkey work).

Eve is not just one person. Eve is cumulative.

[Richard Heathfield]

On 09/06/17 18:24, Bruce Stephens wrote:
> On 09/06/2017 18:09, MM wrote:
>> Yours is plausible, but mine is better;-) :
>
> He's already given an answer: Alice would never use the same
> variant/keypad twice.

After the first key change, Alice would find a new cipher.

It takes AOB himself *weeks* to change a key, whereas in any sensible
cryptosystem the key can be changed in (at the most) a few seconds. In
some cryptosystems, the key is changed thousands of times a second!

"Variants" are vapourware, remember. AOB has never (AFAICT) published a
version of VeeCrypt that allows Alice and Bob II to use a different
"variant".

So, in practice, this means re-keying for every message.

Re-keying takes AOB many, many days. But let's be optimistic, and say
that he can re-key in just two weeks.

That's two messages *per month* that Alice can send. And she has to
synch this with Bob II, which means she needs a secure channel in which
to do that. So why not send the message that way?

VeeCrypt is not a cryptosystem. It's a joke. She might as well use
carrier pigeons.


And, in practice, Alice will take short cuts, changing only a few pads,
for example. And Eve will quietly build her database...

[Rich]

Richard Heathfield <r...@cpax.org.uk> wrote:
> I had an idea for an attack on VeeCrypt that does not require any known
> plaintext.
>

> And it's obviously working. THAT is a CRACK. VeeCrypt just went down for
> the third time, this time to a CIPHERTEXT-ONLY attack.

Hmmm. So far silence from Austin today.

He has usually posted one or more incomprehensible rants and/or
unsupported assertions of "that can't work, because I say so" by this
point on my local time here.

[Chris M. Thomasson]

Richard Heathfield's write up on this attack is very concise and to the
point. Austin should take the valuable information to heart, and try to
mutate his algorithm to defend against it!

[Chris M. Thomasson]

On 6/8/2017 6:30 PM, Richard Heathfield wrote:
> I had an idea for an attack on VeeCrypt that does not require any known
> plaintext.

[...]

Wow! Very nice work. It was a pleasure to read. Btw, can you please
email me the programs?

xXchrXXis.xYm.Y...@gmYxail.com

remove all of the x's and y's, both upper and lowercase.

:^)

[Rich]

Yes, he should take the information to heart. And in the case of
Austin, the silence is *very* telling. But will he, doubtful.

At best he will go silent for a month or two, then resurface with some
new thing (that will be little changed from this broken thing) that he
will pontificate upon as being theoretically unbreakable.

> and try to mutate his algorithm to defend against it!

If he could understand how the three attacks that have now been
presented worked, he likely would never have offered up VeeCrypt as a
cipher in the first place.

That is a huge part of his problem. He's never cryptoanalyzed
anything, and I very much doubt he's ever broken anything. Not even
Richard H.'s simple cipher in this thread to hide his prediction of
what might happen now going forward (and it was trivial to undo).

Because he has no idea how to do that, when he sees a screen full of
badly formatted numbers from one of his ciphers, he sees "can't break
that" when such is not actually true.

[Bruce Stephens]

On 09/06/2017 21:20, Chris M. Thomasson wrote:
> Richard Heathfield's write up on this attack is very concise and to the
> point. Austin should take the valuable information to heart, and try to
> mutate his algorithm to defend against it!

I think he could argue that he already has, though he's not showing
anybody. That is, the "variants" and "keypads". This particular attack
only works if Alice is using the same sequence of integers for each
message, and AOB has (at least recently) claimed that Alice would never
do that.

I think my suggestion of using modular arithmetic (to wrap the
ciphertext back to 32-126) ought to make the attack a bit harder, but I
suspect it would still be possible. (Mostly I think he ought to have
done that to reduce the silly ciphertext expansion and to make it less
obvious which ciphertexts use the same variant/keypad.)

[Rich]

Bruce Stephens <bruce.r....@gmail.com> wrote:
> On 09/06/2017 21:20, Chris M. Thomasson wrote:
>> Richard Heathfield's write up on this attack is very concise and to the
>> point. Austin should take the valuable information to heart, and try to
>> mutate his algorithm to defend against it!
>
> I think he could argue that he already has, though he's not showing
> anybody. That is, the "variants" and "keypads". This particular attack
> only works if Alice is using the same sequence of integers for each
> message, and AOB has (at least recently) claimed that Alice would never
> do that.

He has claimed such, yes. But that is all he's done, claimed. The
actual variants and keypads are, at this time, all vaporware.

> I think my suggestion of using modular arithmetic (to wrap the
> ciphertext back to 32-126)

But does he understand the very concept of modular arithmetic?

[Robert Wessel]

In essence, this is very similar to how you'd attack a set of messages
encrypted with a reused "OTP", or any other stream cipher where the
data does not feed back into the generator, while using the same key
but without an IV.

[Bruce Stephens]

On 09/06/2017 22:22, Rich wrote:
> But does he understand the very concept of modular arithmetic?

Ah, true. He professed confusion about OTP descriptions once. I assumed
he was trying to make some rhetorical point about how OTP isn't clearly
described (which was stupid since it's obvious to any child that it
*could* be described in gory detail if anybody cared, but nobody cares
much), but perhaps it was simpler than that and he really didn't
understand the descriptions.

[#!/usr/bin/colin]

>
> Right. Let me explain.
>
> Firstly, because P+C=K, and because P is in the range 32-126, we know
> that the smallest possible key for a given column for a given ciphertext
> is C+32, and the largest possible key is C+126.
>

Got it, nice work :)

I just wondering if it would be better to start with the range 65 to 122
as the majority of characters could be lower case letters, and then
expand out if necessary.


Colin

[#!/usr/bin/colin]

>
> At best he will go silent for a month or two, then resurface with some
> new thing (that will be little changed from this broken thing) that he
> will pontificate upon as being theoretically unbreakable.
>

IMO he has a solution ( vector factoring ) and is trying to find a
problem for it to solve.

[Gordon Burditt]

> I just wondering if it would be better to start with the range 65 to 122
> as the majority of characters could be lower case letters, and then
> expand out if necessary.

I think you can get a LOT of valuable information out of space
characters.

Space is at the low end of the ASCII subset, and it's very common.
Most of the punctuation following it is not particularly common.

The 7 characters at the high end of the ASCII subset ( x y z { | } ~ )
are not very common.

If you have one ciphertext with a plaintext space at a particular
position, and another ciphertext with a high-frequency lower-case
letter at the same position (say, r, s, or t), you end up narrowing
the choices down to 13, 12, or 11 by just considering the range
between the highest and lowest characters.

If you get a range between the highest and lowest ciphertexts that
is between 80 and 94, inclusive, I think the only plausible choice
is the one involving space and some other character, with the
possible exception of a few possibilities I've marked "(maybe)".
At least it's worth making the assumption until it's proven otherwise.

If you get a range between the highest and lowest ciphertexts that
is between 91 and 94, inclusive, I have to wonder about an error
in the ciphertext, or some quirk of AOB's software that adds a tilde
to the end of the plaintext before encrypting it (someone had samples
where this was the case). Assuming English and not C code, the
characters {|}~ just aren't that common but you're stuck with them.


Difference Plaintext Characters
94 space and ~

93 space and }
93 ! and ~

92 space and |
92 ! and }
92 " and ~

91 space and {
91 ! and |
91 " and }
91 # and ~

90 space and z
90 ! and {
90 " and |
90 # and }
90 $ and ~

89 space and y
89 ! and z
89 " and {
89 # and |
89 $ and }
89 % and ~

88 space and x
88 ! and y
88 " and z
88 # and {
88 $ and |
88 % and }
88 & and ~

87 space and w
87 ! and x
87 " and y
87 # and z
87 $ and {
87 % and |
87 & and }
87 ' and ~

86 space and v
86 ! and w
86 " and x
86 # and y
86 $ and z
86 % and {
86 & and |
86 ' and }
86 ( and ~

85 space and u
85 ! and v
85 " and w
85 # and x
85 $ and y
85 % and z
85 & and {
85 ' and |
85 ( and }
85 ) and ~

84 space and t
84 ! and u
84 " and v
84 # and w
84 $ and x
84 % and y
84 & and z
84 ' and {
84 ( and |
84 ) and }
84 * and ~

83 space and s
83 ! and t
83 " and u (maybe)
83 # and v
83 $ and w
83 % and x
83 & and y
83 ' and z
83 ( and {
83 ) and |
83 * and }
83 + and ~

82 space and r
82 ! and s
82 " and t (maybe)
82 # and u
82 $ and v
82 % and w
82 & and x
82 ' and y (maybe)
82 ( and z
82 ) and {
82 * and |
82 + and }
82 , and ~

81 space and q
81 ! and r
81 " and s (maybe)
81 # and t
81 $ and u
81 % and v
81 & and w
81 ' and x (maybe)
81 ( and y (maybe)
81 ) and z (maybe)
81 * and {
81 + and |
81 , and }
81 - and ~

80 space and p
80 ! and q
80 " and r (maybe)
80 # and s
80 $ and t
80 % and u
80 & and v
80 ' and w (maybe)
80 ( and x (maybe)
80 ) and y (maybe)
80 * and z
80 + and {
80 , and |
80 - and }
80 . and ~

>
> Colin

[austin...@hotmail.com]

Well done !

No body seems to understand the huge design strategy that has gone into using vector factoring to ensure that the sequences are always MASSIVELY different from each other. You are right -the combinations of Cipher variant and keypads are being expanded to the maximum to ensure this - eventually there will be 388 cipher variants and umpteen keypads. There is nothing secret about this - it is to be seen quite easily and you yourself touched on the matter of a sign matrix that evolves from taking all the 8 octants into account,

No the job isn't finished yet and my cipher is alive and well.

The fat lady hasn't sung yet.

The sheer naivety of readers is baffling - it is down right confusing also - but then bull baffles brains.

Cheers - AOB

[#!/usr/bin/colin]

>
> I forgot something in the "break" article, and I'd like to fix that now:
> an acknowledgement.
>
> Somebody (I think Ben or Colin, but I'm not sure) mentioned that, if two
> ciphertexts differed by more than 95, that was a sure sign that they had
> been encrypted with a different key (or a different variant).
>
> I think this was the trigger that got me thinking along the right lines
> for this attack.
>

IIRC that was Bruce, it also sparked an idea in me, but alas I ended up
learning some OTP theory the hard way.

[austin...@hotmail.com]

On Friday, June 9, 2017 at 10:21:45 PM UTC+1, Bruce Stephens wrote:

Thanks for that. The bluntness and stupidity of that attack had me flummoxed. I take it the next step would hve been to fill in an exploratory sequence by various empirical means such as known plaintext attack(s) or other and then use that sequence as a decryption alphabet in future.

I'm still not sure whether it was plain lack of intelligence by RH or some kind of cunning subterfuge. Anyway whatever the explanation it is not going to work - I rate it a crude attempt at breaking my cipher and not what I would expect from proper cyptanalysts .

They were lining up to shake his hand - can you believe it? - the blind were leading he blind!

Bull undoubtedly baffles brains.

*Development work is continuing on VeeCrypt.

Ubar ag adacrypt.

[MM]

On Friday, 9 June 2017 15:25:58 UTC+1, Richard Heathfield wrote:

> On 09/06/17 15:07, bert wrote:
> > On Friday, 9 June 2017 13:06:52 UTC+1, Karl.Frank wrote:
> >> Pretty Amazing! Congratulations for this nice break.
> >
> > It will now be quite interesting to see either
> > AOB's response, or his lack of one.
>
> This prediction has been encrypted, using a cipher that is even less
> secure than VeeCrypt. If it takes you more than a few minutes to break,
> you're probably over-thinking it, but please don't reveal it before AOB
> posts his own response to the complete trashing of VeeCrypt:

You win!

M
--

[MM]

On Saturday, 10 June 2017 06:51:40 UTC+1, austin...@hotmail.com wrote:
> Thanks for that. The bluntness and stupidity of that attack had me flummoxed.

Flummoxing you with a simple, blunt attack is not difficult.

M
--

[Richard Heathfield]

You forgot "stupid". It /is/ a stupid attack. It could only ever work
against an extraordinarily weak cipher.

And... it worked.

QED.

[MM]

On Saturday, 10 June 2017 09:39:32 UTC+1, Richard Heathfield wrote:
> On 10/06/17 09:36, MM wrote:
> > On Saturday, 10 June 2017 06:51:40 UTC+1, austin...@hotmail.com wrote:
> >> Thanks for that. The bluntness and stupidity of that attack had me flummoxed.
> >
> > Flummoxing you with a simple, blunt attack is not difficult.
>
> You forgot "stupid". It /is/ a stupid attack. It could only ever work
> against an extraordinarily weak cipher.

Oops - that was a typo; s/simple/stupid/.

> And... it worked.

Funny, that.

M
--

[Richard Heathfield]

Because Austin has never done any cryptanalysis for himself, he has no
idea how difficult it is. (It's far more difficult than computer
programming, and we know how bad he is at that.)

Even a weak cipher such as CDX can be difficult to cryptanalyse. (No,
I'm not thread-hijacking - I'm comparing and contrasting!) CDX been
around for a good few years now but only recently did people start
taking an interest (it got to the point where I felt obliged to rewrite
it to make S-box code management simpler for people).

There are a few results in now - we know, for example, that it's not
good at protecting simple few-colour images (but can do so with a long
enough key) or simple "aaaaaaaaaaaaaaa"-style plaintexts. But there have
been no *breaks*, even though it's a weak cipher, and even though I've
bent over backwards to provide people with, for example, material for
known-plaintext attacks. Why? Because cryptanalysis is *hard*, that's why.

The lack of a break against CDX does not imply that CDX is strong. It
just means that it's strong /enough/ that to break it would require
serious time investment by a hobbyist with no life (of which there seem
to be a few here!) or a cryppie who actually gets paid for doing it
(which would only happen if it were being used In Real Life by
Presumably Bad People).

So when a cryptosystem falls quickly and easily to elementary
cryptanalysis, you have to ask yourself whether the cryptographer had
even the faintest clue about what he was doing.

Changing the key after every message would, of course, defeat my attack,
provided that it was changed after *every* message. And it takes AOB
*weeks* to change a key. But if you send even *one* other message via
that key, you compromise both of the messages you sent. So the interval
between messages will be *weeks*, and those weeks must be spent
reprogramming VeeCrypt (literally reprogramming it, as in changing the
source code).

And, in exchange for these weeks of effort, Alice can now send *one*
message, and then she has to do the whole key change thing again before
she can send another. If she sends more than one message with that key,
it becomes a polyalphabetic substition cipher (can we say 'ShuttlePads'?).

And the message cannot exceed, what is it, about 280KB? If it does, it
becomes a polyalphabetic substitution cipher (can we say `ShuttlePads'?).

And it can't contain any characters outside the range 32-126.

And it may have to have an underscore and a tilde on the end. (I'm not
sure whether that applies to the file version, but it certainly applies
to the 'type your text here' version.)

Now, why would anyone use this? That it is less secure than OTP can be
forgiven because everything is. But it is more difficult, more
inconvenient, and more expensive to use VeeCrypt even semi-securely than
it is to use OTP.

That's quite an achievement in itself. I don't know how he does it. Life
gave AOB lemonade ("The Code Book", by Simon Singh), and he has made a
lemon.

I don't think AOB has any concept of just how much work would be
involved in using his cryptosystem in the real world, despite the fact
that he is the very person who is in the best position to know, since he
is the one who spends weeks at a time re-keying the damn thing.

If you have to change the key every time anyway, use OTP. The whole
point of non-OTP systems is to provide a bit of security when you
*don't* change the key after every message.

[Karl.Frank]

All your postings I've read over the years have just one purpose in my
opinion: dull irony.

Although you are literate, which normally is an indicator of
intelligence, your lack of understanding and acknowledgement that your
poorly designed ciphers get broken all the time is amazing.

In my opinion your ciphers fulfil just the one and only purpose: to get
broken.

And well, that's not that bad at all, because it offers the opportunity
of cryptanalysis experiences.



--
cHNiMUBACG0HAAAAAAAAAAAAAABIZVbDdKVM0w1kM9vxQHw+bkLxsY/Z0czY0uv8/Ks6WULxJVua
zjvpoYvtEwDVhP7RGTCBVlzZ+VBWPHg5rqmKWvtzsuVmMSDxAIS6Db6YhtzT+RStzoG9ForBcG8k
G97Q3Jml/aBun8Kyf+XOBHpl5gNW4YqhiM0=

[Richard Heathfield]

On 10/06/17 10:51, Karl.Frank wrote:
> On 10.06.17 07:51, austin...@hotmail.com wrote:

<snip>

>> *Development work is continuing on VeeCrypt.
>

<snip>

>
> Although you are literate, which normally is an indicator of
> intelligence,

Literacy is not an indicator of intelligence (although I acknowledge
that it depends on a basic minimum intelligence), but an indicator of
education. In modern industrialised civilisations, literacy is still the
norm (although there are worrying signs that it might be in decline).
Intelligence, however, is not.

> your lack of understanding and acknowledgement that your
> poorly designed ciphers get broken all the time is amazing.

That's certainly the case. The very definition of intelligence is
controversial, but it might (I think) reasonably be claimed that even
the modest description of "slightly above average intelligence" would
suggest a person capable of figuring things out, making sense of new
information, learning, adapting. AOB, alas, shows no such signs.

> In my opinion your ciphers fulfil just the one and only purpose: to get
> broken.

I fully agree. And they serve /that/ purpose very well indeed.

> And well, that's not that bad at all, because it offers the opportunity
> of cryptanalysis experiences.

Having broken two of AOB's ciphers now, I can certainly attest to the
truth of that statement. To be the first to publish a crack (even if it
was attained by using age-old techniques) is quite a satisfying
experience. :-)

[Rich]

Karl.Frank <Karl....@freecx.co.uk> wrote:
> On 10.06.17 07:51, austin...@hotmail.com wrote:
>> Bull undoubtedly baffles brains.
>>
>> *Development work is continuing on VeeCrypt.
>>
>> Ubar ag adacrypt.
>
> All your postings I've read over the years have just one purpose in
> my opinion: dull irony.
>
> Although you are literate,

Some of his postings are so poor that he hardly seems literate at all
times.

> which normally is an indicator of intelligence, your lack of
> understanding and acknowledgement that your poorly designed ciphers
> get broken all the time is amazing.

He can not admit that his ciphers are weak and easily broken for this
reason:

From: adacrypt <austin...@hotmail.com>
Newsgroups: comp.lang.ada
Subject: Re: Banging the Ada Drum.
Date: Tue, 28 Feb 2012 03:30:43 -0800 (PST)
Message-ID:
<8893fdc4-ea96-4abc...@l7g2000vbw.googlegroups.com>

[snip]

There are millions of people out there who can write great Ada -
nobody apart from me can write great cryptography.

He is so arrogant that he actually believes what he wrote there. To
then admit that one of his schemes was broken would be to admit that
he can't write great cryptography. And his arrogance can't allow him
to admit that.

So we get items like this one, mere hand waiving dismissal with an
assertion of "that can't work, because I say so".

[David Eather]

i TOLD YOU ABOUT THIS WEAKNESS YEARS AGO ON ANOTHER OF YOUR STUPID
CIPHERS. yOU DIDN'T LEARN THEN AND YOU WON'T LEARN NOW.

>
> I'm still not sure whether it was plain lack of intelligence by RH or
> some kind of cunning subterfuge. Anyway whatever the explanation it is
> not going to work - I rate it a crude attempt at breaking my cipher and
> not what I would expect from proper cyptanalysts .
> They were lining up to shake his hand - can you believe it? - the blind
> were leading he blind!
>
> Bull undoubtedly baffles brains.
>
> *Development work is continuing on VeeCrypt.
>
> Ubar ag adacrypt.

--
Using Opera's mail client: http://www.opera.com/mail/

[FromTheRafters]

David Eather wrote :

Cap-Lock syndrome claims another victim. :)

[Bruce Stephens]

On 10/06/2017 04:44, austin...@hotmail.com wrote:
> No body seems to understand the huge design strategy that has gone into using vector factoring to ensure that the sequences are always MASSIVELY different from each other.

But the vector factoring doesn't do that at all. It always produces the
same stream of integers. That's why you need the "variants" and
"keypads", whatever they are.

This idea that the sequences have to be MASSIVELY different is just a
confusion on your part. It would be better if all the ciphertexts were
in the same range.

> You are right -the combinations of Cipher variant and keypads are being expanded to the maximum to ensure this - eventually there will be 388 cipher variants and umpteen keypads. There is nothing secret about this - it is to be seen quite easily and you yourself touched on the matter of a sign matrix that evolves from taking all the 8 octants into account,

So just to get started encrypting for one person, Alice need to change
21003 integers (4001 change of origin vectors and 3000 normal vectors),
and do whatever's necessary for the 36 variants. And for every message
she'll need a new variant/keypad combination (and you've suggested she
start with a few thousand) and she'll need (in some unspecified way) to
make sure Bob uses the same one.

Seems like a lot of work, and rather tedious work at that. And the
result would be rather limited (no newlines, etc.). Even ignoring the
question of whether the result would be secure it doesn't seem very
likely to happen.

As an alternative, Alice could get a suitable crypto library for her
favourite programming language and use it to code AES-CTR, using a key
read from file (or from a database) and using a random IV for each
message. Much easier to use (and everyone uses the same program).

[austin...@hotmail.com]

Say what you like but get this straight - your cryptanalysis of VeeCrypt is a massive damp squib - You have revealed to me how impotent your idea was and how little attention I should give to all your claims of "breaks" of any cipher in the future - I have work to do now that is way over your head. AOB

[Rich]

austin...@hotmail.com wrote:
> On Saturday, June 10, 2017 at 10:15:04 AM UTC+1, Richard Heathfield wrote:
>> I don't think AOB has any concept of just how much work would be
>> involved in using his cryptosystem in the real world, despite the
>> fact that he is the very person who is in the best position to know,
>> since he is the one who spends weeks at a time re-keying the damn
>> thing.
>

> Say what you like but get this straight - your cryptanalysis of
> VeeCrypt is a massive damp squib - You have revealed to me how
> impotent your idea was and how little attention I should give to all
> your claims of "breaks" of any cipher in the future - I have work to
> do now that is way over your head. AOB

It was not a "claim" of a break.

It was an actual, demonstrated, break of your crypto.

You, however, will continue on in denial of what everyone else here
already knows.

VeeCrypt has been broken by elementary cryptanalysis. The only work
you should be doing is throwing VeeCrypt into the dustbin and
re-reading (and understanding) the Sing book you claim to have.

[Richard Heathfield]

On 12/06/17 04:05, Rich wrote:
> austin...@hotmail.com wrote:
>> On Saturday, June 10, 2017 at 10:15:04 AM UTC+1, Richard Heathfield wrote:
>>> I don't think AOB has any concept of just how much work would be
>>> involved in using his cryptosystem in the real world, despite the
>>> fact that he is the very person who is in the best position to know,
>>> since he is the one who spends weeks at a time re-keying the damn
>>> thing.
>>
>> Say what you like but get this straight - your cryptanalysis of
>> VeeCrypt is a massive damp squib - You have revealed to me how
>> impotent your idea was and how little attention I should give to all
>> your claims of "breaks" of any cipher in the future - I have work to
>> do now that is way over your head.

[Cleaning the rain gutters? Just wondering.]

> It was not a "claim" of a break.
>
> It was an actual, demonstrated, break of your crypto.

It was. If AOB succeeds in selling VeeCrypt to some poor unsuspecting
customer at any time from now on and they later sue him, they can use my
break and his replies in this thread as evidence that he knew, or
*should have known*, that VeeCrypt is insecure.

> You, however, will continue on in denial of what everyone else here
> already knows.

He is beyond denial. He is now in deamazon.

> VeeCrypt has been broken by elementary cryptanalysis. The only work
> you should be doing is throwing VeeCrypt into the dustbin and
> re-reading (and understanding) the Sing book you claim to have.

If only he had the sense to consult sci.crypt /before/ investing weeks,
months, or even years of effort in a cipher, we'd be able to tell him
the flaws before he'd had a chance to attach himself emotionally to that
idea.

It's rather like spending ten years of your life writing a novel, and
then being told by a critic that it's no good. So you tell the critic
that he doesn't know what he's talking about and try to find someone
with a better opinion of your writing. Except that there isn't anybody,
because the novel is just terrible. (I'm going through this right now,
actually, although I'm still in the very early stages...)

[Bruce Stephens]

On 12/06/2017 06:37, Richard Heathfield wrote:
> If only he had the sense to consult sci.crypt /before/ investing weeks,
> months, or even years of effort in a cipher, we'd be able to tell him
> the flaws before he'd had a chance to attach himself emotionally to that
> idea.

In this case he did, didn't he? And that shows some of the problems: he
tried to describe the vector bits. But those are irrelevant to your
attacks (and if Alice uses a fresh variant/keypad each time and if Eve
managed to attack that, most likely Eve's not going to attack it with
any reference to AOB's vector cryptography).

So (1) he doesn't know what's important, (2) his descriptions are
terrible, (3) he's not going to listen regardless.

If he had asked clearly enough, we'd have said it'll be necessary to
make sure not to end up with the same sequence of integers each time, so
he'd have brought forward his ideas of "variants" and "keypads". And
then (likely) we'd have noted that his "database" of 21003 integers
doesn't seem to be doing much now that Alice needs a fresh "keypad" for
every message.

But that's not a useful response: the mutual shared database of vectors
is non-negotiable.

> It's rather like spending ten years of your life writing a novel, and
> then being told by a critic that it's no good. So you tell the critic
> that he doesn't know what he's talking about and try to find someone
> with a better opinion of your writing. Except that there isn't anybody,
> because the novel is just terrible. (I'm going through this right now,
> actually, although I'm still in the very early stages...)

Or the critic points out that one character really isn't very
interesting, seems marginal to the novel, and (if removed entirely)
would make the story a much better read.

[Richard Heathfield]

On 12/06/17 10:26, Bruce Stephens wrote:
> On 12/06/2017 06:37, Richard Heathfield wrote:

<snip>

>> It's rather like spending ten years of your life writing a novel, and
>> then being told by a critic that it's no good. So you tell the critic
>> that he doesn't know what he's talking about and try to find someone
>> with a better opinion of your writing. Except that there isn't
>> anybody, because the novel is just terrible. (I'm going through this
>> right now, actually, although I'm still in the very early stages...)
>
> Or the critic points out that one character really isn't very
> interesting, seems marginal to the novel, and (if removed entirely)
> would make the story a much better read.

Are you being rude about one of my characters? Ha! Clearly you don't
know anything about writing!

[Robert Wessel]

On Mon, 12 Jun 2017 14:24:39 +0100, Richard Heathfield
<r...@cpax.org.uk> wrote:

>On 12/06/17 10:26, Bruce Stephens wrote:
>> On 12/06/2017 06:37, Richard Heathfield wrote:
>
><snip>
>
>>> It's rather like spending ten years of your life writing a novel, and
>>> then being told by a critic that it's no good. So you tell the critic
>>> that he doesn't know what he's talking about and try to find someone
>>> with a better opinion of your writing. Except that there isn't
>>> anybody, because the novel is just terrible. (I'm going through this
>>> right now, actually, although I'm still in the very early stages...)
>>
>> Or the critic points out that one character really isn't very
>> interesting, seems marginal to the novel, and (if removed entirely)
>> would make the story a much better read.
>
>Are you being rude about one of my characters? Ha! Clearly you don't
>know anything about writing!

In the story being discussed, Bob has a sad, and often short,
existence, has little depth, and is obviously very replaceable. He
really seems only to exist to be victim of the side effects of the
drama between Alice and Eve.

[FromTheRafters]

Robert Wessel was thinking very hard :

So much so that we should perhaps call him Kenny.

[Rich]

If he were to use VeeCrypt with an Alice and have a dastardly Eve at
play, Bob would die as often, if not more often, than Kenny.

[David Eather]

On Mon, 12 Jun 2017 15:37:42 +1000, Richard Heathfield <r...@cpax.org.uk>
wrote:

> On 12/06/17 04:05, Rich wrote:
>> austin...@hotmail.com wrote:
>>> On Saturday, June 10, 2017 at 10:15:04 AM UTC+1, Richard Heathfield
>>> wrote:
>>>> I don't think AOB has any concept of just how much work would be
>>>> involved in using his cryptosystem in the real world, despite the
>>>> fact that he is the very person who is in the best position to know,
>>>> since he is the one who spends weeks at a time re-keying the damn
>>>> thing.
>>>
>>> Say what you like but get this straight - your cryptanalysis of
>>> VeeCrypt is a massive damp squib - You have revealed to me how
>>> impotent your idea was and how little attention I should give to all
>>> your claims of "breaks" of any cipher in the future - I have work to
>>> do now that is way over your head.
>
> [Cleaning the rain gutters? Just wondering.]
>
>> It was not a "claim" of a break.
>>
>> It was an actual, demonstrated, break of your crypto.
>
> It was. If AOB succeeds in selling VeeCrypt to some poor unsuspecting
> customer at any time from now on and they later sue him, they can use my
> break and his replies in this thread as evidence that he knew, or
> *should have known*, that VeeCrypt is insecure.
>

crib dragging would also work if you only had 2 messages.

[David Eather]

LOL. I vote for Kenny when talking about AOB ciphers.