Jump to content

Decryption Problem with dsCrypt


HoppaLong

Recommended Posts

At first, I blamed myself for this problem.  Something is wrong, but I am not entering incorrect
passwords.

I built a script around my favorite encryption app, dsCrypt.  The script can enter a complex
password into dsCrypt directly, or open a text editor and "Send Keys" so the password is
completely visible, waitng to be copied and pasted.  I have never had a single problem with
this script.

The problem occurs when I manually type a password.  If I encrypt a file by entering the
characters manually, I cannot decrypt the file when I move to a different version of Windows.
If my script enters the same password, dsCrypt has no problems decrypting the file with
almost any version of Windows.  To say the least, this is extremely strange!

Just to make sure I wasn't losing my mind, I created several "placeholder" text files with very
simple passwords like "123456" or "cat-dog."  Sure enough, I had the same problem if I manually
typed these passwords.  If I edited my script to enter these silly passwords, there were no
problems with any version of Windows I booted.

This weird behavior seems impossible!  How could this be happening?  If there is no solution,
I must switch to another encryption app.  I really don't want to do that.

Link to comment
Share on other sites


jaclaz, if I used a scripting language created by my dog it wouldn't matter in this case.  This script
allows me to enter insanely complex passwords many times each day without going crazy.  I can
certainly enter these lengthy password manually.  If I was forced to do that, I would abandon
encryption altogether.

The point is, this script is doing its job perfectly.  How can I debug something that has no detectable
problems?  dsCrypt has the problem, right?  Entering a password manually, as opposed to simulated
keystrokes from a script is causing some glitch in dsCrypt's coding.  dsCrypt and my script are
sympatico.

Finally, this script has hidden traps or backdoors.  If you open the script in a text editor it looks
very mundane.  To protect the passwords, certain mouse and keystroke operations must be performed
before the code will execute.  MSFN has some of the brightest people on the web.  My "big secret"
would be quickly decoded.  I hope you can understand why I can't do that!

The truth is, I hate encrypting files.  My business partners threatened to shoot me if I didn't start
encrypting sensitive documents.  (They were joking.  Don't get upset!)   I guess my only option
is to search for a dsCrypt replacement.

Link to comment
Share on other sites

Yep, I understand your desire to not reveal your script contents, but this (respectable) choice makes it impossible for anyone to help/assist you, so your post can only be a (again perfectly understandable) form of ranting.

To me it seems evident (but maybe it is just me :unsure:) from what you report that *somehow* what actually "arrives" to decrypt when sent "manually" is different from what "arrives" to it when sent through your script.

What I would suspect would be that (still *somehow*) what your script is passing is different because it is (say) in a different encoding or format (think - as an example - to ASCII, Unicode or UTF) and I would use a hex editor to verify (after having dumped both the "manual" and "through script" password to file) if such a difference exists.

And same goes if the procedure includes a clipboard copy/paste.

At least you could describe the procedure and enumerate WHICH versions of Windows create the issue.

To give you an example of what can happen (not necessarily your current issue, of course):
http://bavih.blogspot.it/2008/07/notepad-bug.html

jaclaz


 

Link to comment
Share on other sites

Your situation is not unique, the one where you have a problem with your code but cannot post it. So what you need to is replicate the portion that is failing. You do this in preparation to be posted online. A cleaned version of the code (as likely the failing portion is not a unique discovery you have made) that will exhibit the problems you are seeing, but without having all the extra stuff your program does. (I can interject that your program should be built like this already)

Often when I have to do this, 90% of the time I will find the problem on my own. Or I will hit the issue where the PoC code works but the original doesn't. Having a working vs non-working set is a great thing. But if after this exercise, your PoC code still does not work properly, you can post it online without worry of sharing sensitive information.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...