The Testing Area :: June Extensions

Quote

update: just found a bug in aespipe; created an .aes file that restored fine once, but then stopped restoring files if I tried it again (everything looked fine in the termimal window, but files never appeared on the disk).

Can't say I've ever seen that. Sounds like you are running out of space on root or the device?

Rather than unpacking in place, I suggest making a directory, make sure there is space, cd to that, then run the tar decryption there, so all the decrypted files unpack into that directory.

@Curaga:

Quote

IBcrypt is also a lot faster than aespipe, especially compared to AES with 50 000 iterations and older computers.

Read the aespipe readme. It's set to 100 by default. I'm probably the only person in the world that advocates setting bz2aespipe password hash iterations to 50,000 (or more) ;=) That script is only one of its applications, btw.

I wasn't recommending not using bcrypt, I'm not familiar enough with it. It may well be faster. Better? I doubt it +++. These progs do different things with different algorithms. aespipe is designed to encrypt streams, and can also encrypt entire filesystems with aes128 so they can be mounted with loop-aes. It can also use gpg-encrypted keys and provides a choice of hash algorithms.

I haven't compared speeds with bcrypt, but that's not all that helpful with different ciphers. I have in the past compared aespipe with gnupg running in a named pipe with the same ciphers on the same data, and aespipe is much faster than gnupg.

The thing with encryption often isn't the cipher or key length per se - it's usually the particular implementation or security issues on the particular system that provides the hole. For example, overwriting the data twice isn't necessarily secure - though it might just be on new high density media, on older drives it could perhaps be recovered. A paranoid Guttman wipe (35 times in a special sequence) is only of extra value on very old drives.

Better to use shred -u -n 20 or something and nuke the plaintext data, or, use wipe.dsl or similar. And don't use swap, or if you do, turn it off afterwards and shred the swap device, then make the swap again. But the experts would say never write plaintext to an unencrypted drive in the first place.

If you're advocating getting bcrypt into the base it may well be a good candidate since it's small.

BTW don't confuse DES with 3DES - they are quite different. DES is absolutely useless, yes. Last I heard 3DES was still(?) ok - for now.

Quote (WDef @ June 18 2007,16:34)

Quote

The problem occurred when I changed the name on a subdirectory after creating the .aes file. (to see if it would recreate the original when restoring--as it does with a regular .tar.gz file). It didn't. When I restored the subdirectory's orginal name, it still wouldn't work. No problems restoring the same archive in .tar.gz format, where original directories get recreated if they no longer exist. There's a few gigs of available space, but I guess there could be an inode problem or something..

I didn't spend a lot of time on it, and can try it again. (when I can't restore a backup file, I lose confidence quickly).

EDIT: I just tried aespipe out on my other laptop (where I am now) and it works fine. I think I had some inode problems before on the other computer. I'm not sure why the aes file didn't work while a regular .tar.gz did, but the problem is no doubt computer related (...second thought, it could also be ignorance related...).

OK so sounds like you had a problem with your filesystem.

jpeters

Quote

I couldn't get the windows version to work at all, however.

How did you try it? I have it installed on a USB stick with PortableApps so I can use it between OSes. I've had no trouble with either Linux or Windows versions. I've set it up in an appdir in rox desktop so I only have to drag files onto it and a terminal pops up and prompts me for pass phrases.

In Windows, you can either use a command line or just drag what you want to encrypt/decrypt over the icon and a terminal window pops up asking for your key. Make sure zlib.dll is in the same directory with bcrypt. The Windows version has something of a very serious issue -- it doesn't hide your pass phrase when you type it (something that's mentioned on their website but bears repeating because it's kind of offputting to see the phrase instead of a static cursor or a line of asterisks). I posted some USB/portability entries and pages a month ago including one about bcrypt:
http://lucky13.blogsavy.com/portable-encryption-with-bcrypt/

As far as "superiority" goes, you get what you pay for. I don't think bcrypt is enterprise grade, particularly compared to other applications. At the same time, any form of encryption or any application is only going to be as secure as other steps (like choice of pass phrases) taken during encryption. It's a lot faster than GPG, but that's because GPG has a lot more features available -- and those features make GPG a better option for sharing signed/encrypted data with others. I think bcrypt can be a useful tool if used properly.

WDef

Quote

I wasn't recommending not using bcrypt, I'm not familiar enough with it.

You're correct that aes-pipe is a lot more flexible. So is GPG. There's nothing inherently wrong with bcrypt. It's small and gets the job done. It lacks a lot of features aes-pipe and GPG and truecrypt and ncrypt have. All it does is encrypt/decrypt, and it has a couple options (print to stdout/not, compress/not, overwrite original/not, overwrite x times). I think it's suitable for DSL because it's so small and it performs its tasks pretty quickly compared to other encryption tools. I like it because it's flexible enough with the same command to encrypt and decrypt (no -e and -d) that I was able to set BFE as a MIME-type in rox and set a run action for it (same could probably be done in emelfm).

You're also correct about the need to distinguish between 3des (EDE) and DES. They're not the same. Blowfish is faster than 3des, but it's not inherently more secure (3des is estimated to be between 112-168 bit -- EDE is between 2x56 and 3x56 -- versus old DES at 56 bit and blowfish at 128 bit).

Next Page...
original here.