VeeCrypt Cipher - exploration and look at Scramble 'n Load Procedure results

[Rich]

A small experiment (on Linux).

First, grab the VeeCrypt zip that has been newly restored to Austin's
site:

$ wget https://www.adacrypt.co.uk/images/VeeCrypt_Cipher_XY13.zip

Unzip the zip file into /tmp:

$ unzip VeeCrypt_Cipher_XY13.zip -d /tmp/veecrypt_xy13/

and change working directory to the unzip location:

$ cd /tmp/veecrypt_xy13/

and first, we are greeted with a toplevel directory (containing spaces):

$ ls -al

drwxr-xr-x 3 noone noone 4096 Jun 3 18:00 ./
drwxrwxrwt 104 root root 61440 Jun 3 18:00 ../
drwxr-xr-x 4 noone noone 4096 Jun 3 18:00 VeeCrypt\ Cipher\ \ XY13/

so, cd into it now too:

$ cd VeeCrypt\ Cipher\ \ XY13

and what do we find?:

$ ls -al

drwxr-xr-x 4 noone noone 4096 Jun 3 18:00 ./
drwxr-xr-x 3 noone noone 4096 Jun 3 18:00 ../
-rw-r--r-- 1 noone noone 6148 May 16 10:40 .DS_Store
drwxr-xr-x 2 noone noone 4096 Jun 3 18:00 GNAT\ Ada\ 95\ Compiler/
drwxr-xr-x 2 noone noone 12288 Jun 3 18:00 Variant_X_Cipher/

The .DS_Store file identifies as an Apple Mac file:

$ file .DS_Store

.DS_Store: Apple Desktop Services Store

Which implies that either:
1) AOB is now working with a Mac, or
2) This mysterious "webmaster" to which he "posts" his files to upload
uses a Mac. I rather suspect this item to be the case.

The "GNAT Ada 95 Compiler" directory contains a set of Windows link files:

$ ls -al GNAT\ Ada\ 95\ Compiler/

drwxr-xr-x 2 noone noone 4096 Jun 3 18:00 ./
drwxr-xr-x 4 noone noone 4096 Jun 3 18:00 ../
-rwxrwxrwx 1 noone noone 651 Aug 14 2015 Ada\ GUI\ IDE.lnk*
-rwxrwxrwx 1 noone noone 634 Aug 14 2015 Ada95\ Reference\ Manual.lnk*
-rwxrwxrwx 1 noone noone 702 Aug 14 2015 GDBTK\ Manual.lnk*
-rwxrwxrwx 1 noone noone 1455 Aug 14 2015 GNAT\ Debugger.lnk*
-rwxrwxrwx 1 noone noone 714 Aug 14 2015 GNAT\ Reference\ Manual.lnk*
-rwxrwxrwx 1 noone noone 714 Aug 14 2015 GNAT\ User's\ Guide.lnk*
-rwxrwxrwx 1 noone noone 714 Aug 14 2015 General\ GNAT\ information.lnk*
-rwxrwxrwx 1 noone noone 891 Aug 14 2015 Help\ for\ Win32\ Ada\ bindings.lnk*

$ file GNAT\ Ada\ 95\ Compiler/*

GNAT Ada 95 Compiler/Ada GUI IDE.lnk: MS Windows shortcut,
Item id list present, Points to a file or directory, Has Relative path,
Archive, ctime=Fri Aug 14 13:44:46 2015, mtime=Fri Aug 14 13:44:46 2015,
atime=Fri Dec 18 07:43:58 1998, length=695296, window=hide
GNAT Ada 95 Compiler/Ada95 Reference Manual.lnk: MS Windows shortcut,
Item id list present, Points to a file or directory, Has Relative path,
Archive, ctime=Fri Aug 14 13:44:46 2015, mtime=Fri Aug 14 13:44:46 2015,
atime=Sat Jan 25 20:42:36 1997, length=1124674, window=hide
GNAT Ada 95 Compiler/GDBTK Manual.lnk: MS Windows shortcut,
Item id list present, Points to a file or directory, Has Relative path,
Archive, ctime=Fri Aug 14 13:44:48 2015, mtime=Fri Aug 14 13:44:48 2015,
atime=Thu Jan 21 22:47:48 1999, length=18559, window=hide
GNAT Ada 95 Compiler/GNAT Debugger.lnk: MS Windows shortcut,
Item id list present, Points to a file or directory, Has Relative path,
Icon number=0, Archive, ctime=Fri Aug 14 13:44:46 2015,
mtime=Fri Aug 14 13:44:46 2015, atime=Thu Jan 21 22:59:22 1999,
length=1097728, window=hide
GNAT Ada 95 Compiler/GNAT Reference Manual.lnk: MS Windows shortcut,
Item id list present, Points to a file or directory, Has Relative path,
Archive, ctime=Fri Aug 14 13:44:48 2015, mtime=Fri Aug 14 13:44:48 2015,
atime=Thu Jan 21 21:53:04 1999, length=263367, window=hide
GNAT Ada 95 Compiler/GNAT User's Guide.lnk: MS Windows shortcut,
Item id list present, Points to a file or directory, Has Relative path,
Archive, ctime=Fri Aug 14 13:44:48 2015, mtime=Fri Aug 14 13:44:48 2015,
atime=Thu Jan 21 21:54:28 1999, length=350358, window=hide
GNAT Ada 95 Compiler/General GNAT information.lnk: MS Windows shortcut,
Item id list present, Points to a file or directory, Has Relative path,
Archive, ctime=Fri Aug 14 13:44:48 2015, mtime=Fri Aug 14 13:44:48 2015,
atime=Thu Jul 30 01:00:06 1998, length=7130, window=hide
GNAT Ada 95 Compiler/Help for Win32 Ada bindings.lnk: MS Windows shortcut,
Item id list present, Points to a file or directory, Has Relative path,
Archive, ctime=Fri Aug 14 13:44:48 2015, mtime=Fri Aug 14 13:44:48 2015,
atime=Mon Sep 9 11:58:16 1996, length=3733386, window=hide

So, AOB thought he was _including_ the compiler, and he only included his
"links" to the compiler. Which makes the compiler _inclusion_ worthless for
anyone downloading the zip.

So, what do we have in the Variant_X_Cipher directory?:

$ cd Variant_X_Cipher/
$ ls -1a

.
..
.DS_Store
Basic_Num_io.ads
Batch_Encryption_Program_Mark_1.adb
Batch_Encryption_Program_Mark_1.adb.0
Batch_Encryption_Program_Mark_1.adb.1
Batch_Encryption_Program_Mark_1.adb.2
Batch_Encryption_Program_Mark_1.adb.3
Batch_Encryption_Program_Mark_2.adb
Batch_Encryption_Program_Mark_2.adb.0
Batch_Encryption_Program_Mark_2.adb.1
Batch_Encryption_Program_Mark_2.adb.2
Batch_Encryption_Program_Mark_2.adb.3
Change_Of_Origin_I_Coefficients.ads
Change_of_Origin_I_Coefficients.adb
Change_of_Origin_I_Coefficients.adb.0
Change_of_Origin_I_Coefficients.adb.1
Change_of_Origin_I_Coefficients.adb.2
Change_of_Origin_I_Coefficients.adb.3
Change_of_Origin_J_Coefficients.adb
Change_of_Origin_J_Coefficients.adb.0
Change_of_Origin_J_Coefficients.adb.1
Change_of_Origin_J_Coefficients.adb.2
Change_of_Origin_J_Coefficients.adb.3
Change_of_Origin_J_Coefficients.ads
Change_of_Origin_K_Coefficients.adb
Change_of_Origin_K_Coefficients.adb.0
Change_of_Origin_K_Coefficients.adb.1
Change_of_Origin_K_Coefficients.adb.2
Change_of_Origin_K_Coefficients.adb.3
Change_of_Origin_K_Coefficients.ads
Email_Encryption_Program_Mark_1.adb
Email_Encryption_Program_Mark_1.adb.1
Email_Encryption_Program_Mark_1.adb.2
Email_Encryption_Program_Mark_2.adb
Email_Encryption_Program_Mark_2.adb.1
General_Decryption_Program_Mark_1.adb
General_Decryption_Program_Mark_1.adb.0
General_Decryption_Program_Mark_1.adb.1
General_Decryption_Program_Mark_1.adb.2
General_Decryption_Program_Mark_1.adb.3
General_Decryption_Program_Mark_2.adb
General_Decryption_Program_Mark_2.adb.0
General_Decryption_Program_Mark_2.adb.1
General_Decryption_Program_Mark_2.adb.2
General_Decryption_Program_Mark_2.adb.3
Normal_Vector_I_Coefficients.adb
Normal_Vector_I_Coefficients.ads
Normal_Vector_J_Coefficients.adb
Normal_Vector_J_Coefficients.ads
Normal_Vector_K_Coefficients.adb
Normal_Vector_K_Coefficients.ads
Pad_1.adb
Pad_1.ads
PlainTextFile_1.dat
PlainTextFile_100.dat
PlainTextFile_1000.dat
PlainTextFile_10000.dat
PlainTextFile_2000.dat
PlainTextFile_30000.dat
PlainTextFile_4000.dat
PlainTextFile_500.dat
PlainTextFile_50000.dat
PlainTextFile_9.dat
U_MAKE_ASCII_TEST_FILE.adb
b_batch_encryption_program_mark_1.c
b_batch_encryption_program_mark_1.o
b_batch_encryption_program_mark_2.c
b_batch_encryption_program_mark_2.o
b_email_encryption_program_mark_1.c
b_email_encryption_program_mark_1.o
b_email_encryption_program_mark_2.c
b_email_encryption_program_mark_2.o
b_general_decryption_program_mark_1.c
b_general_decryption_program_mark_1.o
b_general_decryption_program_mark_2.c
b_general_decryption_program_mark_2.o
basic_num_io.ali
basic_num_io.o
batch_encryption_program_mark_1.ali
batch_encryption_program_mark_1.exe
batch_encryption_program_mark_1.o
batch_encryption_program_mark_2.ali
batch_encryption_program_mark_2.exe
batch_encryption_program_mark_2.o
change_of_origin_i_coefficients.ali
change_of_origin_i_coefficients.o
change_of_origin_j_coefficients.ali
change_of_origin_j_coefficients.o
change_of_origin_k_coefficients.ali
change_of_origin_k_coefficients.o
email_encryption_program_mark_1.ali
email_encryption_program_mark_1.exe
email_encryption_program_mark_1.o
email_encryption_program_mark_2.ali
email_encryption_program_mark_2.exe
email_encryption_program_mark_2.o
general_decryption_program_mark_1.ali
general_decryption_program_mark_1.exe
general_decryption_program_mark_1.o
general_decryption_program_mark_2.ali
general_decryption_program_mark_2.exe
general_decryption_program_mark_2.o
normal_vector_i_coefficients.ali
normal_vector_i_coefficients.o
normal_vector_j_coefficients.ali
normal_vector_j_coefficients.o
normal_vector_k_coefficients.ali
normal_vector_k_coefficients.o
pad_1.ali
pad_1.o

Now, what we have here is:

1) Another .DS_Store Mac file (but this may still have snuck in from the
"webmaster")

2) A whole lot of what appear to be manually _versioned_ files (all the
*.[0-9] files). Ignoring the hidden files, there are 109 total files,
of which 31 are *.[0-9] format names. So 28.44% of the total files
appear to be _old versions_.

3) No *instruction* files (i.e., a README or some such). So both Alice
and Bob appear to be expected to _just understand_ how to use the code
by osmosis or ESP or some other esoteric method.

4) Several *.exe files (6 of them), several *.o files (20 of them),
several *.ali files (14 of them), several *.c files (6 of them) for a
total of 46 additional files (42.20% of the total number of files) that
are either temporary outputs of his GNAT compiler (*.o, *.ali, *.c) or
windows console executables (*.exe) for 32-bit windows.

None of the temporary files needed to be included, and since Alice
should re-key before using this mess to communicate with Bob II, she
has no need for the precompiled windows executables either. This is
because if she uses the exe she also uses the "key" that AOB setup, so
AOB could read everything she tried to send Bob II.

Note that we have 46 temporary or executable files plus 31 seemingly
_versioned_ files for a total of 77 unnecessary files (70.64% of the
total files are unnecessary)

So, lets remove the temporary and executable files:

$ rm *.exe *.o *.ali *.c

Now, given that there are no instructions, lets start by trying to compile
Batch_Encryption_Program_Mark_1.adb:

$ gnatmake Batch_Encryption_Program_Mark_1.adb

gcc -c Batch_Encryption_Program_Mark_1.adb
Batch_Encryption_Program_Mark_1.adb:3:06: file "normal_vector_i_coefficients.ads" not found
Batch_Encryption_Program_Mark_1.adb:4:06: file "normal_vector_j_coefficients.ads" not found
Batch_Encryption_Program_Mark_1.adb:5:06: file "normal_vector_k_coefficients.ads" not found
Batch_Encryption_Program_Mark_1.adb:6:06: file "change_of_origin_i_coefficients.ads" not found
Batch_Encryption_Program_Mark_1.adb:7:06: file "change_of_origin_j_coefficients.ads" not found
Batch_Encryption_Program_Mark_1.adb:8:06: file "change_of_origin_k_coefficients.ads" not found
Batch_Encryption_Program_Mark_1.adb:9:06: file "pad_1.ads" not found
Batch_Encryption_Program_Mark_1.adb:10:14: file "basic_num_io.ads" not found
Batch_Encryption_Program_Mark_1.adb:12:11: warning: file name does not match unit name, should be "batch_encryption_program_mark_1.adb"
gnatmake: "Batch_Encryption_Program_Mark_1.adb" compilation error

Note, I knew this above would happen, due to having encountered the same
issue with ShuttlePads last year. We've got to first rename the files to be
able to compile them:

$ for name in *.adb *.ads ; do mv "$name" "$(printf $name | tr [:upper:] [:lower:])" ; done

And try recompiling:

$ gnatmake batch_encryption_program_mark_1.adb

gcc -c batch_encryption_program_mark_1.adb
batch_encryption_program_mark_1.adb:476:12: warning: unary minus expression should be parenthesized here
batch_encryption_program_mark_1.adb:500:08: warning: unary minus expression should be parenthesized here
gcc -c basic_num_io.ads
gcc -c change_of_origin_i_coefficients.adb
gcc -c change_of_origin_j_coefficients.adb
gcc -c change_of_origin_k_coefficients.adb
gcc -c normal_vector_i_coefficients.adb
gcc -c normal_vector_j_coefficients.adb
gcc -c normal_vector_k_coefficients.adb
gcc -c pad_1.adb
gnatbind -x batch_encryption_program_mark_1.ali
gnatlink batch_encryption_program_mark_1.ali

Two compiler warnings, I'll ignore those for now, but it did compile. So,
lets try running it:

$ ./batch_encryption_program_mark_1

raised STORAGE_ERROR : stack overflow or erroneous memory access

So, any Alice, picking up this mess, is now faced with a batch of
non-working source code. Maybe batch_encryption_program_mark_2.adb works
instead?

$ gnatmake batch_encryption_program_mark_2.adb

gcc -c batch_encryption_program_mark_2.adb
batch_encryption_program_mark_2.adb:479:12: warning: unary minus expression should be parenthesized here
batch_encryption_program_mark_2.adb:503:08: warning: unary minus expression should be parenthesized here
gnatbind -x batch_encryption_program_mark_2.ali
gnatlink batch_encryption_program_mark_2.ali

Compiles, but does it run:

$ ./batch_encryption_program_mark_2


2017-6-3
18;39;8
A demonstration program of encryption at work >

Prepared Test File Titles

PlainTextFile_1.dat
PlainTextFile_9.dat
PlainTextFile_100.dat
PlainTextFile_500.dat
PlainTextFile_1000.dat
PlainTextFile_2000.dat
PlainTextFile_4000.dat
PlainTextFile_10000.dat
PlainTextFile_30000.dat
ASCII_PlainTextFile_527.dat

PLease enter the name of the file to encrypt >

Ok, so it seems that "mark_2" is the only working one (well, at least as far
as arriving at AOB's 1970's emulation of a green screen tty UI).

Now, on to the real reason for this experiment. In this message:

Message-ID: <b0a5b7fb-fa86-4840...@googlegroups.com>
Subject: VeeCrypt Cipher - Scramble 'n Load Procedure Explained - How It Works

he talks about how to 'uncomment' some put statements in
Load_n_Scramble_Normal_Vector_I_Coefficients to be able to see the before
and after state of his "scrambled" array. So, one edits
batch_encryption_program_mark_1.adb to remove the comments and discoveres
that the source file as windows line endings (this tidbit is largely why I
think the 'apple' files snuck in from his webmaster).

So, uncommenting the put statements, but leaving his "StepNum_1" and
"RepeatsNum_1" alone, recompiling, and running the executable, one gets
3,753 lines worth of "before/after" data. Here is a snippet of the top of
the output file (all 3,753 lines can be had here
https://pastebin.com/qsnNYqAC):

Scrambling
Before After

6 8
2 4
4 2
8 6

2 3
2 3
3 2
3 2

5 2
9 9
9 9
2 5

5 3
1 7
7 1
3 5

9 5
6 8
8 6
5 9

Now, lets rearrange that to fit a bit better here on Usenet:

Before: 6248 2233 5992 5173 9685
After : 8426 3322 2995 3715 5869

Now, remember, I left Austin's 'parameters' set to Austin's choices, which
in the case of "mark_2" are:

SliceNum_1 : CONSTANT Integer := 0; --Start point in array
StepNum_1 : CONSTANT Integer := 4; --Upstream placemoves
RepeatsNum_1: CONSTANT Integer := 750; --Repeats

Note how the "scramble" is nothing more than reversing the order of groups
of four values.

6248 reversed is 8426
...
9685 reversed is 5869

This is what Austin considers a "scramble". Reversing the order of
non-overlapping sub-groups of digits.


So, two takeaways from this experiment:

1) Alice better be willing to put in a bunch of effort to _fix_ things as
delivered by Austin, because what Austin has given her requires quite a
bit of change before it will work. And she better be willing to figure
it out for herself because Austin's zip provides no instructions on
what to do.

2) Austin's idea of a _scramble_ is a very poor scramble by any normal
definition of the word "scramble".

[MM]

On Sunday, 4 June 2017 00:07:22 UTC+1, Rich wrote:
> A small experiment (on Linux).

I tend to use either FreeBSD or MacOS.

> So, lets remove the temporary and executable files:
>
> $ rm *.exe *.o *.ali *.c
>
> Now, given that there are no instructions, lets start by trying to compile
> Batch_Encryption_Program_Mark_1.adb:
>
> $ gnatmake Batch_Encryption_Program_Mark_1.adb

This works, case mismatch notwithstanding, on FreeBSD and MacOS.

[ Case problem snipped ]

> Note, I knew this above would happen, due to having encountered the same
> issue with ShuttlePads last year. We've got to first rename the files to be
> able to compile them:
>
> $ for name in *.adb *.ads ; do mv "$name" "$(printf $name | tr [:upper:] [:lower:])" ; done

I do this anyway, just because. And I do a more detailed version of
1) Remove all the comments, because they are mostly useless
2) Reformat the code with gnatpp --<lotsa stuff>
3) Manually remove all the extra output garbage

> And try recompiling:
>
> $ gnatmake batch_encryption_program_mark_1.adb

I add -Wall, and fix the issues raised, because a few of them are usually genuine bugs.

> Compiles, but does it run:
>
> $ ./batch_encryption_program_mark_2

It usually does after my cleanups, and I also add common-line usage to them
(trivial job) if I'm going to (ab)use them more than once.

> So, uncommenting the put statements, but leaving his "StepNum_1" and
> "RepeatsNum_1" alone, recompiling, and running the executable, one gets
> 3,753 lines worth of "before/after" data. Here is a snippet of the top of
> the output file (all 3,753 lines can be had here
> https://pastebin.com/qsnNYqAC):

I pulled out this Lego-block a couple of years ago so I can mess with it
in isolation. Your analysis is correct. It's crap.

> So, two takeaways from this experiment:
>
> 1) Alice better be willing to put in a bunch of effort to _fix_ things as
> delivered by Austin, because what Austin has given her requires quite a
> bit of change before it will work. And she better be willing to figure
> it out for herself because Austin's zip provides no instructions on
> what to do.

Agree.

> 2) Austin's idea of a _scramble_ is a very poor scramble by any normal
> definition of the word "scramble".

Agree. And he's been told this many times before. He seems to be holding
on for nothing more than simple bloody-mindedness.

M
--

[Rich]

MM <mrvm...@gmail.com> wrote:
>> Now, given that there are no instructions, lets start by trying to compile
>> Batch_Encryption_Program_Mark_1.adb:
>>
>> $ gnatmake Batch_Encryption_Program_Mark_1.adb
>
> This works, case mismatch notwithstanding, on FreeBSD and MacOS.

I'm not surprised about MacOS as I think I remember seeing something
about MacOS also being case preserving but case insensitive.

I'm surprised about FreeBSD, I would have expected the same results as
on Linux.

[austin...@hotmail.com]

My cipher does not depend very strongly on the degree of scrambling - if it it did there are is much more I could do to enhance that but no - in this cipher especially almost no scrambling would be still be secure - the method was developed else where and as applied to VeeCrypt it inoy needs to be perfunctory.

AOB

[MM]

On Sunday, 4 June 2017 08:03:35 UTC+1, austin...@hotmail.com wrote:
> My cipher does not depend very strongly on the degree of scrambling

Why not?

Right now, the scrambling is an undocumented feature of ALL of your work.

M
--

[austin...@hotmail.com]

On Sunday, June 4, 2017 at 12:07:22 AM UTC+1, Rich wrote:

It is important to me that it should be understood that as applied to VeeCrypt the scrambling Ploy is hardly used if at all - the scrambling is already done beforehand to a prepared batch of keypads and Alice simply indexes a cipher variant and associated keypad from their mutual databases memory when she wants to encrypt - the scrambling procedure is only used periodically to communicate with Bob as an on-going maintenance tool or as a quick facility to check something suspicious in an emergency.

Scrambling does a good job by enabling the entities to set up mutually synchronised databases initially - it changes in usefulness from situation to situation.

The purpose of my post was to introduce the idea in general to readers.

adacrypt

[MM]

On Sunday, 4 June 2017 09:33:11 UTC+1, austin...@hotmail.com wrote:
> It is important to me that it should be understood that as applied to VeeCrypt
> the scrambling Ploy is hardly used if at all - the scrambling is already done
> beforehand to a prepared batch of keypads and Alice simply indexes a cipher
> variant and associated keypad from their mutual databases memory when she
> wants to encrypt - the scrambling procedure is only used periodically to
> communicate with Bob as an on-going maintenance tool or as a quick facility
> to check something suspicious in an emergency.

OK - thats a start, but now please document the when/why/how of all the uses.

> Scrambling does a good job by enabling the entities to set up mutually
> synchronised databases initially - it changes in usefulness from situation
> to situation.

How so? Details, please.

> The purpose of my post was to introduce the idea in general to readers.

Introducing the idea is good, but the execution is wanting. This is not a
problem if it is corrected.

M
--

[austin...@hotmail.com]

On Sunday, June 4, 2017 at 12:07:22 AM UTC+1, Rich wrote:

Correction:
I should have said that the entities don not have to exchange scrambling parameters very often because the cipher program comes with a batch of prepared scrambled keypads - alice simply indexes a particalar variant and one of the (there are fify)prepared keypads and then encrypts according to these.

Note well: The alternative to mutaul databases is nasty - it means the old very vulnerable task of sending keys along with *each message - a pain to say the least - on the other hand once the mutual databases are set up there is no more key transport - what a relief that is so don't anybody knock my invention of "Synchronised Mutual Data Bases".

[MM]

On Sunday, 4 June 2017 12:47:49 UTC+1, austin...@hotmail.com wrote:
> Note well: The alternative to mutaul databases is nasty - it means the old very
> vulnerable task of sending keys along with *each message - a pain to say the
> least - on the other hand once the mutual databases are set up there is no
> more key transport - what a relief that is so don't anybody knock my invention
> of "Synchronised Mutual Data Bases".

Garbage. Ellis, Cocks, Williamson, Diffie & Hellman solved that problem decades ago.

These days it's called the Diffie-Hellman key exchange protocol. Simon Singh
describes it in the book that you have (and clearly haven't finished or understood).

M
--

[Rich]

> Note well: The alternative to mutaul databases is nasty - it means
> the old very vulnerable task of sending keys along with *each message
> - a pain to say the least - on the other hand once the mutual
> databases are set up there is no more key transport - what a relief
> that is so don't anybody knock my invention of "Synchronised Mutual
> Data Bases".

With a traditional cipher one does not *send the key* with the message.
The key is kept secret, and one only has to send a new key when
changing keys. As long as the key is not compromised (i.e., stolen by
Eve) then the key does not need to be changed.

This is because a traditional cipher when used in a cipher mode
provides a way to randomize each encryption with the same key such that
even if Alice encrypts the identical plaintext, the result is different
ciphertexts. And the randomization method data is small (typically the
size of one cipher block) and so is sent in the clear with the
ciphertext.

As well, in a traditional cipher, the key is very short (for AES it is
16 bytes: i.e: 0123456789abcdef) and the method of randomization (the
IV) is also typically the same size (so it would look like
2867183747834723).

So, at most Alice needs a way to send Bob 16 bytes to send him a new
key, and she adds 16 bytes to each encrypted message for a new IV.
That is hardly a pain. Further, her encryption program will handle the
generation and attachment of the 16 byte IV, so she would not even
notice that one, so zero pain.

With your Batch_Encryption_Program_Mark_2.adb, you have:

seven "SliceNum_?" variables for Alice to change,
seven "StepNum_?" variables for Alice to change, and
seven "RepeatsNum_?" variables for Alice to chage

just to adjust the "parameters" (with 35 bytes as presented in your
.zip)

and an additional

2,997 lines of case statement in Normal_Vector_I_Coefficients.adb,
2,997 lines of case statement in Normal_Vector_J_Coefficients.adb, and
2,997 lines of case statement in Normal_Vector_K_Coefficients.adb

which map up to four digit numbers into three digit output numbers in
an unknown semi-rearranged way. Presuming Alice must also rearrange
those output numbers that is 26,973 (2997*3*3) additional bytes of data
that Alice has to communicate to Bob II in order to rekey.

So, AES, in CBC mode, requires 16 bytes for a key and 16 bytes for an
IV, for a maximum of 32 bytes on Alice's part (half of which the
encryption program can handle automatically for her). And, this
handles randomizing each encryption by picking automatically a new
random IV for each message (16 bytes per message).

Your cipher requires at least 35 for parameters and 26,973 bytes for
coefficients data for at least 27,008 bytes just to rekey, and there is
no randomization per message, which is why the linear solution of
simultaneous equations works to break your cipher. The identical input
message produces the identical output ciphertext as long as the key
does not change.

So if Alice wanted to randomize the output of each encryption, she
first has to send Bob II 27,008 bytes of data (and understand how/why
to make the proper Ada code changes) vs. simply randomly picking 16
bytes.

Your "mutual database" technology is the one that is the *much larger
pain* for the entities.

[Bruce Stephens]

On 04/06/2017 12:47, austin...@hotmail.com wrote:
> Correction:
> I should have said that the entities don not have to exchange scrambling parameters very often because the cipher program comes with a batch of prepared scrambled keypads - alice simply indexes a particalar variant and one of the (there are fify)prepared keypads and then encrypts according to these.

If anybody is to use this (and they surely aren't) you'd need to give
more specificity than that.

> Note well: The alternative to mutaul databases is nasty - it means the old very vulnerable task of sending keys along with *each message - a pain to say the least - on the other hand once the mutual databases are set up there is no more key transport - what a relief that is so don't anybody knock my invention of "Synchronised Mutual Data Bases".

What on earth does that mean?

Suppose Alice wants to make her own encryption scheme and is fine with
just symmetric encryption (where the participants need to keep a secret
key for everyone they communicate with). (This is how things had to work
before 1976-ish.)

So when sending a message to Bob, she chooses Bob's secret key,
generates a fresh IV and encrypts the message. She sends the IV and
encrypted message to Bob. (The IV is considered a part of the
ciphertext.) Notice that really all she does is give the message and
Bob's identity to the program; generating the IV and so on is all just
part of the process.

And Bob can decrypt using the key (which he knows) and the IV.

There's no "sending keys along with each message". There never was.

Possibly you're thinking of asymmetric encryption, but let's be honest,
there's just no hope of you understanding that well enough to offer any
sane critique, so you're much better off not trying.

[Richard Heathfield]

On 04/06/17 12:47, austin...@hotmail.com wrote:
<snip>

>
> Correction: I should have said that the entities don not have to
> exchange scrambling parameters very often because the cipher program
> comes with a batch of prepared scrambled keypads - alice simply
> indexes a particalar variant and one of the (there are fify)prepared
> keypads and then encrypts according to these.

There's nothing simple about it. I've seen your explanation and I still
don't know how to do it.

> Note well: The alternative to mutaul databases is nasty - it means
> the old very vulnerable task of sending keys along with *each message

No, there are other ways. Even without public key cryptography (which is
the obvious way to exchange new keys), it is possible to distribute keys
to very large numbers of people. For example, you can just publish a key
book. The Germans did this in WW2 for Enigma users.

Yes, there was the risk of a key book falling into the hands of the
enemy, and yes, this sometimes happened, but it was relatively rare, and
was not the principal reason (or even a significant reason) that Enigma
ultimately failed its users. If Enigma had been used properly, Bletchley
Park would have been completely stumped, and the publishing of keys to
large numbers of military personnel would not have been enough of a
weakness to be of more than minor assistance to the Allies.

> - a pain to say the least - on the other hand once the mutual
> databases are set up there is no more key transport - what a relief
> that is so don't anybody knock my invention of "Synchronised Mutual
> Data Bases".

Your "invention" is nothing more than "let's share a key, and let's post
changes to each other". It can be found on Page 180 of "Applied
Cryptography" (2nd edition), by Bruce Schneier - published in 1996.

Its weakness is explained right there on that page.

--
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