Hi, everyone,
I'm looking for the test vectors of TDES(Triple Data Encryption
Standard). I have gone through the website of NIST and only to find
such link below
http://csrc.nist.gov/groups/STM/cavp/documents/des/tripledes-vectors.zip
which provides some sample test vectors but far from full size for a
Monte Carlo Test.
I spent much time on searching the test vectors on the internet
through Google, maybe for my own fault, I still can't find full test
vectors for TDES Monte Carlo Test use, especially including CBC mode.
So, I turn to here for help, and wish that it may not be a fool
question for everybody.
Thank you for your kindness, let me show my gratitude in
advance.

You can offer your help by posting the link or write letter to
me , my e-mail is : tomzhi27@gmail.com

On the question of cryptographic strength in this series, I have
already posted on several aspects:

1) Cryptographic Strength can be classified and roughly rated.

2) The base used makes a difference as there are better choices.

3) Pseudorandom Character Generators as needed can be used directly in
the base selected for a specific algorithm.

4) The next area is to deal with homophones and/or problematic
encryption which can be used to increase strength. Rather then having
one ciphertext for one plaintext under one key, optional ciphertexts
would all decrypt to the same result.

A simple choice scheme would be a caesar where one of several outputs
is used in a rather elementary way. Note that plaintext and
ciphertext lengths with it are the same. There are many other examples
that conserve fixed length. Other classic and neoclassic systems
might use a 2X or 3X increase in size from Pt to Ct which can be used
to allow several versions of Ct but are considered rather wasteful of
bandwidth. Still there is much to learn in their study.

There are certain compression techniques which might affect absolute
length.

Folks,

Thanks for reading this post. I have an issue where we are using
RealVNC to do some remote management of some computers out in the
field. We are using a DLL (vncauth.dll wirtten in C++) and use it
from C# code to encrypt the vnc password before connecting.
vncauth.dll uses Richard Outerbridge d3des (D3DES (V5.09)) to the
encryption of the password, then we change the encrypted password into
hex before placing it in the config file of RealVNC. Clicking the
RealVNC config file launches RealVNC and we are connected. So far so
good...

The issue is that out of ~12K passwords that we have, about 250 do not
work (garbage output) when using Richard Outerbridge des encryption. I
couldn't find an "updated" version online. The link to the source
files are:

vncauth.c
http://www.codase.com/search/display?file=L2dlbnRvbzIvdmFyL3RtcC9yZXBvcy9jb2Rhc2...

d3des.h
http://www.codase.com/search/display?file=L2dlbnRvbzIvdmFyL3RtcC9yZXBvcy9jb2Rhc2...

Take a simple key then repeatedly XOR it the length of a long text
file. This kind of encryption is what most beginners come up with as
a safe encryption however it is one of the easiest to brake if
underlying file plaintext English.
The question is does doing a BWT or UNBWT before this encryption
offer any extra protection assuming the attacker has only access to
what you did and the results. I am only looking at binary version of
BWTS and UNBWTS since that would be better but one could use the
ordinary 256 symbol BWTS.
The BWTS of long text file would create very long strings of zeros
and ones. This would cause the repeated key to likely be exposed in
the sequences of zeros as unchanged and inverted in a long series of
ones. Without to much difficulty one could test each sequence of
bits in ciphertext for either the inverted key or the actual key. If
none leads to correct key one could even test for the underlying
binary bwts to have ben 000...111.. or the opposite. The point is
that doing a BWTS as a stand alone for the encryption pass would
weaken this kind of encryption and would make it easier to bust than
doing nothing.
What about doing a binay UNBWTS on text before an encryption pass. ...