You are here

Security - Cannot decrypt... PLZ HELP ME!!!

29 posts / 0 new
Last post
Compyka
Offline
Last seen: 16 years 2 months ago
Joined: 2008-01-17 16:40
Security - Cannot decrypt... PLZ HELP ME!!!

Hello!

I have encrypted a folder on my USB drive. I tried to decrypt it, but I typed the password differently. As soon as I realised it, stopped the action, but it "decrypted" 4 pictures already. I retyped the pw. in the correct way, and tried to decrypt again. It only dc-ed only the last 3 files which remained and the others not anymore. Please help me! I really need those files Cry

Thank You Very Much

Steve Lamerton
Steve Lamerton's picture
Offline
Last seen: 10 years 6 months ago
Developer
Joined: 2005-12-10 15:22
Firstly

don't do anything, I'll post some things to try later on today. Also what type of encryption were you using?

Steve Lamerton
Steve Lamerton's picture
Offline
Last seen: 10 years 6 months ago
Developer
Joined: 2005-12-10 15:22
Right then

before you do anything, take a copy of the files that are still encrypted and work on the copy.

If I have this right you should be able to encrypt the files with the wrong password that you used and the decrypt them with the correct password and you should have your files back.

Tim Clark
Tim Clark's picture
Offline
Last seen: 12 years 11 months ago
Joined: 2006-06-18 13:55
small point

Steve,

Just thought I'd point out you can edit your own post. You don't need to "reply" to yourself, and, as a moderator, you can edit your own post even if someone has already replied.

Tim

Things have got to get better, they can't get worse, or can they?

Simeon
Simeon's picture
Offline
Last seen: 9 years 5 months ago
DeveloperTranslator
Joined: 2006-09-25 15:15
thats

cool!
I reckon lots o people want that! Smile

"What about Love?" - "Overrated. Biochemically no different than eating large quantities of chocolate." - Al Pacino in The Devils Advocate

Steve Lamerton
Steve Lamerton's picture
Offline
Last seen: 10 years 6 months ago
Developer
Joined: 2005-12-10 15:22
Yep

but then it doesn't show up as a new post in tracker.

Ryan McCue
Ryan McCue's picture
Offline
Last seen: 14 years 6 months ago
Joined: 2006-01-06 21:27
Hehe.

Bumper Blum

"If you're not part of the solution, you're part of the precipitate."

John T. Haller
John T. Haller's picture
Offline
Last seen: 5 hours 34 min ago
AdminDeveloperModeratorTranslator
Joined: 2005-11-28 22:21
Encryption Issues

I thought that the bug where it would incorrectly decrypt (and destroy) a file when you enter the wrong password was fixed in the current release.

Sometimes, the impossible can become possible, if you're awesome!

Steve Lamerton
Steve Lamerton's picture
Offline
Last seen: 10 years 6 months ago
Developer
Joined: 2005-12-10 15:22
I

wasn't aware that something was supposed to change. At the moment Toucan encrypts the file and append an extension. As it's being decrypted the file extension is removed. Are you saying that you would like it to decrypt to a separate file, leaving the encryped file intact? As for storing passwords to check them agains files, there is no way that I would be happy storing them to file, although I guess they could be hashed first.

John T. Haller
John T. Haller's picture
Offline
Last seen: 5 hours 34 min ago
AdminDeveloperModeratorTranslator
Joined: 2005-11-28 22:21
Not Storing

I don't mean storing them. I mean that the decryption should simply fail if the password is wrong. Having a tool destroy files if a user types a password in wrong is about as far from user friendly as possible. Or am I misunderstanding the issue?

Sometimes, the impossible can become possible, if you're awesome!

powerjuce
powerjuce's picture
Offline
Last seen: 13 years 1 month ago
Developer
Joined: 2007-09-20 21:34
not meant to be for average users...

Toucan is a custom built portable app for advanced users to synchronise, backup and encrypt their data, wherever they are.

so they should understand the risks

Please search before posting. ~Thanks

Steve Lamerton
Steve Lamerton's picture
Offline
Last seen: 10 years 6 months ago
Developer
Joined: 2005-12-10 15:22
I

see what you are saying, but how should Toucan 'know' if you are using the wrong password? Also looking at the ccrypt page, this is simply the way that it works, there is no way to stop it overwriting the file on decryption, which it why it asks for the password twice, as does Toucan.

John T. Haller
John T. Haller's picture
Offline
Last seen: 5 hours 34 min ago
AdminDeveloperModeratorTranslator
Joined: 2005-11-28 22:21
Tool Itself

But doesn't the tool itself fail if it tries to decrypt a file with an incorrect password?

Sometimes, the impossible can become possible, if you're awesome!

Shawn Faucher
Shawn Faucher's picture
Offline
Last seen: 14 years 7 months ago
Developer
Joined: 2007-10-23 22:14
RE; Tool Itself

If it works the way I think it does, there is no failure.. it simply passes the file through the algorithm using the specified key (password). It has no way of knowing what comes out the other end is garbage because the wrong key was used, just like it has no way of knowing if it's good if the right key is used.

To get around this you would have to include a hash or something of that sort and do a comparison after decryption. This would mean you'd also have to decrypt to separate files..

formerly rayven01

Steve Lamerton
Steve Lamerton's picture
Offline
Last seen: 10 years 6 months ago
Developer
Joined: 2005-12-10 15:22
Nope

if there was a way for it to do that then a tool could easily be written to do the same thing and crack the password. Looking at the site I think that the data is lost as ccrypt uses a random initialisation vector, so short of recreating those exact conditions re-encryption to get the files back would be difficult, however I might write a little program to brute force that vector, so there is still a chance, give me a couple of days and I'll see what I can do.

Shawn Faucher
Shawn Faucher's picture
Offline
Last seen: 14 years 7 months ago
Developer
Joined: 2007-10-23 22:14
RE: Nope

I am far from a security expert, but couldn't you do the following:

  • Get a checksum of the file before encryption
  • Prepend the checksum to the file
  • Encrypt the result with the password.

Then on decryption side..

  • Decrypt the whole thing to another file using the given password
  • Split the checksum from the result and compare
  • Replace the nondecrypted file with the result and destroy the checksum if they match
  • Destroy the result and checksum if they don't match and warn of failure

formerly rayven01

Tim Clark
Tim Clark's picture
Offline
Last seen: 12 years 11 months ago
Joined: 2006-06-18 13:55
Self Destruct

Looks like it has a "Self Destruct Mechanism" built in.
You have one try to decrypt, if you're wrong, data is destroyed !!

Talk about security Shock
Tim

Things have got to get better, they can't get worse, or can they?

selinger
Offline
Last seen: 16 years 2 months ago
Joined: 2008-01-18 17:43
That's not how it works

Hi all,

first, here are some pertinent facts about ccrypt. Most of this is explained in some detail on its man page.

  • Unlike what Steve wrote, ccrypt refuses to decrypt data with a key that does not seem to match. (I agree with John and Tim that this is a useful feature even for "advanced" users, who are just as likely to mistype a password as normal users).
  • A technical detail: the password matching feature is not implemented by storing the password (that would be silly), nor by computing a hash of the entire file. Instead, a 32-bit magic number is attached to the *beginning* of the file before encryption. When this magic number is missing upon decryption, then the key was wrong and the file is not decrypted. Because this is detected at the beginning, the decryption can simply be aborted and it is not necessary to first decrypt everything into a separate file.
  • the -m option can be used to force decryption with a non-matching password, but in this case ccrypt refuses to overwrite the file and will only decrypt to stdout.
  • There is a small probability that ccrypt will accidentally allow a file to be decrypted with a mistyped password. This probability is 2^(-32), or about one in 4 billion.
  • even if ccrypt accidentally decrypts a file with the wrong password (probability 2^(-32)), it would still refuse to do so on the next file. The probability that a non-matching password could be used on four consecutive files is 2^(-128). This is astronomically small, much much smaller for example than the probability of a random hardware malfunction.

So, as much as I hate to say it: the problem reported by the original poster should not technically have occurred. There must be some other explanation.

One explanation would be if Toucan passed the "-m" option to ccrypt; this would be an extremely bad idea, like driving without a seatbelt. However, I checked the Toucan 1.2 sources where the call to ccrypt appears in a file called secure-file.h, line 71. There are some things I don't like about this code (passing the password on the command line is not safe, and the double shell escapes make you wonder what happens if the password or filename contains quotes, backslashes, dollar signs, etc). However, the code does not use the "-m" option and therefore no file should have been destroyed.

I realize that "it cannot have happened" is not a very satisfying answer to a problem that in fact happened. But I would be very curious to receive more information about this problem, such as whether it can be reproduced. Perhaps the user didn't really mistype the password, but only thought he had done so? Perhaps the files that are assumed destroyed were in fact decrypted correctly?

-- Peter

Shawn Faucher
Shawn Faucher's picture
Offline
Last seen: 14 years 7 months ago
Developer
Joined: 2007-10-23 22:14
RE: That's not how it works

So my theory on securing the file wasn't far off.. the magic number is computed from the file somehow even if it's not a full checksum. Not bad for a security noob. Wink Makes sense that they do this automatically.

formerly rayven01

selinger
Offline
Last seen: 16 years 2 months ago
Joined: 2008-01-18 17:43
RE: That's not how it works

rayven01: you are sort-of right. The magic number is not actually computed from the file; it is the constant string "c051". This is padded with 28 bytes of seed, and the resulting 32 bytes are encrypted with one round of encryption and used as the initialization vector. When decrypting, we simply check whether the decrypted first block starts with "c051" or not. Since the magic number is encrypted along with the rest of the data, there's no way to tell whether it is present or not unless you know the key in the first place.

Steve: the password matching features does not give rise to a tool for cracking the password. One may certainly attempt a brute-force attack by trying all 2^256 possible passwords. However, the presence of the magic number does not speed up this process: even without it, one can usually tell from the first block of plaintext whether a given key matches or not (for example, every JPEG file contains the letters "JFIF" within the first 10 bytes). There is some more information on this in the ccrypt FAQ.

Steve Lamerton
Steve Lamerton's picture
Offline
Last seen: 10 years 6 months ago
Developer
Joined: 2005-12-10 15:22
Hey

Peter. I reread the main page again after my post and realised my mistake, thanks for the clarification. As for your concern with passing the passwords over the commandline, I was going to use the library directly to remove that issuein the next version.

Compyka
Offline
Last seen: 16 years 2 months ago
Joined: 2008-01-17 16:40
Encryption

I used Toucan 1.1.2. I could not select the type of the encryption, but in the folders I've found an executable, called "burp" maybe that was it. I read among the posts, that it adds a string to the beginning of the files, or was it ccrypt? :S

Steve Lamerton
Steve Lamerton's picture
Offline
Last seen: 10 years 6 months ago
Developer
Joined: 2005-12-10 15:22
Unfortunately

this was a known issue in the 1.1 series, which is why the standard encryption type was changed in 1.2. Because of this I believe your data is lost.

Jasper
Offline
Last seen: 16 years 1 month ago
Joined: 2008-02-07 09:40
Possible solution

I believe it's not. (okey maybe one of the files is)

What you should do is use the very first version, encrypt the files again with the incorrect password - then decrypt it again with the correct password. I can't promise it'll work, but it seems logical it does.

Delinger
Offline
Last seen: 16 years 1 day ago
Joined: 2008-03-30 23:48
Any solution possible?

My problem is similar, any possible way to fix the problem and take back the file?¿

LOGAN-Portable
LOGAN-Portable's picture
Offline
Last seen: 11 years 2 months ago
Developer
Joined: 2007-09-11 12:24
Hmm would a dycrypted file

Hmm would a dycrypted file with wrong password, be able to get restored when re-encrypting with the wrong password and then finally decrypting with the correct one?

Is this an old issue that has been fixed in the time of the original post?

Hmm always make backups comes to mind..

Steve Lamerton
Steve Lamerton's picture
Offline
Last seen: 10 years 6 months ago
Developer
Joined: 2005-12-10 15:22
Yes

this issue was fixed by defaulting Toucan to a different encryption method in version 1.2 and a warning has been on the Toucan homepage for some time now about using the Blowfish method, so to be honest I have very little sympathy. To finally kill the issue Blowfish will be decrypt only in version 2.

LOGAN-Portable
LOGAN-Portable's picture
Offline
Last seen: 11 years 2 months ago
Developer
Joined: 2007-09-11 12:24
No Backward compatibility?

No Backward compatibility?

Steve Lamerton
Steve Lamerton's picture
Offline
Last seen: 10 years 6 months ago
Developer
Joined: 2005-12-10 15:22
Decrypt

only, if you have any files you will be able to get them, but you will have to use the new method for any new files to be encrypted.

Log in or register to post comments