Re: http://www.dataet.com/public/source/vsacmv20/

[DataETRsch@aol.com]

Igor,

In a message dated 97-05-17 01:04:54 EDT, you write:

<< Thank you VERY MUCH for releasing the source code. This shows that you are
 serious about your program and truly appreciate how important is the process
 of review as far as your credibility is concerned.
 
 I have downloaded your code and looked at it. Looks rather interesting
 (especially the part below). What I did not understand, however, is
 what is SetVal and how it works. Also, I was not clear how you set
 variables AE1, AE2, ..., AE10 and so on.
 
 As far as I understand, you use these variables to select the particular 
 encryption method. Do you normally select only one method on some random 
 basis or you use several passes?
 
 Also, some may be interested to look at this particular encryption
 method (I added some indentation and comments for readability). I believe
 that it is not particularly strong. >>

Hi. Thanks for taking a look at the source code. Actually, SetVal is just a
name used for many parameters of functions and procedures within VSACM. The
documentation of VSACM V2.0 describes what SetVal represents in each function
or procedure. Attached to this message is the help file of VSACM. As for the
AE1, AE2, etc. variables, they're set with the VSACMSetEnableTC1001,
VSACMSetEnableTC1002, etc. procedures. If you take a look at
VSACMProcessOperation function in LibUnit.pas and the Internal function in
IntUnit.pas, you'll notice how relatively uncomplex algorithm extensions are
combined to form a powerful algorithm. The procedure TC1001 (in StdUnit.pas)
you mentioned is basically a pseudo-random byte XORer. TC1001 is NEVER used
as the sole encryptor of a file. You'll also notice that, at a minimum,
single passes of TC1001, TC2005, TC1005, TC3001, TC3004, and TC3005 are used
to encrypt/decrypt a file. No, an algorithm extension is not chosen randomly.
Some of the procedures are "scramblers". Others are "incrementors". Others
are "avalanchers". Again, it is best to analyze VSACM as a whole in a
systematical (chronological) manner instead of analyzing each procedure of
function in each source code file one by one. By the way, what do you think
of the key hashing procedure (VSACMSetKey) and the memory deallocation and
destruction procedure (VSACMInitialize) and the masking tables in
IntUnit.pas? Did you find any "backdoors" or ways to hack a decryption date
or time lock applied to a file without applying the correct key? (There
aren't any). How about any flaws?

Also, for others who may be reading this, if you still think VSA2048 is still
a "flawed" or "crappy" or "sucky" or "snake-oiled" encryption algorithm, why
don't you PROVE it by cracking the file located at
http://www.dataet.com/public/source/vsacmv20/breakit.dat (if you are in the
U.S.)?!?! (All words, no action!!!) Well? The file was encrypted using a
120-bit VSA2048 key. The key isn't even 128 bits in length! I don't know
about you, but I would think VSA2048 is pretty good if not even one
cypherpunk out there can decrypt the message. As for my previous line about
the decryption contest being limited to the cypherpunks (@toad.com), I have
changed my mind. The contest is open to any person (in the United States). I
will post contest details to cypherpunks@toad.com again.

I appreciate the comments. Thanks.

Regards,

Jeremy Yu-Ramos
DataET Research