Thread: error messages, documentation need improvement
Brought to you by:
thesun
From: Tom M. <tme...@vl...> - 2005-08-23 05:10:38
|
After reading the "Quick use guide" here: http://sourceforge.net/docman/display_doc.php?docid=26727&group_id=129038 I grabbed a certificate (cert) and private key (key) created with OpenSSL on my Debian box and attempted to run rsyncrypto 0.14 on a Windows NT system: % rsyncrypto.exe src/file cryp/file key cert Invalid version magic: Not exactly a helpful error message. So I downloaded the source package, grepped the files for the error message, and found that it had something to do with not liking the format of the certificate. I dug through the mailing list archives and came across this helpful message: http://sourceforge.net/mailarchive/message.php?msg_id=11809991 Shachar Shemesh writes: > AES keys (a.k.a. symmetric keys) are generated automatically by > rsyncrypto per encrypted files. This is what is stored in the "key" > file name you specify as the third parameter. Ah, so rsyncrypto creates the key file, rather than reading it. The guide, when it says stuff like: If [the key file] already exists, the keys in it will be used for this encryption. or It can either exist, in which case the next parameter can be an x509 certificate with a public key, or not exist, in which case the next parameter needs to be the private key corresponding to the public key used during encryption. In the later case, the key file will be created after decryption. makes it sound like supplying a key is required for encryption. After this was clarified, it made a lot more sense why the key parameter is a directory when you specify the -r switch. > The rsyncrypto manual points you to the req(1) and x509(1) manual > pages of openssl. Manual? Ah, I see it now in the source package. Apparently it didn't make it into the Win32 package. The man page says: rsyncrypto will encrypt files using a symmetric block cipher (AES). Each file is encrypted using a unique key. The file key is stored in two locations. One is the "key" file, and the second is inside the encrypted file itself. The second copy is encrypted using a RSA public key, which can be shared for all encrypted files. which is a pretty clear description. However, saying "each file is encrypted using a unique key," is still vague. Where does the key come from? Apparently it generated by rsyncrypto. That should be specified. Something like..."rsyncrypto generates a 128-bit (see -b switch) symmetric RSA key and encrypts the file using symmetric block cipher (AES). It saves a copy of this key both in the encrypted file and optionally at the location specified by 'symkeyfile'. The former is encrypted using the 'pubkeyfile' (an X509 certificate), which is shared among all files, if processing multiple files." Taking a step back for a moment, what's the benefit of having the individual keys stored in files? I'm sure there is some performance benefit when decrypting, but for the typical user it seems like it would introduce an unnecessary complication and more files that need to be managed. Have you considered having generation of the key files being optional and only enabled if a switch is specified? > Off the top of my head, the command line to generate would > probably be something like: > > openssl req -new -nodes -x509 -out backup.crt -keyout backup.key I think that worked. It got rid of the 'Invalid version magic' error. Be good to add this to the man page. Actually, there should be a mini-HOWTO in the manual that explains how to generates the public/private keys, and how they relate to rsyncrypto. Much of the raw info for that is in the email I'm quoting. > The *.crt file is the certificate (public key) file. rsyncrypto > ignores just about all fields of the resulting certificate except > the actual key. Then I'm not sure why rsyncrypto didn't like my original certificate. It looked essentially the same, but had a bunch of headers before the 'BEGIN CERTIFICATE' block. (The original certificate was generated without the -nodes and -x509 options.) So after putting the new certificate (cert) and private key in place, I eventually got it to work in the recursive mode, after creating empty destination directories for the encrypted files (cbin) and the symmetric keys (keys): % rsyncrypto.exe -r bin\ cbin\ keys\ cert and decrypted the files using: % rsyncrypto.exe -d -r cbin\ ubin\ keys\ cert Along the way I erroneously used -c instead of -r and again got some less than useful error messages: % rsyncrypto.exe -c bin cbin keys cert file open failed: Input/output error % rsyncrypto.exe -c bin\ cbin\ keys\ cert file open failed: No such process Also, after encrypting an individual file like so: % rsyncrypto.exe bin/rsync.exe cbin/rsync.exe rsync.exe.key cert when attempting to decrypt it using: % rsyncrypto.exe -d cbin/rsync.exe test.exe rsync.exe.key or % rsyncrypto.exe -d cbin/rsync.exe test.exe cert or % rsyncrypto.exe -d cbin/rsync.exe test.exe private rsyncrypto crashes. The second variation should have failed to decrypt, but the other two should have worked - no? If not, how do you decrypt a file when you've lost the symkey? Apparently like this: % rsyncrypto.exe -d cbin/rsync.exe test.exe foo private where 'foo' is a non-existent file, which gets created. Technically the "Quick use guide" accurately describes how this works, but it's far from intuitive. Regardless, none of them should have crashed. But: % rsyncrypto.exe -d cbin/rsync.exe test.exe rsync.exe.key private or % rsyncrypto.exe -d cbin/rsync.exe test.exe rsync.exe.key cert works, even though the second one doesn't make much sense. I don't have a convenient build environment on Windows, but if I get the build problems worked out on my Debian box I'll see about adding verbosity to the error messages and look into the above crashes. -Tom -- Tom Metro Venture Logic, Newton, MA, USA "Enterprise solutions through open source." Professional Profile: https://www.linkedin.com/e/fps/3452158/ |