June Extensions

Forum: The Testing Area
Topic: June Extensions
started by: roberts

Posted by roberts on June 12 2007,01:17

Thanks to J S for:
elinks.uci
curl.uci
tmsnc.tar.gz

Thanks to jpeters for:
sjeng.dsl

Thanks to curaga for:
bcrypt.tar.gz

Posted by roberts on June 12 2007,17:35

Thanks to J S for an update to:
rtorrent-0.7.uci

Posted by jpeters on June 13 2007,06:54

I just checked out bcrypt; pretty amazing. It encrypted a folder of 14 books in about 5 seconds, and restored in about a second.

Update: worked great unencrypting an encryped file passed to another linux computer with bcrypt installed (i.e., password goes with the file). I couldn't get the windows version to work at all, however.
Wish it had a switch for encrypting subdirectories, but ./*/* works.

Posted by curaga on June 13 2007,10:39

Glad you like it ;)

Posted by WDef on June 15 2007,21:50

Quote

.
Wish it had a switch for encrypting subdirectories

If you want to put whole directory trees into encrypted archives, you could try aespipe.dsl (eg):

Code Sample

tar -cvf /pathto/output.aes --use-compress-program=bz2aespipe somedirectorytree

And to decrypt:

Code Sample

tar -xvf /pathto/output.aes --use-comprress-program=bz2aespipe

It has a variety pf choices of hashes and ciphers -- see the top of the bz2aespipe script to set these.

It's by the author of loop-aes and is very strong, particularly if you increase the number of hash iterations at the top of bz2aespipe to, say, 50,000 times ;=)

Posted by jpeters on June 16 2007,06:26

Quote (WDef @ June 15 2007,17:50)

If you want to put whole directory trees into encrypted archives, you could try aespipe.dsl (eg):

Just tried that out, thanks! I'll start using it for my complete backups.
More frequently, however, I'll want to pull some file saved onto an external server for use on any of several computers. Bcrypt works nicely for that. (aespipe restores an archive to orginal path).

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).

Posted by curaga on June 16 2007,07:50

Bcrypt is also a lot faster than aespipe, especially compared to AES with 50 000 iterations and older computers..
Also smaller (17k - 80k) if it will get into DSL some time..

Posted by roberts on June 16 2007,15:17

DSL currently has tripleDES and uses it in the webdata program (backup to ftp) as well as the encrypted backup via the 'protect' boot option. How does bcrypt compare considering old(er) computers?

Posted by curaga on June 16 2007,15:21

Blowfish is a lot stronger than tripleDES..
I haven't tried tripleDES, but bcrypt was quite fast in my tests after compilation.

According to Wikipedia:

Quote

-DES key was originally 128-bit, but NSA 'persuaded' it to 56 bits, so it could be broken
-NSA could break DES quickly already in the 70's
-DES has been cracked in less than 24 hours
-Blowfish is one of the fastest block ciphers in widespread use, except when changing keys.
-In some implementations, Blowfish has a relatively large memory footprint of just over 4 kilobytes of RAM. This is not a problem even for older smaller desktop and laptop computers, but it does prevent use in the smallest embedded systems such as early smartcards.
-Blowfish is not subject to any patents and is therefore freely available for anyone to use.

To further increase bcrypt's performance, compression and secure overwriting of original files can be turned off at use time.

Sorry, this does not answer the comparison. I cannot do that now.. Anyone?

Edit:
I found this comparison:
< http://www.schneier.com/blowfish-speed.html >
From it, on a Pentium Blowfish uses 18 clock cycles/byte encrypted when DES uses 45 and tripleDES 108. So speed gain is clear...

Posted by jpeters on June 17 2007,02:36

Using bcrypt to encrypt a 13M tar.gz file (basically my archived hard drive partition) cut down on the file's size slightly and took about 3 seconds.

Here's my cute little script for a backup file using bcrypt. A "MyFiles" directory on hda3 has a lot of subdirectories where I keep all my files, so I run the script from there:

1 #!/bin/bash
2 rm ./myfiles.tar.gz* #old backup file
3 find . > ./files.txt
4 tar cvf ./myfiles.tar --no-recursion --numeric-owner -T ./files.txt
5 gzip -9 ./myfiles.tar
6 cp ./myfiles.tar.gz ./myfiles.dsl
7 sudo ./declobber ./myfiles.dsl # remove open directories
8 cp -u $HOME/myfiles/myfiles_noclobber.dsl ./myfiles.tar.gz
9 rm ./myfiles.dsl
10 sudo rm -R $HOME/myfiles
11 bcrypt ./myfiles.tar.gz

This creates a "myfiles.tar.gz.bfe" file in my MyFiles directory. I'm not sure it's necessary to remove open directories using the declobber script, but what the heck. To restore I cd to the MyFiles directory and run the restore script.

1 #!/bin/bash
2 bcrypt ./myfiles.tar.gz.bfe
3 tar -zxvf ./myfiles.tar.gz

This is all done in seconds. The longest procedure is typing in the password.

Posted by WDef on June 18 2007,20:34

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.

Posted by jpeters on June 19 2007,02:06

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...).

Posted by WDef on June 19 2007,10:04

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

Posted by lucky13 on June 20 2007,17:23

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.

Posted by lucky13 on June 20 2007,18:04

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).

Posted by jpeters on June 21 2007,07:17

Quote (lucky13 @ June 20 2007,13:23)

I downloaded version 4.1.1 with libraries to an XP. It worked encrypting new files, but wouldn't decrypt files brought over from my linux machine. I haven't tried the older version.

EDIT: Which version are you using with PortableApps?

Posted by lucky13 on June 21 2007,10:09

Versions: bcrypt (recent) is 1.1, zlib.dll 1.1.4 (was included in the Win32 binary from the official bcrypt page). I have brypt installed both as a PortableApp and on my XP box. Both work flawlessly and seamlessly with all files from Linux and BSD.

Posted by curaga on June 21 2007,12:29

lucky: Bcrypt uses 448-bit key, the strongest Blowfish supports..

Posted by jpeters on June 21 2007,14:53

Quote (lucky13 @ June 21 2007,06:09)

Ah...that explains it. Version 1.1 is from 2002. The latest is 4.1.1 EDIT: 1.1 works!
< http://www.encryptsolutions.com/english/download/windows.html >

Posted by WDef on June 21 2007,14:58

Quote

You're correct ... you're also correct ..

I know I'm correct :=) (Just kidding! I occasionally do put my foot in it ... not this time)

Seriously, getting into a discussion abut the quality of an encryption app is very difficult for non-experts, which is probably most of us here (certainly me).

Even the experts and so-called "experts" get it wrong sometimes, and there's quite a lot of politics involved. It can be quite hard to get definitive opinions. About the only thing everyone seems to agree on is that gnupg/pgp is the standard.

That, and that users focus too much on ciphers and key lengths and not enough on the implementation and system and what happens to keys and plaintext, including, as lucky13 says, using a decent password.

I was horrifed once to read an article in Linux Journal a few years ago by a so-called expert who laid out a scheme for encrypting the root filesystem on one's laptop using dmcrypt and a single-line unencrypted key on the usbstick. If the usbstick gets into the attacker's hands, then that scheme is useless. A really bad, uninformed article.

About the best a non-expert can do is to google and look for criticisms of the particular prog or ways to use it better.

An instructive example is to follow the historical email list war between the dmcrypt/cryptsetupLUKS folk and loop-aes. Mucho nastiness all round, but to my mind loop-aes came out as the clear winner because Jari Ruusu, the loop-aes developer, fired off a range of serious criticisms of the implementation of dmcrypt (and cryptoloop and truecrypt) that all turned out to be correct. But for a while, the dmcrypt developers, who were way behind loop-aes in terms of their development status (I think still are) and I think rather defensive, denied it all with FUD, said loop-aes was actually spreading FUD, and that the weakness described was not significant. But in encryption, there's really no such things as an insignificant weakness per se, that's only something that makes sense in the context of a threat model. Anyway they eventually moved to address some of Jari's criticisms. Truecrypt acted much faster - in fact they responded to a similar criticism very fast indeed. This is a bit of simplification of the whole story,otherwise I'd be typing here forever.

But you'll find people who'll say all this is back to front :=)

Posted by roberts on June 21 2007,22:28

I have posted more extensions...

Thanks to WDef for:
netpipes.dsl
aespipe.dsl
loopaes-3.1f-2.4.31_x86.dsl
loopaes-3.1d-2.4.26_x86.dsl
gdb.dsl

Thanks to Juanito for:
syslinux.uci
syslinux_mssys.tar.gz

Thanks to J.S. for an update to:
elinks.uci

Please read the info files for instructions.

Posted by lucky13 on June 21 2007,23:08

curaga

Quote

Bcrypt uses 448-bit key, the strongest Blowfish supports..

I was generalizing, and the default for blowfish is 128-bit. I like bcrypt (especially on USB between Linux and Windows) and am glad it's in the latest RC. Good job!

jpeters

Quote

EDIT: 1.1 works!

Seeeeeeeee...

WDef

Quote

About the best a non-expert can do is to google and look for criticisms of the particular prog or ways to use it better.

Between DSL's size constraints, speed, and ease of use, my vote is for bcrypt. The fact that it plays well between different operating systems is a very big plus, too. Users who desire additional features or need more secure encryption are most likely going to have their own ideas and can extend however they see fit.

Posted by WDef on June 22 2007,00:04

Quote

my vote is for bcrypt

I didn't think I was voting against it, was I?

Ping: Robert
That's gdb.dsl, as in GNU debugger

Posted by roberts on June 22 2007,00:22

Quote (WDef @ June 21 2007,17:04)

Ping: Robert
That's gdb.dsl, as in GNU debugger

Thanks. Corrected post.

Posted by lucky13 on June 22 2007,00:29

Quote

I didn't think I was voting against it, was I?

I don't even know if you're voting or not. I speak only for myself.

Posted by curaga on June 22 2007,10:32

@Roberts, check the first post too..

bcrypt.tar.gz not .dsl

Posted by roberts on June 22 2007,14:47

Quote (curaga @ June 22 2007,03:32)

@Roberts, check the first post too..

bcrypt.tar.gz not .dsl

Thanks, corrected both, your handle and extension name.
I guess my stress is showing. Too many pots on the stove!

Posted by jpeters on June 23 2007,08:15

While correcting typos: Looks like the info file for Alsa.unc needs correcting? It's "sudo /etc/init.d/alsa-autoconfig" (not alsa-config) ...at least on my copy. Thanks

Posted by roberts on June 23 2007,15:06

Quote

alsa-autoconfig

fixed!

Posted by jpeters on June 24 2007,15:11

Almost.....there's another reference to alsa-config in the line above that corrected.

Posted by roberts on June 28 2007,05:42

More extensions now posted:

Thanks to Curaga for:
busyserver.tar.gz

Thanks to WDef for:
loopaes-3.1f-2.4.31_x86.dsl
loopaes-3.1f-2.4.26knpx_x86.dsl
gpgpatched.dsl

Thanks to J.S. for:
python2.5.uci

Download from the testing area.
Be sure to read the info file.

Posted by stupid_idiot on June 29 2007,09:00

I would like to split 'amule-gtk1.uci' into 2 parts:
1. amule.uci (amule, alc, alcc, ed2k, wxcas) - about 850K
2. amule-utils.uci (amule daemon, amule command-line client, amule remote gui) - about 2M
3. The 2 pkgs above depend on separate 'libwxgtk1.dsl' which is ready now. Also preparing more wxgtk1 apps, namely 'xchm' and 'wxdfast'.

Or should I use 'amule-gtk1.uci' and 'amule-gtk1-utils.uci'?

jls_legalize, you already have a package called 'amule-gtk2-2.1.3-ver2.dsl', so I thought I had better ask here first before changing the name. Another reason is, I think it is better to consult developers first.

Thanks everybody.

Posted by mikshaw on June 29 2007,12:29

stupid_idiot: The one thing that sounds odd about that plan is the fact that you want to make *.uci packages that depend on a *.dsl package. One of the main points about using UCIs is that they do not require the filesystem to be opened any further to writing, as *.dsl extensions do. By requiring the *.dsl, you remove this important feature of uci packages.

Posted by stupid_idiot on June 29 2007,23:43

Yes, you are right. The size of libwxgtk1 seems more suitable for uci/unc:
4904 /usr/local/lib/libwx_gtk-2.6.so.0

Reason for choosing .dsl was because I'd like to have it in a standard libdir (/usr/local/lib) and for simplicity. uci is okay as well by placing a symlink in /usr/local/lib to the file in /opt/libwxgtk1. But since uci should not have files outside /opt I think a unc is more suitable. What do you think?

p.s. If it is not difficult to make a unc, could anyone please post a short description of the process? Thank you very much.

Posted by ^thehatsrule^ on June 30 2007,01:08

stupid_idiot: you can set LD_LIBRARY_PATH, using a wrapper script. �Since it's pretty small, you may as well include it in amule.uci (which I assume amule-utils will be dependent on)

Posted by Juanito on June 30 2007,04:41

Quote

p.s. If it is not difficult to make a unc, could anyone please post a short description of the process?

1. Make dsl extension, put in /home/dsl
2. declobber.sh myextension.dsl
2. dsl2unc.sh myextension.dsl [the declobbered one, not the original]

Posted by stupid_idiot on June 30 2007,06:25

Thanks Juanito.

Posted by mikshaw on June 30 2007,16:04

Quote

But since uci should not have files outside /opt I think a unc is more suitable.

Again, I think uci is a better alternative for creating library packages that will be used with other uci packages. With unc you are forcing the use of unionfs. If the applications that depended on it were also unc that would make enough sense, but it doesn't make sense (to me, anyway) to have unionfs enabled for a single package when the only reason that package exists is to run uci packages that don't require unionfs.

As ^thehatsrule^ said, you don't have to be too concerned about standard lib directories with uci/tar.gz packages when you can use a wrapper script as the initial executable file.

Posted by stupid_idiot on June 30 2007,17:19

I agree. It will be 'libwxgtk1.uci' then. Thank you mikshaw for your advice. I will need a few days to test all the wxgtk1 apps first.

Posted by curaga on July 01 2007,06:00

What will happen if Audacity 1.2.4.uci is loaded too? As it needs wxgtk 2.4 and doesn't work with 2.6..

Posted by mikshaw on July 01 2007,14:49

There should be no conflict unless the user (for unknown reason?) decides to add both lib directories to the library path from a startup or login script. Unless that happens, the lib provided with Audacity affects only the audacity package and any child processes of Audacity.

stupid_idiot: If you still have the time/desire, would you consider keeping the includes with the package, or submitting them as a separate dev package? When this library is available in the repository, I will see about making it a dependency for the next Audacity package, which would be *much* smaller as a result and would make any potential conflict a moot issue.

Posted by stupid_idiot on July 01 2007,17:00

Making a symlink from /usr/local/include/wx-2.6 to /opt/libwxgtk1-dev/wx-2.6 will do, besides including '/usr/local/bin/{wx-config,wxrc,wxrc-2.6}'. 'libwxgtk1-dev.uci' will be a little over 700k. Meanwhile, 'libwxgtk1.uci' is ~1800k. This seems like the best way. Also, it is very good to hear audacity can be reduced in size.