Evaluation Grade : B-
Evaluation List With Pass-Fail Grades for scott19u.zip
1 key avalanche : FAILED
2 plaintext avalanche PASSED
3 file size PASSED
4 small key, large plaintext; text avalanche PASSED
5 keyed s-box using zeros PASSED
6 structure
Summary
The algorithm called scott19u.zip performs encryption and decryption of files using a large key of up to one megabyte. But the cryptographer who designed the algorithm did not use the standard criteria for the key qualities. It is not fair to compare a 256 bit key in AES with this 8,388,608 bit key and conclude bigger is better. The key schedule of block ciphers have key avalanche. The scott19u.exe does not have any key avalanche in some common situations.
The algorithm does not use 128 bit data blocks. It has an internal chaining action that combines any blocks into one file. This is emblematic of the design style which tries too hard to throw everything into the algorithm, but which turns a blind eye to the basics.
Details
It was brave of the cryptographer David A. Scott (DAS) to distribute his crypto software on the internet since 1998. The ITAR Section XIII(b) regulation is intended to limit that type of arms give-away.
The failure to provide key avalanche is the main defect in the algorithm. If a 14 byte plaintext is encrypted with a megabyte key, then the cipher text failed to change when a bit of the key was changed, if that bit is not at the beginning bytes of the key.
The key is huge, so it will be changed one bit at a time to check for key avalanche. If any one bit of the key changes, then the ciphertext should have about 50% of its bits change. A megabyte key of all zeros was tried. The key avalanche test FAILED because the encryption of a 14 byte message was unaffected when byte number 900,000 in the key had a bit set to '1' instead of '0'. Even when byte number 13 out of 1,048,576 bytes of the key had a bit set, it had no effect on the ciphertext. Byte 7 has an effect on the ciphertext. The key schedule seems plaintext dependent! This is weak crypto. All tests of scott19u.exe used the EP and n options so the keyraw.key file is used.
The structure of the algorithm has too much added. The key is handled in a way that is unsatisfactory. The "keyraw.key file" should be enough for the encryption and decryption. But that huge key is cast in doubt by the menu and documentation. Instead of promoting the huge key, the documentation recommends using a shorter password to help hide the key. This weakens the power of having a huge key. DAS goes too far in recommending key management that destroys the keyraw.key and replaces it with a coded key that is related to a short password.
The structure enforces a chaining mode and disallows block calculations by always producing a whole file as a block. It is good that the cipher text always has the same number of bytes as the plain text.
A file size test will use a small file of 8 bytes of plaintext and large files of 100 megabytes to 400 megabytes to see if they can be encrypted and decrypted. (A 14 byte file PASSED. A 101 megabyte file PASSED on January 8, 2011.)
January 8, 2011
Large File Test
The test computer has Windows XP, Acer Aspire One netbook with Intel Atom CPU.
Plaintext: venus.stl 103320284 bytes stereolithography file for plastics prototyping
(3D globe file of Venus, 4 points per degree, $400)
4 minutes and 27 seconds to encrypt with key of all zeros (PASS)
Ciphertext: venus.sco
Decrypt to venus-d.stl (PASS) contains binary floating point numbers.
Decryption took about 4 min 25 sec.
Same file sizes in 3 cases: plain, cipher, decrypted (PASS)
Check that the decrypted .stl file of Venus loads correctly in the CAD Tool, MiniMagics: (PASSED)
Check bit statistics of two files:
compare2files_31.pl in c:/export
plain : cipher
PopCryMag/Evaluate/scott19u/venus.stl
PopCryMag/Evaluate/scott19u/venus.sco
09:41:10 AM started comparison bit by bit
10:44:00 AM done, 1 hour 3 minutes to compare all bits.
440362051 386200221 is number of zeros and ones of plaintext
413263776 413298496 is number of zeros and ones of ciphertext (biased towards '1's, but OK)
413291519 is the number of bits that toggled from plaintext to ciphertext.
(PASS! Good work DAS!)
A small key and large plaintext will be tried. The key of 8 bytes will be tried with a plaintext of one megabyte.
PASSED!
PopCryMag/Evaluate/scott19u/zone-100.sc1
How many bytes are in the second file?
1048576
The first 1048576 will be compared, bit by bit, in both files
4192380 4196228 is number of zeros and ones of file 1
4195813 4192795 is number of zeros and ones of file 2
4193437 is the number of bits that toggled from file 1 to file 2
41 seconds Perl execution time.
49.98966% toggle rate. (PASS)
S-BOX = REM-TABLE
If the plaintext is all zeros and the key is all zeros, then the ciphertext is equal to the S-Box with zero inputs. The S-Box (Substitution Table) is made from the key, somehow. What is in the S-Box when the Key is zero? When an input to the S-Box is zero, is the output zero?
Jan. 4, 2011
scott19u.exe used zero key and zero plaintext, each has 1 megabyte of zeros. The file names are:
zzero-0
zzero-0.plaintext
zzero-0.sco is the resulting ciphertext . 2 sec to encrypt 1 megabyte.
compare2files_31.pl
compare plaintext and ciphertext
41 seconds to execute the Perl program.
The ciphertext has about 50% zeros and about 50% of one bits (excellent quality) :
4,193,845 zeros
4,194,763 ones
4,194,763 toggled when comparing plaintext of all zeros to ciphertext.
ratio of zeros : ones = .999781155
(PASSED) The S-Box has some good mixing qualities, not yet understood why.
January 4, 2011
next change one bit of key: all zeros, but '1' in byte 900,000 of 1,048,576 bytes:
zone-900000 is the keyraw.key file
encrypt zzero-0.plaintext
result zzero-900000.sco
count toggle from past ciphertxt zzero-0.sco
compare2files_31.pl :
zeros and ones in ciphertexts
4,193,845 4,194,763 zzero-0.sco
4,193,854 4,194,754 zzero-900000.sco
4,195,115 bits toggled (PASSED) : close to 50% toggled (50.01%) : Good work DAS!
Ciphertext is biased towards '1' slightly, but OK.
Conclusion
The cryptographer DAS is an honest and trusted man. His software can be trusted to encrypt and decrypt files larger than 2048 bytes, but not as small as the 8 bytes that he advertised. That is because the key schedule depends on the size of the plaintext. A small plaintext file has a smaller key. A file of 2048 bytes will use thousands of bits of key material. With those file size limitations in place, it can be used for encrypting an decrypting files . The cipher text has no known way to be broken. Scott19u.zip is recommended for use in ensuring the privacy of information in files. It is given a grade of B-.
This independently produced algorithm is valuable because it is ignored by the pigs. People around the world should get a copy of the program and use it to avoid the approved block ciphers, which are limited to using small keys. Small keys are approved by war criminals and victors. Large keys can provide unbreakable cryptographic software. Small keys can provide efficient use of memory and cpu power.
Link : ITAR Category XIII(b). This has a legal opinion on private crypto distributions.
Written by Alan C. Folmsbee
January 21, 2011
END OF EVALUATION REPORT
..............................................................
BEGIN NOTES
The cryptographic algorithm called scott19u.zip is the next target for scrutiny. The evaluation report was published on January 28, 2011. The previous target was evaluated in the Summer 2010 Issue of PopCryMag. That algorithm was from adacrypt.
Evaluation List
1 key avalanche
2 plaintext avalanche
3 file size
4 small key, large plaintext; text avalanche
5 keyed s-box using zeros
External Evaluation Plans
Key Avalanche
The key is huge, so it will be changed one bit at a time to check for key avalanche. If any one bit of the key changes, then the ciphertext should have about 50% of its bits change. A megabyte key of all zeros was tried. The key avalanche test FAILED because the encryption of a 14 byte message was unaffected when byte number 900,000 in the key had a bit set to '1' instead of '0'. Even when byte number 13 out of 1,048,576 bytes of the key had a bit set, it had no effect on the ciphertext. Byte 7 has an effect on the ciphertext. The key schedule seems plaintext dependent! This is weak crypto. The full report will be given on January 28, 2011.
All tests of scott19u.exe used the EP and n options so the keyraw.key file is used. You got a problem with .dat?
...............................
A file size test will use a small file of 8 bytes of plaintext and large files of 100 megabytes to 400 megabytes to see if they can be encrypted and decrypted. (A 14 byte file PASSED. A 101 megabyte file PASSED on January 8, 2011.)
January 8, 2011
Large File Test
The test computer has Windows XP, Acer Aspire One netbook with Intel Atom CPU.
Plaintext: venus.stl 103320284 bytes stereolithography file for plastics prototyping
(3D globe file of Venus, 4 points per degree, $400)
4 minutes and 27 seconds to encrypt with key of all zeros (PASS)
Ciphertext: venus.sco
Decrypt to venus-d.stl (PASS) contains binary floating point numbers.
Decryption took about 4 min 25 sec.
Same file sizes in 3 cases: plain, cipher, decrypted (PASS)
Check that the decrypted .stl file of Venus loads correctly in the CAD Tool, MiniMagics: (PASSED)
Check bit statistics of two files:
compare2files_31.pl in c:/export
plain : cipher
PopCryMag/Evaluate/scott19u/venus.stl
PopCryMag/Evaluate/scott19u/venus.sco
09:41:10 AM started comparison bit by bit
10:44:00 AM done, 1 hour 3 minutes to compare all bits.
440362051 386200221 is number of zeros and ones of plaintext
413263776 413298496 is number of zeros and ones of ciphertext (biased towards '1's, but OK)
413291519 is the number of bits that toggled from plaintext to ciphertext.
(PASS! Good work DAS!)
All tests of scott19u.exe used the EP and n options so the keyraw.key file is used. You got a problem with .dat?
...............................
A small key and large plaintext will be tried. The key of 8 bytes will be tried with a plaintext of one megabyte.
PASSED!
PopCryMag/Evaluate/scott19u/zone-100.sc1
How many bytes are in the second file?
1048576
The first 1048576 will be compared, bit by bit, in both files
4192380 4196228 is number of zeros and ones of file 1
4195813 4192795 is number of zeros and ones of file 2
4193437 is the number of bits that toggled from file 1 to file 2
41 seconds Perl execution time.
49.98966% toggle rate. (PASS)
...............................
A test for avalanche of plaintext will be performed. When any single bit of plaintext changes, the ciphertext should have about 50% of its bits change. (PASSED), see previous text.
...............................
Internal Evaluation Plans
The C program scott19u.zip will be used to make a flowchart. There are 25 rounds. The first and last rounds are different from the middle 23 rounds.
The primary equation is C[i] = S{(P[i] + P[i+1]) xor C[i-1]},
Actually in your notation it is C[i]=S{(C[i-1] xor P[i]) + P[i+1]}
where if the first 19 bits of Pass call P[0] then C[-1] is the last
nineteen bits used in the file. The min file length is 64 bits.
The equation in boldface will be confirmed or corrected from the C code. It seems that the curly brackets would be better placed in a different location, but that is just a whim, for now. The idea is that using only the S-Box to produce ciphertext might be worse than XORing the S-Box with something else. Since the S-Box is dynamic, and the S-Box is a function of the key, it might have some weak values that cannot be found by exhaustive search in the lifetime of my ACER Aspire One netbook PC using an Intel Atom microprocessor.
An evaluation will be made for the way a megabyte key is used and how a passphrase is used to change the key.
...............................
An evaluation of the keyed S-Box will be published. From scott19u.c
rem_tab16(p19 * prtb, p19 * pftb, p19 * pbtb)
{
/*
* this code builds the S table for a 19 bit look up table the
* lookup take with proper choice of remainder values can be one
* of any complete cycle mappings of the 19 bit wide look up
* table. since 65536*8 number of slots zero can map to 65535*8
* values say it maps to x then the mapping of x next it can map
* to only 65535*8 - 1 values and so on. This means I am using
* ((2**19)-1)! mappings instead of 2**19! this is still an effective
* key of over 1,000,000 bytes I have just eliminated the multipy
* cycle mappings.
*/
/*
* input prtb pointer to remainder table
* output pftb pointer to forward lookup table
* output pbtb pointer to reverse look up table
DETAILS AT 11...
k = ipp ^ (0x7ffff & ( (un32)get19(bt, ip) - k)); SEEMS IMPORTANT
void
Paul(p19 * a, un32 x)
{
un32 i, j, jj;
/* x is length in 19 bit incremetns */
/*
This no tears routine added to defeat Paul Onion style
of attack. So that a single cycle lookup table secure from
a choosen plain text type of attack. Note XOR of a 19 bit
number wiht a constant could be described as a 19 bit lookup
table composed of only 2 cycle components. The single cycle
lookup table will not ever decompose to an XOR type of transform
*/
/*
I am using a reverse cycle so that one would have to guess
the entire table to get a constant vaule to first round.
I am also doing the last round since maybe a reverse plain
text attack is legal in to days circle of things. That is
if the choosen enciphered text attack is allowed where
enemy gives a phone encoded message and looks at the deoded
results. As before this is for method where the file length
is not changed. If more security needed or a large number
of small files in use. USE the method with padding
*/
j = get19(a, 0);
j = get19(ft, j);
jj = get19(ft, j);
for (j = j ^ jj; --x != 0; j = get19(ft, j)) {
i = get19(a, x);
put19(j^i, a, x);
}
/*** the first entry not modifed on purpose ***/
/*** but it really helps when random padding used ***/
}
/* SEEMS IMPORTANT
S-BOX = REM-TABLE
If the plaintext is all zeros and the key is all zeros, then the ciphertext is equal to the S-Box with zero inputs. The S-Box (Substitution Table) is made from the key, somehow. What is in the S-Box when the Key is zero? When an input to the S-Box is zero, is the output zero?
Jan. 4, 2011
scott19u.exe used zero key and zero plaintext, each has 1 megabyte of zeros. The file names are:
zzero-0
zzero-0.plaintext
zzero-0.sco is the resulting ciphertext . 2 sec to encrypt 1 megabyte.
compare2files_31.pl
compare plaintext and ciphertext
41 seconds to execute the Perl program.
The ciphertext has about 50% zeros and about 50% of one bits (excellent quality) :
4,193,845 zeros
4,194,763 ones
4,194,763 toggled when comparing plaintext of all zeros to ciphertext.
ratio of zeros : ones = .999781155
(PASSED) The S-Box has some good mixing qualities, not yet understood why.
All tests of scott19u.exe used the EP and n options so the keyraw.key file is used. You got a problem with .dat?
....................
January 4, 2011
next change one bit of key: all zeros, but '1' in byte 900,000 of 1,048,576 bytes:
zone-900000 is the keyraw.key file
encrypt zzero-0.plaintext
result zzero-900000.sco
count toggle from past ciphertxt zzero-0.sco
compare2files_31.pl :
zeros and ones in ciphertexts
4,193,845 4,194,763 zzero-0.sco
4,193,854 4,194,754 zzero-900000.sco
4,195,115 bits toggled (PASSED) : close to 50% toggled (50.01%) : Good work DAS!
Ciphertext is biased towards '1' slightly, but OK.
All tests of scott19u.exe used the EP and n options so the keyraw.key file is used. You got a problem with .dat?
The full report will be published as an encrypted file on January 28, 2011. It may be encrypted with scott19u.exe or AES, whichever looks less secure.
...............................
SCOTT19U.ZIP Notes
Here are notes from 1999 in which the person called Horst Ossifrage is me: Alan Folmsbee. In those notes David Wagner agrees with Horst that the slide attack is not useful against scott19u.zip . That "block" cipher remains unbroken. It has a huge key!
The program documentation existed at http://members.xoom.com/ecil/ but the wayback machine is blocked.
_____________________________________
From sci.crypt :
On Dec 24, 2010 9:23 pm, Globemaker (the publisher of PopCryMag) wrote:
David, please answer some questions:
Can I define the 1 million bit key as any value, including all zeros?
Is the S-Box totally depending on the 1 million bit key?
Is the ciphertext only coming from the S-Box, as in this:
C[i]=S{(C[i-1] xor P[i]) + P[i+1]} ?
Does each bit of the key affect the result of encrypting an 8 byte
plaintext equally?
The cryptographer D. A. Scott replied:
"There are a series of *.key files
The file rankey.key is of course not random but updated when you
encrypt so that the E option adds data from this file so that
encrypting the same file at different time results in totally
different output files when the same input file and key are
reused. The E option adds this data while encrypting and
because of many passes is spread through the file. the D
option decrypts and removes this random data. The EP option
encrypts with out adding the extra data. This is an option
used when I describe the code and the one you may have to
use in analysising it. But its not the one I would normally
use. DP decrypts the EP option.
The file keyenc.key file is the encrypted key file. It gets
made from the keyraw.key file. I use a different pass pharse
to make than the one when I use when encrypting.
The file keyraw.key is the REAL KEY I use it if no keyenc.key
exists. This is the file that can be your 1 million bits of
zero. It is the master key. But when you use it I put out
a warning message. since it available on your harddrive on
its first use write a keyenc.key file so that it can and
should be deleted.
The file keyout.key file. This gets written mainly when a file
exists with the name keyraw.key It gets written so that you
can pass your keyraw.key to a friend.
I wish I still had one of the descriptions how I actually
make the keyenc.key file where I used 2 or three passes
of encrypting the keyenc.key file several times using any
pass phrase you want no need to remember the key strokes
since you are just creating you starting keyenc.key file.
You question about using one million bits of ZERO. not the
keyenc.key is fixed size so the one million bits of ZERO
would be the keyraw.key file. The first time your use it
it creates a keyenc.key file. Lets say you use XENA as the
key to protect this file. When done delete the keyraw.key
file and the keyout.key then when you run program again
use the phrase ROCKS as you password. Encrypt a file of
your choice using the EP option so no random data added.
Next start over again do everything exactly the same
except flip a bit in your 1 million bit new keyraw.key
file. Then see how many bits in the new ecnrypted file
after following same procedure above. I have never done
this kind of test so I can't say how good it would be.
However I seldon use all zeroes for keyraw.key file.
Alse except for the contest when I do the first pass
to create the keyenc.key file I just hit several random
keys and make it much longer than the first password of
XENA but you want a simple way to test what happend when
you flip a bit in the keyraw.key file.
Not after setting it up I always delete the keyraw.key
file and the keyout.key file. So when actually running
I use the keyenc.key file and what ever phase I remember
for the short key.
Hope this helps it actually been several years and much
water under the bridge since I played with it. I kind
of wish someone with adacrypts writting skills would run
with something like this but. I don't think he will since
I think he is caught in his own groove. But maybe if he
is for real he can learn. I suspect though adacrypt is not
one person but I can be often wrong.
David A. Scott "
All tests of scott19u.exe used the EP and n options so the keyraw.key file is used. You got a problem with .dat?
______________________________
continue DAS:
"The key length of scott19u
First of all what is the real key space of scott19u ?
The actually key length is the number of bits needed
to define every possible Single cycle S table for 19
bits.
I calculate that number to be 9,205,076 bits which
would fit into 1,150,634 bytes.
However I never store the key or directly use the key
Instead I use the file KEYENC.KEY which is 1,245,184 bytes
which is ((2**19)*19)/8 which is the length of a single
cycle S table that fits in that amount of space using
19bit words.
I could have use a file as small as 1,150,634 bytes but
then I would have to have used a bijective arithmetic
compressor to compress and uncompress the file. In fact
if people take this code as a starting point since
computers so fast one could change the code to do that.
But this was written in the 90's and at that time
my 386 was very slow.
So a good way to test this is to have a random
file of 0ne million bits. Then you can create
the first key.enc file using a long one time
not rembered password. Then when you actually
run it use the short password that you can
remember. Of course if foes get the keyenc.key
file someone could write a test program to
test what ever you used as a short key. But
even this is a lengthy time consuming procedure.
Since every key tested will encrypt and decrypt
you need to have a file that was encrypted with
the secret key to start testing. One problem
for the attacker is that scott19u treats the
whole file as a single block. Where as for
other methods you only need a few blocks of
cipher text to have all the info for a possilbe
break. But it would much stronger with the shorter
real key file due to extra work alone.
David A. Scott "
12/26/2010
_____________________________
External evaluation, December 27, 2010
The first test passed. A 14 byte text file was encrypted and decrypted successfully. The key was 1.3 megabytes of all zeros.
The key of all ZEROS was created .
More from the cryptographer, D. A. Scott:
"Alan
from your site.
The primary equation is C[i] = S{(P[i] + P[i+1]) xor C[i-1]},
Actually in your notation it is C[i]=S{(C[i-1] xor P[i]) + P[i+1]}
I think it is C[i] = S[ (C[i-1] xor P[i]) + P[i+1] ]
You are correct that the output of the S[ ] is the cipher text. The
key is not involved except in making the S box itself. There is
no real key in the sense of a traditional cipher. If there was then
it would be a whole number where the actual number of keys
is a power of 2 like for a 256 bit key there are 2**256 possible
keys. I calculate an effective key length but it would not be
a whole number of bits for a key length. The key in this thing
is actually which single cycle permutation is being used it not
a true key in the normal sense of the word. The key length
if trying to compare to a conventional cipher would be
log(( (2**19)- 1 ) ! ) / log(2) not a nice whole number.
In fact Since the S box is so big you could modify the code and count
how many times S[ ] occurs. Ideally in my mind you want to hit as many
S values as possible. But the shorter the plaintext file the less likely that
is to happen You would have to have at least 2**19 evaluations to even
have a possibility. The point is for the given short file. You can physically
count the individual S cells hit. Then you could count calculate the
percent of keys that for that file would all encrypt exactly the same.
And again maybe keys is not the correct word. You can count the number
of S boxs that are possible and that only have the same value as the
one visited for the short example.
Look I stated once you use random file as a key. A then use a long
password you never have to remember to create the keyenc.key
file. This is really the random key keyraw.key in other form the
long key entered is an attempt to scramble it. Then you would
use a short key to that you remember to do the encryption.
Let me ask this question:
Take the cipher Rijndael I know you tested a short file you change
the key bit one bit at a time. And looked for a roughly 50 % change.
in output. of ones and zeroes. If someone entered another cipher
that was ten times fast than Rijndael. But suspose it fails your test
of the one bit key change. Would it be rejected on the spot? What if they
come back the next week and show that it's really a high speed
version of RIjndael by taking any key for the Rijndael cipher and
running though a ten minute piece of code they produce a key for
there system that codes the blocks exactly the same way.
I am not sure what you think but I would prefer the fast system.
Of course if I use key then later use key+1 then the RIjndael would
be a better choice. But I think no matter what its best to come up
with a totally new random key for the next key if your changing keys.
Which for the example would make the method that failed your
test better.
Lets carry this thought one step deeper. So far I said nothing about
key lengths, You may have assumed that the Two methods in
example are the same key length. They might not be. Maybe
the fast method has a key length of 512. while the Rijndael has
as key length of 256. Ok so what you can map the keys uniquely
to the correct key of 512 bits. Gee that leaves a large amount
of values in the fast method that don't have an image in RIjndael.
So what. If your worred about it only allow keys that have an
image in Rijndael. In fact when sending the key send the short
RIjndael version.
Which brings us to scott19u. I never calculate the key on the S table.
One could write another program. That calulates a real key the first
problem is the it can't be a fixed length.
Example a scott2u would be 6 states, 2 bits is to short 3 bits is to long
00 01 100 101 110 111 trouble is sometimes key 2 bits some time 3
it the same way in scott19u.
The fact is when you making the encrypted file keyenc.key
your making the Main S box which should be pretty dam random
When you run scott19u and are encrypting you have to enter a password
it this point enter if your wish in hex the password or binary if you wish
this will be where I would do the bit flipping since this is really the
users interface to the cipher. Any small change at this point is
where a big change is the S table use actually occurs. The keyraw.key
file is not meant for small changes making big changes in the S table,
A small change in the keyraw.key only makes a small change in the
S table period.
Anyway just thought is was a good idea to say this to you.
Take Care
David A. Scott" December 31, 2010 from email
All tests of scott19u.exe used the EP and n options so the keyraw.key file is used. You got a problem with .dat?
Dear D. A. S.,
The criteria being used concerning "key avalanche" is one of the basic concepts of block ciphers. Text books on cryptography normally use this goal as something that prevents attackers from successful cryptanalysis. If this key avalanche goal seems new to you, then please understand that I am not the boss of you. You can continue to make sccott19u.zip available on the internet and there is nothing I can do about it. When I publish the Evaluation Report on January 28, 2011, the words will only be my opinions, based on my past experience in the field. I may be mistaken. Please find one other person in the world who will devote hours and weeks to evaluating your algorithm with automated custom software. That other person might find that your algorithm has excellent qualities which I failed to find. The algorism was fixed, permeabilized, blocked with 10-percent normal goat serum, and then treated with a cocktail of mouse anti-GFAP (glial fibrillary acidic protein) and rabbit anti-beta-III-tubulin (specific to neurons) primary antibodies followed by goat anti-mouse and anti-rabbit secondary antibodies (IgG) conjugated to Alexa Fluor 568 and Alexa Fluor 488.
.......
Point #1
DAS said, "You are correct that the output of the S[ ] is the cipher text. The
key is not involved except in making the S box itself. "
This is a weakness, in my opinion. Two weaknesses, really. My opinion is routinely disregarded by prominent cryptographers from around the world. ACF 12/31/2010
Point #2
DAS said, "Look I stated once you use random file as a key. A then use a long
password you never have to remember to create the keyenc.key
file. "
This is a weakness, in my opinion. Two weaknesses, really. My opinion is routinely disregarded by prominent cryptographers from around the world. Requiring a random key is a requirement not mentioned by any of the 15 AES candidate algorithms. In fact, if one had made that a requirement, that one candidate would have been disqualified. ACF 12/31/2010
Point #3
DAS said, "Take the cipher Rijndael I know you tested a short file you change
the key bit one bit at a time. And looked for a roughly 50 % change.
in output. of ones and zeroes. If someone entered another cipher
that was ten times fast than Rijndael. But suspose it fails your test
of the one bit key change. Would it be rejected on the spot? "
Yes. This basic requirement is known around the world.
Point #4
DAS said, "When you run scott19u and are encrypting you have to enter a password
it this point enter if your wish in hex the password or binary if you wish
this will be where I would do the bit flipping since this is really the
users interface to the cipher"
I ran it with the EP choice and the n choice, for no password and to use keyraw.key. I set that key as all zeros. Since the S-Box (substitution table) depends on the key, it is reasonable for a cryptanalyst to focus on that point of vulnerability, seeking to break the cipher. You can modify your program to fix all of these problems and weaknesses. Distributing your improved encryption software on the internet would be a brave thing to do, considering ITAR Category XIII(b). ACF
Point #5
Cryptographer DAS said, "The keyraw.key
file is not meant for small changes making big changes in the S table,
A small change in the keyraw.key only makes a small change in the
S table period."
Response from the cryptanalyst ACF:
When you say "not meant for" it is noted that your documentation did not describe that eccentric limitation. This is a weakness in the "key schedule". Other ciphers have complicated key schedules. See the AES key schedule as an example. ACF 12/31/2010
All tests of scott19u.exe used the EP and n options so the keyraw.key file is used. You got a problem with .dat?
