jFileCrypt can encrypt your files fast and very secure with a password. It's written in Java 5 and runs under nearly every operating system. The encryption standards Blowfish, DES, 3DES, AES and RC4 are supported.
What's New
Version 0.3.0t:
removed support for zip archives
introduced a new archive type
added automatic hash computation and verification functionality
improved translation support
added a confirmation window when clicking stop
fixed bugs using RC4, DES, 3DES and AES encryption
implemented use of CBC (cipher-block chaining) mode instead od the unsafe ECB (electronic codebook) mode
added -g option to command line to start GUI using given defaults
added output of java version to command line
added functionality to overwrite files and to ask the user about it
bugfix: list algorithms in command line does not longer fail due to missing translation
Version 0.3.0t:
removed support for zip archives
introduced a new archive type
added automatic hash computation and verification functionality
improved translation support
added a confirmation window when clicking stop
fixed bugs using RC4, DES, 3DES and AES encryption
implemented use of CBC (cipher-block chaining) mode instead od the unsafe ECB (electronic codebook) more...
1) Blowfish's key length is variable from 4 to 56 bytes, however, Java's export restrictions only allow a maximum of 16 bytes. It's not 'Any length' as described in the 'Algorithm info' window.
2) ARC4's key length is variable from 1 to to 256 bytes, but again Java's export restrictions cripple this to a maximum of 16. It's also not 'Any length'.
3) The block ciphers only use ECB mode, and since a picture is worth a thousand words, I'll let the picture at the bottom of this section on Wikipedia explain why that's bad: http://en.wikipedia.org/wiki/Block_cipher_modes_of_operation#Electronic_codebook_.28ECB.29
4) RC4 is used in a more insecure way. There are no precautions taken against the Fluhrer, Mantin and Shamir attack.
5) The password input is used directly as a key, unless the password is greater than the key length, at which point it is hashed with SHA-1 and truncated to key length. Wouldn't it be better to just use truncated SHA-1 or SHA-256 in the first place? You might also want to use a salt.
6) There's no checking before decryption to see if the password entered was correct. I can understand the reason for this from a power user perspective, but Joe User is going to complain heavily to you when he decrypts his document with the wrong password and it comes out as garbage, but is still unaware of what went wrong.
sorry, i loaded up a German only version. I replaced the file, so please download again and you will get it in english. Other translations will come next time.
you need to install Java 5. jFileCrypt unfortunately only works under Java 5. You can install it about the Software Update assisstent.
If this doesn't fix your problem, download the plattform-indepent version from http://sourceforge.net/project/showfiles.php?group_id=156398. If then the problems still exists, mail me yannickheiber at users.sourceforge.net.
Please login or create a new MacUpdate Member account to use this feature
Watch Lists are available to MacUpdate Desktop Members Upgrade Now
Download and auto-install
using MacUpdate Desktop. Save
time moving folders and cleaning-up.
jFileCrypt can encrypt your files fast and very secure with a password. It's written in Java 5 and runs under nearly every operating system. The encryption standards Blowfish, DES, 3DES, AES and RC4 are supported.
+2
+2
1) Blowfish's key length is variable from 4 to 56 bytes, however, Java's export restrictions only allow a maximum of 16 bytes. It's not 'Any length' as described in the 'Algorithm info' window.
2) ARC4's key length is variable from 1 to to 256 bytes, but again Java's export restrictions cripple this to a maximum of 16. It's also not 'Any length'.
3) The block ciphers only use ECB mode, and since a picture is worth a thousand words, I'll let the picture at the bottom of this section on Wikipedia explain why that's bad: http://en.wikipedia.org/wiki/Block_cipher_modes_of_operation#Electronic_codebook_.28ECB.29
4) RC4 is used in a more insecure way. There are no precautions taken against the Fluhrer, Mantin and Shamir attack.
5) The password input is used directly as a key, unless the password is greater than the key length, at which point it is hashed with SHA-1 and truncated to key length. Wouldn't it be better to just use truncated SHA-1 or SHA-256 in the first place? You might also want to use a salt.
6) There's no checking before decryption to see if the password entered was correct. I can understand the reason for this from a power user perspective, but Joe User is going to complain heavily to you when he decrypts his document with the wrong password and it comes out as garbage, but is still unaware of what went wrong.
+67
If this doesn't fix your problem, download the plattform-indepent version from http://sourceforge.net/project/showfiles.php?group_id=156398. If then the problems still exists, mail me yannickheiber at users.sourceforge.net.
Have a nice day!
ybasket