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