Request features

Been there so I stopped using it until it'll be resolved...

the main problem with storing the passwords that you use is the portable nature of Toucan. Say for example that I have two PC's both with a file in the My Documents folder called RevisionNotes.txt and I encrypt both of them with Toucan but using different passwords, how does Toucan know how to store the password as the two files have the same path? If it were to store the computer name for example, then what about files on your USB stick, it would be the right file but the computer name would be different. In short I can see no easy way of doing this, however one of the new features that I am looking at for 2.0 would be to keeps a list of previously used passwords (in hashed form) so at least the program could warn you if you had never used that password before, although it wouldn't know which password you had used, if you see what I mean.

As for double encrypting files this can't happen any longer in 1.2 (which should be released tonight) as it appends a file extension.

As for finer control of Secure, that is also coming in 2.0 with the new interface.

Some encryption schemes store a checksum or hash somewhere in the encrypted file, so they can check either the password or the result of the decryption. That way they can assure you that the file has been decrypted accurately. Problem is, it gives someone trying to hack into your file an easy way to know when they have succeeded. If you don't let them know (from the filename and extension) what kind of file it is, and don't store a checksum, they'd have to spend a bit of time after each password guess trying to figure out whether the file got decrypted to good data (meaning the password was correct) or to garbage (or doubly encrypted).

It's not so easy to tell a jpg file from an excel spreadsheet without using a hex editor or something, and that just makes the brute force attempt take that much longer. I think the word is "infeasible".

Storing a list of hashed passwords could similarly make the task a bit easier, since a brute force attempt would simply try against the hash list until it found one, then try it on the encrypted file. It wouldn't be trivial, but it might be just enough easier as to be "feasible". If the task can be automated, it might be possible to do the brute force against the list in a reasonable time, or to luck into the correct password and know immediately. Sometimes the programmer increases the time required by running many iterations of the hashing function when creating the hash list.

It's the balance between convenience and protection. If you are keeping your files from honest or busy people, then having the checksum or hash available may be a reasonable relaxation of security. Your data isn't any good to you if you can't access it.

If someone has physical access to your drive, there's not a huge amount you can do to prevent them from encrypting your files -- or reformatting your drive, for that matter. They could even bring their own encryption program to do it. Sometimes losing access to your data is worse than someone else having access to it. Adding a unique extension or copying the encrypted file to a recycle bin before a decryption attempt might be ways to help the real owner avoid doing it by accident with Toucan, without increasing the risk too much.

Keeping a non-encrypted backup version at home would be a reasonable precaution, of course.