cryptsetup 1.3.0-rc1 (test release candidate)

The first cryptsetup 1.3.0-rc1 release candidate is available at

http://code.google.com/p/cryptsetup/

Feedback and bug reports are welcomed.

p.s. Please let me know if you tested crypto backend support or loop-AES compatibility mode (and report problems, if there is any:-)

Thanks,
Milan

Cryptsetup 1.3.0 (rc1) Release Notes
====================================

Changes since version 1.2.0

Important changes
~~~~~~~~~~~~~~~~~
* Several userspace crypto backends support

cryptsetup now supports generic crypto backend interface which allows compile package with various crypto libraries, these are already implemented:

* gcrypt (default, used in previous versions)
* OpenSSL
* NSS (because of missing ripemd160 it cannot provide full backward compatibility)
* kernel userspace API (provided by kernel 2.6.38 and above)
(Note that kernel userspace backend is very slow for this type of operation.
But it can be usefull for embedded systems, because you can avoid userspace crypto library completely.)

Backend is selected during configure time, using --with-crypto_backend option.

   configure --with-crypto_backend=BACKEND (gcrypt/openssl/nss/kernel) [gcrypt]

Note that performance checked (iterations) in LUKS header will cause that real iteration time will differ with different backends. (There are huge differences in speed between libraries.)

* Cryptsetup now automatically allocates loopback device (/dev/loop) if device argument is file and not plain device.

This require Linux kernel 2.6.25 and above (which implements loop autoclear flag).

You can see backing file in cryptsetup status output if underlying device is loopback.

* Adds luksChangeKey command

cryptestup luksChangeKey --key-file <old keyfile> <new keyfile> [--key-slot X] cryptestup luksChangeKey [--key-slot X] (for passphrase change)

This command allows passphrase/keyfile change in one step. If no key slot is specified (and there is still free key slot on device) new slot is allocated before the old is purged.

If --key-slot option is specified (or there is no free slot) command will overwrite existing slot.
WARNING: Be sure you have another slot active or header backup when using explicit
key slot (so you can unlock the device even after possible media failure).

* Adds compatible support for loop-AES encryption type in loopaesOpen command.

Linux dm-crypt in 2.6.38 and above supports loop-AES compatible mapping (including multi-key and special CBC mode, all three modes are supported).

If you have raw loop-AES keyfile (text file with uuencoded per-line keys), you can access loop-AES volume using

     cryptsetup loopaesOpen <device> <name> [--key-size 128] --key-file <key-file>

If you are using GPG encrypted keyfile

     gpg --decrypt <key-file> | cryptsetup loopaesOpen --key-file=- <device> <name>

Do not forget to specify key size. Other ciphers than AES should work but were not tested. Version and hash is automatically detected according to number of lines in key file.

Please note that loopAES dm-crypt mode is provided for compatibility reasons (so you do not need to patch kernel and util-linux to map existing volumes) but is is not, and never will be, optimized for speed.
It is experimental feature for now.

* WARNING: This is the last cryptsetup release which supports library with old API (using struct crypt_options).
These calls are deprecated since 1.1.0 and AFAIK no application is using it in recent distros. Removing compatible code will allow new features to be implemented easily.

Other changes
~~~~~~~~~~~~~
* Increase libcryptsetup version (loopAES change), still fully backward compatible.
* Fixes static build (--disable-static-cryptsetup now works properly).
* Supports secure data flag for device-mapper iotcl (will be in 2.6.39, forcing kernel to wipe all ioctl buffers with possible key data). To enable this flag you need new device-mapper library, in LVM2 2.02.84.
* Add copyright texts into some files and adds GPL exception allowing to distribute resulting binaries linked with OpenSSL.
* Update FAQ.
* Fix message when locking memory fails.
* Fix luksAddKey return code if master key is used.
* Update some text files in distributions.
* Add docs directory with Release Notes archive.
* Do not hardcode loopback device name in tests, use internal loopback library.

Thanks for your work, Milan.

I've tried to open some old loop-AES partitions with this version and kernel 2.6.38-rc8. It basically seems to work (however, it seems to be slower than original loop-aes as your comment regarding speed suggests)

Two notes:

1) Keyfile handling

The following didn't work with one keyfile:

cryptsetup --key-file /path/keyfile -s 256 loopaesOpen <device> <name>

but this did work:

cat /path/keyfile | \\
cryptsetup --key-file - -s 256 loopaesOpen <device> <name>

I didn't have this problem with another keyfile.

2) Offset, skip and sizelimit support

It was common to store the gpg-keyfile in the head of an partition. See for example http://loop-aes.sourceforge.net/aespipe.README:

---
3.3. Example 3 - Encrypted CD-ROM
[...]
mount -t iso9660 /dev/cdrom /cdrom -o loop=/dev/loop0,encryption=AES128,gpgkey=/dev/cdrom,offset=8192
---

I was able to open such a partition with plain dmsetup; 'cryptsetup loopaesOpen' didn't work because '--size','--skip' and '--offset' are not supported. Perhaps you could add support for these switches to loopaesOpen; the necessary changes in cryptsetup seems trivial. ( '--offset' - but not '--skip' - is already mentioned in the manpage as a supported option for loopaesOpen )

mfg,
Rudi

yes, it is slow but is is generally usable. I tried to implement it the simplest way (e.g. CBC first block tweaking is done using dmcrypt IV generator, in theory it should be done using cryptoAPI etc).

Can you please send me the keyfile (with replaced all keys with zeroes or so
- I think the problem is just with EOL chars)?

Yes, I know. I was not sure is someone really using it :)

Maybe I added something already but not documented it, anyway I want to add:

- offset should be supported using --offset switch

- skip - I am not sure how it works in loopAES, need to check. If it is just IV offset on the first data sector, it is just one line of code (we have the same for plain dmcrypt already).

- limited read of key-file from start of device should be done using --keyfile-size. But the problem is that it is gpg encrypted, and I do not want to fork gpg binaries from cryptsetup code (at least not in this version).

But it can be probably workarounded using wrapper like
dd if=<dev> bs=8k count=1 2>/dev/null | gpg -d .. | cryptsetup --offset ...

Really, LUKS is better here in handling metadata on disk. (And loop device support allows separate metadata device in next version, I had just not time to finish that yet in 1.3.0)

yes, I'll fix it in next rc.

Thanks for testing it!
Milan

Yes, it's fast enough for compatibility access of old disks. People should switch to xts, if they want better speed.

It seems to be a problem with (unusual) large keyfiles. Sampe keyfile generation:

for dat in seq 1 65; do head -c "$x" /dev/urandom | \\
openssl enc -base64 -A ; echo ; done >keyfile

On my machine, $x greater than 90 results in different internal keys for 'cat keyfile | cryptsetup ' and 'cryptsetup --key-file keyfile'. If the key-file is even large, I get at least an error message. Sample keyfile ( x=91 ) attached or at http://pastebin.com/PeLUZ5a4, if the mailing list removes attachements.

mfg,
rudi

[...]

Wups, buffer overflow or cutdown (with the later being a whole lot better, but still a problem)?

Arno

Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: [email protected] 
GnuPG:  ID: 1E25338F  FP: 0C30 5782 9D93 F785 E79C  0296 797F 6B50 1E25 338F
----
Cuddly UI's are the manifestation of wishful thinking. -- Dylan Evans

If it's in the news, don't worry about it.  The very definition of 
"news" is "something that hardly ever happens." -- Bruce Schneier 

There are no fixed buffers :)

Increasing LOOPAES_KEYFILE_MAXSIZE helps.
(it is clearly visible in debug output - when reading from stdout, it reads 8125 bytes, but from keyfile it is limited to 8000).

I will also limit LUKS keyfile in next version, mistake will cause problems (reading the whole device in locked memory -> OOPS or something like that). I guess max 8MB is enough? We have already limit on passphrase from terminal to 512 bytes.

Fixed in svn already.

Milan

Hey,

please document these limits properly in the manpage.

greetings,
jonas

Sure. The loop aes limit was safety margin, I am really not sure which configuration are even possible. It was set up according to documentation.

(And the reported keyfile was so nice, that it cut exactly the last key so it detected 64 keys (v2 keyfile) instead of 65 and not failed because of wrong key length as expected:-)

For the LUKS limit must be documented and must not cause regressions for people (that one is not yet limited in code, that remark above was misleading, I just added TODO line.

Milan

Ah, very good! (Not that I really suspected this was an overflow ;-)

But a cut-down. Hmm. I think this makes sense, even if it can break some things. But it should give an error rather than proceed, see below.

Indeed. What you could do is have it default to error instead of to cut-down and proceed. That would make more sense, since cutting it is almost always not going to work. The only case I can think of were cutting works if is your key comes from /dev/(u)random for swap or the like.

If it gives a descriptive error message when the length is exceded, it is less critical. Also, a commandline option to increase/decrease the limit may be a good idea, but I would see it as non-urgent.

Arno

Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: [email protected] 
GnuPG:  ID: 1E25338F  FP: 0C30 5782 9D93 F785 E79C  0296 797F 6B50 1E25 338F
----
Cuddly UI's are the manifestation of wishful thinking. -- Dylan Evans

If it's in the news, don't worry about it.  The very definition of 
"news" is "something that hardly ever happens." -- Bruce Schneier 

yup. This is common problem for all supported types, so I will probably remove per-type limits, and add one maximal keyfile limit configurable during compile time.

Exceeding this limit will cause fail.

Limiting keyfile read (if needed - like /dev/urandom or when stored in the beginning of device) should be always possible using --keyfile-size parameter (or --new-keyfile-size for new keyfile option).

(This commadline limit option should possibly override maximal compiled-in limit if specified number is larger.)

Is it better approach?

Milan

Sounds fine to me, especially if the commandline can override the compile limit. Then the compile-limit protects everybody except those that think they know what they are doing. And those are responsible for their own actions. This would also remove any need to think about extreme cases in the compile limit.

Arno

Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: [email protected] 
GnuPG:  ID: 1E25338F  FP: 0C30 5782 9D93 F785 E79C  0296 797F 6B50 1E25 338F
----
Cuddly UI's are the manifestation of wishful thinking. -- Dylan Evans

If it's in the news, don't worry about it.  The very definition of 
"news" is "something that hardly ever happens." -- Bruce Schneier 

I added offset support, seems loopAES always uses offset==skip (IOW initial vector is always related to absolute sector size on the device).

Reading of keyfile from device can be limited by --keyfile-size switch, but as described elsewhere there is no internal gpg support, so gpg encrypted key is stored on device itself, you have to process it using gpg first.

I do not plan to add sizelimit option, this can just cause confusion.

(In fact you can do that using cryptsetup resize command afterwards or by limiting underlying device. If it is problem, please show me real example where it is needed.)

I'll release another RC soon (also with keyfile limits rewritten).

Thanks,
Milan

No, loopAES supports both options. It depends on user input:

--
-o offset
The data start is moved offset bytes into the specified file or
device. Normally offset is included in IV (initialization
vector) computations. If offset is prefixed with @ character, then offset is not included in IV computations. @ prefix functionality may not be supported on some older kernels and/or loop drivers.
--

Both options seems to be supported by dmcrypt/dmsetup. In the first case IV offset is always identic to the sector offset, in the second case IV offset is always zero.

(IV offset: 6th value at dmsetup table, sector offset: 8th value. I hope, I haven't muddle something )

Sounds reasonable. It's main usage seems to be recovery if your partition table is damaged or similar exceptional things happend.

I wonder how I missed that. Ok, the we just allow --skip and if it is not explicitly defined, it will behave as now. So @offset => --skip 0 --offset $offset/512, right?

I added test for default offset (and verification with losetup passes), so it is just that @ prefix mode missing now.

yes, everything is supported, this is just userspace handling.

FYI the documentation is in kernel itself
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob_plain;f=Documentation/device-mapper/dm-crypt.txt;hb=HEAD

Thanks,
Milan

Yes.
However the current behaviour is that skip is implicitly set to the same value as offset.
The default behaviour for plain-cryptsetup is that skip is set to zero, if only offset is specified.
But I don't think this inconistency matters. There are also inconsistencies in the interface between cryptsetup/plain and cryptsetup/luks (e.g. order of name and device )

Yes.

Btw, I can't report any problems with other ciphers. Twofish and serpent seem to work well, too.

cu,
rudolf

Exactly. That's why I implemented it is as different command.

(But from the libcryptsetup point of view it is just another format, no new functions, just format specific options.)

In fact, I hate these inconsistencies but I cannot switch order or parameters now. And providing new commadline interface causes even more problems...

Code is already in svn, there is one change in library object (format specific option missed skip option) but we can do that still, so final 1.3.0 version will have that included.

Great.

Thanks again for testing,
Milan

Thanks again, Milan.

It looks fine to me. I was able to open old disks with it. And I've also run a small script that systematically compared the output of loop-aes and dmcrypt for different settings (cipher, keylength, keymode, offset/iv computation,...).

Some features are missing (key size 160 for dmcrypt, and various losetup-switches (phash,itercountk), but it's unclear, if anyone use them. ( At least as long as loop-aes is still maintained, it's IHMO not necessary to support exotic settings )

cu,
rudolf

yes, it is expected. I can implement it if anyone uses it but I doubt it is worth it. This is really not targeted as replacement but compatible mode to open existing devices.

BTW key size 160 bits? strange size. for which cipher?
Probably kernel cryptoAPI module limitation, there should be no limit in dmcrypt.

Milan

Am Wed, 23 Mar 2011 15:37:48 +0100
schrieb Milan Broz <[email protected]>:

it's mentioned for twofish and blowfish in my manpage of losetup (losetup/loop-aes accepts even other key lengths. I don't know, if this behaviour is intentend or make sense at all )

http://loop-aes.sourceforge.net/ciphers.README mentions twofish160 only. According to this document, it's necessary for compatibility with suse 8.1 encryption ( together with other unusal and insecure settings).

ok, just quickly reading twofish cryptoAPI implementation in kernel, it seems to not support 160bit (just 128, 192, 256).
so neither cryptsetup nor dmcrypt problem.

Milan

Cryptsetup does support the odd format of those old images. The key length for those images actually isn't 160 bits but 192 though. The missing bits of the 160 bit ripemd160 output were padded with zeros. The needed options for cryptsetup are
--cipher twofish-cbc-null -s 192 -h ripemd160:20

cu
Ludwig

 (o_   Ludwig Nussel
 //\
 V_/_  http://www.suse.de/
SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg)

Do I gets this right, if multikey is not used loop aes is just equivalent to aes-cbc-plain? Couldn't the existing 'create' action be extended to just handle the loop-AES multikey mode as well? Ie no additional command?

Note the IV produced by 'plain' is 32bit while loop-AES uses 64bit IIRC. Ie there's an incompatibility for volumes larger than 2TB. So you probably need to default to 'aes-cbc-plain64'. I guess that's the reason why you introduced plain64 in the first place. :-)

cu
Ludwig

 (o_   Ludwig Nussel
 //\
 V_/_  http://www.suse.de/
SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg)

There is additional hashing per line for loopAES keyfile and it warns user if it detects GPG header. (create will simply map device without warning).

Yes, you can probably map this one one key mode using create command as well, but using separate command allows version to be autodetected according to number of lines in keyfile.

I do not want to mix these formats together, non-multikey loopAES mode is not safe anyway and should not be used.

Yes, that is just mistake, there should be plain64, thanks. That's why I do release candidate to catch these things:)

Milan

The second cryptsetup 1.3.0-rc2 release candidate is available at

http://code.google.com/p/cryptsetup/

Feedback and bug reports are welcomed.

Thanks,
Milan

Cryptsetup 1.3.0 (rc2) Release Notes
====================================

Changes since version 1.3.0-rc1

* Introduce maximum default keyfile size, add configure option, visible in --help.

Cryptsetup now fails if read from keyfile exceeds internal limit.
You can always specify keyfile size (overrides limit) by using --keyfile-size option.

* Require the whole key read from keyfile in create command (regression in 1.2.0).

* Fix offset option for loopaesOpen.

* Lock memory in luksDump command.

Changes since version 1.2.0

Important changes
~~~~~~~~~~~~~~~~~
* Several userspace crypto backends support

cryptsetup now supports generic crypto backend interface which allows compile package with various crypto libraries, these are already implemented:

* gcrypt (default, used in previous versions)
* OpenSSL
* NSS (because of missing ripemd160 it cannot provide full backward compatibility)
* kernel userspace API (provided by kernel 2.6.38 and above)
(Note that kernel userspace backend is very slow for this type of operation.
But it can be usefull for embedded systems, because you can avoid userspace crypto library completely.)

Backend is selected during configure time, using --with-crypto_backend option.

   configure --with-crypto_backend=BACKEND (gcrypt/openssl/nss/kernel) [gcrypt]

Note that performance checked (iterations) in LUKS header will cause that real iteration time will differ with different backends. (There are huge differences in speed between libraries.)

* Cryptsetup now automatically allocates loopback device (/dev/loop) if device argument is file and not plain device.

This require Linux kernel 2.6.25 and above (which implements loop autoclear flag).

You can see backing file in cryptsetup status output if underlying device is loopback.

* Adds luksChangeKey command

cryptestup luksChangeKey --key-file <old keyfile> <new keyfile> [--key-slot X] cryptestup luksChangeKey [--key-slot X] (for passphrase change)

This command allows passphrase/keyfile change in one step. If no key slot is specified (and there is still free key slot on device) new slot is allocated before the old is purged.

If --key-slot option is specified (or there is no free slot) command will overwrite existing slot.
WARNING: Be sure you have another slot active or header backup when using explicit
key slot (so you can unlock the device even after possible media failure).

* Adds compatible support for loop-AES encryption type in loopaesOpen command.

Linux dm-crypt in 2.6.38 and above supports loop-AES compatible mapping (including multi-key and special CBC mode, all three modes are supported).

If you have raw loop-AES keyfile (text file with uuencoded per-line keys), you can access loop-AES volume using

     cryptsetup loopaesOpen <device> <name> [--key-size 128] --key-file <key-file>

If you are using GPG encrypted keyfile

     gpg --decrypt <key-file> | cryptsetup loopaesOpen --key-file=- <device> <name>

Do not forget to specify key size. Other ciphers than AES should work but were not tested. Version and hash is automatically detected according to number of lines in key file.

Please note that loopAES dm-crypt mode is provided for compatibility reasons (so you do not need to patch kernel and util-linux to map existing volumes) but is is not, and never will be, optimized for speed.
It is experimental feature for now.

* WARNING: This is the last cryptsetup release which supports library with old API (using struct crypt_options).
These calls are deprecated since 1.1.0 and AFAIK no application is using it in recent distros. Removing compatible code will allow new features to be implemented easily.

Other changes
~~~~~~~~~~~~~
* Increase libcryptsetup version (loopAES change), still fully backward compatible.
* Fixes static build (--disable-static-cryptsetup now works properly).
* Supports secure data flag for device-mapper iotcl (will be in 2.6.39, forcing kernel to wipe all ioctl buffers with possible key data). To enable this flag you need new device-mapper library, in LVM2 2.02.84.
* Add copyright texts into some files and adds GPL exception allowing to distribute resulting binaries linked with OpenSSL.
* Update FAQ.
* Fix message when locking memory fails.
* Fix luksAddKey return code if master key is used.
* Update some text files in distributions.
* Add docs directory with Release Notes archive.
* Do not hardcode loopback device name in tests, use internal loopback library.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

The stable cryptsetup 1.3.0 release is available at

http://code.google.com/p/cryptsetup/

Feedback and bug reports are welcomed.

Milan

Cryptsetup 1.3.0 Release Notes
==============================

Changes since version 1.2.0

Important changes
~~~~~~~~~~~~~~~~~
* Several userspace crypto backends support

cryptsetup now supports generic crypto backend interface which allows compile package with various crypto libraries, these are already implemented:

* gcrypt (default, used in previous versions)
* OpenSSL
* NSS (because of missing ripemd160 it cannot provide full backward compatibility)
* kernel userspace API (provided by kernel 2.6.38 and above)
(Note that kernel userspace backend is very slow for this type of operation.
But it can be usefull for embedded systems, because you can avoid userspace crypto library completely.)

Backend is selected during configure time, using --with-crypto_backend option.

   configure --with-crypto_backend=BACKEND (gcrypt/openssl/nss/kernel) [gcrypt]

Note that performance checked (iterations) in LUKS header will cause that real iteration time will differ with different backends. (There are huge differences in speed between libraries.)

* Cryptsetup now automatically allocates loopback device (/dev/loop) if device argument is file and not plain device.

This require Linux kernel 2.6.25 and above (which implements loop autoclear flag).

You can see backing file in cryptsetup status output if underlying device is loopback.

* Introduce maximum default keyfile size, add configure option, visible in --help.

Cryptsetup now fails if read from keyfile exceeds internal limit.
You can always specify keyfile size (overrides limit) by using --keyfile-size option.

* Adds luksChangeKey command

cryptestup luksChangeKey --key-file <old keyfile> <new keyfile> [--key-slot X] cryptestup luksChangeKey [--key-slot X] (for passphrase change)

This command allows passphrase/keyfile change in one step. If no key slot is specified (and there is still free key slot on device) new slot is allocated before the old is purged.

If --key-slot option is specified (or there is no free slot) command will overwrite existing slot.
WARNING: Be sure you have another slot active or header backup when using explicit
key slot (so you can unlock the device even after possible media failure).

* Adds compatible support for loop-AES encryption type in loopaesOpen command.

Linux dm-crypt in 2.6.38 and above supports loop-AES compatible mapping (including multi-key and special CBC mode, all three modes are supported).

If you have raw loop-AES keyfile (text file with uuencoded per-line keys), you can access loop-AES volume using

     cryptsetup loopaesOpen <device> <name> [--key-size 128] --key-file <key-file>

If you are using GPG encrypted keyfile

     gpg --decrypt <key-file> | cryptsetup loopaesOpen --key-file=- <device> <name>

Do not forget to specify key size. Version and hash is automatically detected according to number of lines in key file. For special configuration you can override IV sector offset using --skip option, device offset with --offset and hash algorithm using --hash, see man page for details.

Please note that loopAES dm-crypt mode is provided for compatibility reasons (so you do not need to patch kernel and util-linux to map existing volumes) but it is not, and never will be, optimized for speed.
It is experimental feature for now.

* Require the whole key read from keyfile in create command (regression in 1.2.0).

* WARNING: This is the last cryptsetup release which supports library with old API (using struct crypt_options).
These calls are deprecated since 1.1.0 and AFAIK no application is using it in recent distros. Removing compatible code will allow new features to be implemented easily.

Other changes
~~~~~~~~~~~~~
* Lock memory also in luksDump command.
* Fix return code when passphrase is read from pipe.
* Increase libcryptsetup version (loopAES change), still fully backward compatible.
* Fixes static build (--disable-static-cryptsetup now works properly).
* Supports secure data flag for device-mapper ioctl (will be in 2.6.39, forcing kernel to wipe all ioctl buffers with possible key data). To enable this flag you need new device-mapper library, in LVM2 2.02.84.
* Add copyright texts into some files and adds GPL exception allowing to distribute resulting binaries linked with OpenSSL.
* Update FAQ.
* Fix message when locking memory fails.
* Fix luksAddKey return code if master key is used.
* Update some text files in distributions.
* Add docs directory with Release Notes archive.
* Do not hardcode loopback device name in tests, use internal loopback library.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iEYEARECAAYFAk2bdVYACgkQf1Jlc7shgi+0kACfWl6r6PW4drgs+gg/Dp2LJswF ov4An1xyiyv2fXBXXsyyTAhF47dGFr41
=wjM/
-----END PGP SIGNATURE-----
_______________________________________________
dm-crypt mailing list [email protected]
http://www.saout.de/mailman/listinfo/dm-crypt

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

The stable cryptsetup 1.3.1 release is available at

http://code.google.com/p/cryptsetup/

Feedback and bug reports are welcomed.

Milan

Cryptsetup 1.3.1 Release Notes
==============================

Changes since version 1.3.0

* Fix keyfile=- processing in create command (regression in 1.3.0).

* Simplify device path status check (use /sys and do not scan /dev).

* Do not ignore device size argument for create command (regression in 1.2.0).

* Fix error paths in blockwise code and lseek_write call.

* Add optional Nettle crypto backend support.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iEYEARECAAYFAk3b01oACgkQf1Jlc7shgi839wCdGoDzkhAT3C9M72Q4DppuC8Gv xLQAniLnce06wzw7iwOLtvlpjPwOoaFZ
=YAom
-----END PGP SIGNATURE-----