Thread: problem on windows XP
Brought to you by:
thesun
From: Julian P. R. <jul...@gm...> - 2006-04-17 12:39:38
|
Hi, First of all well done for the great idea for this project. I have looked at the available documentation and the history of this list, and it seems that this will help me a lot. I downloaded the windows binaries, (wont be able to try on Linux till I get home this evening). I am having problems running it from the command line... whatever arguments I give it, the program crashes and I get the usual Microsoft "this program has a problem and will be closed" message. This even happens if I just run "rsyncrypto" at the command line. The only way I got some outout was with "rsyncrypto -h", but otherwise, arguments or no arguments, the program crashes. I just downloaded ver 0.17 .zip file, and tried to run it... Am I doing something wrong? Cheers Julian |
From: Shachar S. <sh...@li...> - 2006-04-17 13:10:49
|
Julian Pace Ross wrote: > Hi, > First of all well done for the great idea for this project. Thanks. > I downloaded the windows binaries, (wont be able to try on Linux till > I get home this evening). > I am having problems running it from the command line... whatever > arguments I give it, the program crashes and I get the > usual Microsoft "this program has a problem and will be closed" message. > This even happens if I just run "rsyncrypto" at the command line. > The only way I got some outout was with "rsyncrypto -h", but > otherwise, arguments or no arguments, the program crashes. > I just downloaded ver 0.17 .zip file, and tried to run it... > Am I doing something wrong? Well, yes, but it's not entirely your fault. There is a known bug that causes rsyncrypto to GPF if it is not given a correct public or private key. The version currently in CVS at least special cases the empty argument list case, but not the one released for Windows. Sorry. So unless you give it all four mandatory arguments, with a valid public key file as the fourth, it will, indeed, barf on you. Sorry. Generating a correct public key is explained in the man page. I'm afraid you'll need openssl for that, however. I hope I helped, Shachar > > Cheers > Julian > -- Shachar Shemesh Lingnu Open Source Consulting ltd. Have you backed up today's work? http://www.lingnu.com/backup.html |
From: Julian P. R. <jul...@gm...> - 2006-04-17 13:49:28
|
OK used a proper certificate file and it is now working fine and I like it :) In the near future I will be implementing a backup solution using rsyncrypto, so I will send some feedback maybe it will help the development / ideas. Thanks & well done. Julian Shachar Shemesh wrote: >Julian Pace Ross wrote: > > > >>Hi, >>First of all well done for the great idea for this project. >> >> > >Thanks. > > > >>I downloaded the windows binaries, (wont be able to try on Linux till >>I get home this evening). >>I am having problems running it from the command line... whatever >>arguments I give it, the program crashes and I get the >>usual Microsoft "this program has a problem and will be closed" message. >>This even happens if I just run "rsyncrypto" at the command line. >>The only way I got some outout was with "rsyncrypto -h", but >>otherwise, arguments or no arguments, the program crashes. >>I just downloaded ver 0.17 .zip file, and tried to run it... >>Am I doing something wrong? >> >> > >Well, yes, but it's not entirely your fault. > >There is a known bug that causes rsyncrypto to GPF if it is not given a >correct public or private key. The version currently in CVS at least >special cases the empty argument list case, but not the one released for >Windows. Sorry. > >So unless you give it all four mandatory arguments, with a valid public >key file as the fourth, it will, indeed, barf on you. Sorry. > >Generating a correct public key is explained in the man page. I'm afraid >you'll need openssl for that, however. > >I hope I helped, > Shachar > > > >>Cheers >>Julian >> >> >> |
From: Julian P. R. <jul...@gm...> - 2006-06-21 12:41:34
|
Hi Shachar, Today I have finally found some time to play around with rsyncrypto, and I have a couple of simple questions if you dont mind. I am using a 1024 bit X509 certificate for the encryption, and I am performing some tests on a test folder which is around 5Mb in size. Encryption and decryption work fine. I noticed that encryption of the whole 5Mb takes around 30s, during which CPU is at a constant 100%. (I have a P4 1.7G on a laptop (win XP)). During decryption, CPU is also at 100% but the duration is around a third (10sec). Is this the behaviour to be expected? If it is the case, its probably OK for me, although if I have to encrypt say 1Gb from scratch it would mean around 1hr 40 mins with CPU at 100%!!! Maybe there are ways (using different types of keys etc..) that I can do to speed up the process? Another question.. this is the command I'm running from the command line: C:\rsyncrypto-0.17>rsyncrypto -rcv --delete \testdec \testenc \rsyncrypto- 0.17 mykey.crt Something strange happens: I find the encrypted files in the dst directory (testenc). But I also find a copy of all that I encrypted in \rsyncryptp- 0.17, which is the "keysdir". Also, i tried doing a "cold" decryption, using a similar command line above (switching the src and dst, and adding -d) with mykey.key instead of mykey.crt. However I am getting a GPF. Finally, just a curiosity... in my language (Maltese) Shemesh means "sun"... is it the same at your end? :) Thanks Julian |
From: Shachar S. <rsy...@sh...> - 2006-06-21 13:00:10
|
Julian Pace Ross wrote: > Encryption and decryption work fine. I noticed that encryption of the > whole 5Mb takes around 30s, during which CPU is at a constant 100%. (I > have a P4 1.7G on a laptop (win XP)). > During decryption, CPU is also at 100% but the duration is around a > third (10sec). > Is this the behaviour to be expected? I'm not sure. I'm still looking into what can be done to speed rsyncrypto up. At the moment, this is consistent with the numbers I get. > Maybe there are ways (using different types of keys etc..) that I can > do to speed up the process? As far as I can tell, it's the gzip, rather than the encryption, that slows everything down. You can try passing compression levels to gzip using the "--gzip" rsyncrypto option. > Another question.. this is the command I'm running from the command line: > C:\rsyncrypto-0.17>rsyncrypto -rcv --delete \testdec \testenc > \rsyncrypto-0.17 mykey.crt > > Something strange happens: I find the encrypted files in the dst > directory (testenc). But I also find a copy of all that I encrypted in > \rsyncryptp- 0.17, which is the "keysdir". Rsyncrypto has two keys. One is the assymetric key (which you generated as mykey.crt, well done), and another is the per file symmetric key used for hot decryption. These are generated in the "keysdir" directory (in the case of recursive encryption). > Also, i tried doing a "cold" decryption, using a similar command line > above (switching the src and dst, and adding -d) with mykey.key > instead of mykey.crt. However I am getting a GPF. Can it be that you are using an encrypted private key? At the moment, rsyncrypto does not support that. > Finally, just a curiosity... in my language (Maltese) Shemesh means > "sun"... is it the same at your end? :) Both my name and my surname have meaning in Hebrew. See http://shemesh.biz/sun.html. Surprisingly enough, my surname's meaning in Hebrew and in Maltese is the same. Do you know of any connection between the languages? > Thanks > Julian Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. Have you backed up today's work? http://www.lingnu.com/backup.html |
From: Julian P. R. <jul...@gm...> - 2006-06-21 13:58:59
|
> As far as I can tell, it's the gzip, rather than the encryption, that > slows everything down. You can try passing compression levels to gzip > using the "--gzip" rsyncrypto option. OK, I understand... however not too sure about the syntax.. (can i use the gzip.exe that came with the rsyncrytpo for windows?) > Can it be that you are using an encrypted private key? At the moment, > rsyncrypto does not support that. Yep that was the case... I am now happily hot and cold decrypting. Since I am new to cryptography, I still cant figure what the pros and cons of hot/cold decryption are... the unique "per file" key is also stored in the encrypted file itself, so why not just always use the private key to decrypt? The speed of hot/cold seems to be the same... any hints?... I know i need to read up more on the subject... >> Finally, just a curiosity... in my language (Maltese) Shemesh means >> "sun"... is it the same at your end? :) > > Both my name and my surname have meaning in Hebrew. See > http://shemesh.biz/sun.html. Surprisingly enough, my surname's meaning > in Hebrew and in Maltese is the same. Do you know of any connection > between the languages? Ah, that makes sense... Maltese is a semitic language with strong arabic, spanish, and italian influences (Malta having been conquered by everyone and their dog throughout history)... but it remains fundamentally semitic.. so there is the interesting connection. Thanks again. Regds Julian |
From: Julian P. R. <jul...@gm...> - 2006-06-22 10:19:54
|
Hi again Shachar, If i am encrypting files that do not already exist on the dst dir, but the aes symmetric key for that file does exist in the keysdir (since this file was already encypted before, but simply deleted from the dst dir), is the same symmetric key already available in keysdir used anyway? Also, if I understood well, once the RSA key is used to create the symmetric key, then the RSA key is never used for simple updates of the file (since the symmetric key is used directly). How much does this speed up the process? Also I realised the if a file is changed slightly, and the aes key in the keysdir is deleted, running an encryption will recreate the key file in keysdir. Since this recreated key is the same key encrypted in the file, wouldnt the private key be needed to recreate the unencrypted aes key in keys dir? Or is a new key generated from scratch when this happens? Newxt question..... the man page refers to a gzip file that performs null compression by redirecting the I/O to cat. I cant seem to find the file in the source tgz... but my real question is: Is this possible on windows? Is it possible to bypass compression entirely? And finally, do you take any precautionary measures to prevent your clients from choosing wrong dirs, keys etc.. thus generating segmentation faults? Hopefully this will be my last barrage of 'rsyncrpyto newbie' questions... Thanks once again Julian PS i dont know if you got the email below late yesterday... OK, I understand... however not too sure about the syntax.. (can i use > the gzip.exe that came with the rsyncrytpo for windows?) > > > Can it be that you are using an encrypted private key? At the moment, > > rsyncrypto does not support that. > > Yep that was the case... I am now happily hot and cold decrypting. Since > I am new to cryptography, I still cant figure what the pros and cons of > hot/cold decryption are... the unique "per file" key is also stored in > the encrypted file itself, so why not just always use the private key to > decrypt? > The speed of hot/cold seems to be the same... any hints?... I know i > need to read up more on the subject... > > >> Finally, just a curiosity... in my language (Maltese) Shemesh means > >> "sun"... is it the same at your end? :) > > > > Both my name and my surname have meaning in Hebrew. See > > http://shemesh.biz/sun.html. Surprisingly enough, my surname's meaning > > in Hebrew and in Maltese is the same. Do you know of any connection > > between the languages? > > Ah, that makes sense... Maltese is a semitic language with strong > arabic, spanish, and italian influences (Malta having been conquered by > everyone and their dog throughout history)... but it remains > fundamentally semitic.. so there is the interesting connection. > > Thanks again. > Regds > Julian > > > _______________________________________________ > Rsyncrypto-devel mailing list > Rsy...@li... > https://lists.sourceforge.net/lists/listinfo/rsyncrypto-devel > |
From: Shachar S. <rsy...@sh...> - 2006-06-23 14:33:49
|
Julian Pace Ross wrote: > Hi again Shachar, > > If i am encrypting files that do not already exist on the dst dir, but > the aes symmetric key for that file does exist in the keysdir (since > this file was already encypted before, but simply deleted from the dst > dir), is the same symmetric key already available in keysdir used anyway? Yes. > Also, if I understood well, once the RSA key is used to create the > symmetric key, then the RSA key is never used for simple updates of > the file (since the symmetric key is used directly). How much does > this speed up the process? It doesn't. For one thing, each file is encrypted independently of the previous time it was encrypted. Only the symmetric key is used. As such, while we save on generating a new symmetric key, we do still encrypt it using RSA. Another aspect is that the RSA encryption takes a negligible part of the time it takes to actually encrypt the file. > Also I realised the if a file is changed slightly, and the aes key in > the keysdir is deleted, running an encryption will recreate the key > file in keysdir. The symmetric key is only extracted during decryption, and only if it's not already available. The answer to your question is "you understood incorrectly". > Since this recreated key is the same key encrypted in the file, > wouldnt the private key be needed to recreate the unencrypted aes key > in keys dir? If your statement above were true, then yes. > Or is a new key generated from scratch when this happens? Yes. > Newxt question..... the man page refers to a gzip file that performs > null compression by redirecting the I/O to cat. I cant seem to find > the file in the source tgz... but my real question is: Is this > possible on windows? The nullgzip was mostly used for testing purposes. At some point, to make working with CVS faster, I moved all the testing infrastructure into a different CVS branch. Unfortunately, I never got around to releasing it properly. If memory serves me correctly, it had a Windows version of the null gzip as well (the Unix version was just a tiny shell script). > Is it possible to bypass compression entirely? Using null gzip it is. I highly recommend against it, however. Rsyncrypto already reduces the strength of the encryption when compared with the standard AES/CBC method. Making the compressed input a low entropy one introduces uncertainties that I would rather not sign my name on. > And finally, do you take any precautionary measures to prevent your > clients from choosing wrong dirs, keys etc.. thus generating > segmentation faults? Mostly, my clients either get me to install the system for them. A GUI wrapper is in development, but due to my health situation, that has been delayed. > Hopefully this will be my last barrage of 'rsyncrpyto newbie' > questions... > > Thanks once again > Julian > PS i dont know if you got the email below late yesterday... > > OK, I understand... however not too sure about the syntax.. (can i use > the gzip.exe that came with the rsyncrytpo for windows?) > Yes, but you need to make sure it receives the correct parameters, probably through a wrapper. Unfortunately, I'm not aware of an easy way to do that in Windows. In Unix, you could write a tiny shell script. Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. Have you backed up today's work? http://www.lingnu.com/backup.html |
From: Shachar S. <rsy...@sh...> - 2006-06-23 14:33:49
|
Julian Pace Ross wrote: > Hi again Shachar, > > If i am encrypting files that do not already exist on the dst dir, but > the aes symmetric key for that file does exist in the keysdir (since > this file was already encypted before, but simply deleted from the dst > dir), is the same symmetric key already available in keysdir used anyway? Yes. > Also, if I understood well, once the RSA key is used to create the > symmetric key, then the RSA key is never used for simple updates of > the file (since the symmetric key is used directly). How much does > this speed up the process? It doesn't. For one thing, each file is encrypted independently of the previous time it was encrypted. Only the symmetric key is used. As such, while we save on generating a new symmetric key, we do still encrypt it using RSA. Another aspect is that the RSA encryption takes a negligible part of the time it takes to actually encrypt the file. > Also I realised the if a file is changed slightly, and the aes key in > the keysdir is deleted, running an encryption will recreate the key > file in keysdir. The symmetric key is only extracted during decryption, and only if it's not already available. The answer to your question is "you understood incorrectly". > Since this recreated key is the same key encrypted in the file, > wouldnt the private key be needed to recreate the unencrypted aes key > in keys dir? If your statement above were true, then yes. > Or is a new key generated from scratch when this happens? Yes. > Newxt question..... the man page refers to a gzip file that performs > null compression by redirecting the I/O to cat. I cant seem to find > the file in the source tgz... but my real question is: Is this > possible on windows? The nullgzip was mostly used for testing purposes. At some point, to make working with CVS faster, I moved all the testing infrastructure into a different CVS branch. Unfortunately, I never got around to releasing it properly. If memory serves me correctly, it had a Windows version of the null gzip as well (the Unix version was just a tiny shell script). > Is it possible to bypass compression entirely? Using null gzip it is. I highly recommend against it, however. Rsyncrypto already reduces the strength of the encryption when compared with the standard AES/CBC method. Making the compressed input a low entropy one introduces uncertainties that I would rather not sign my name on. > And finally, do you take any precautionary measures to prevent your > clients from choosing wrong dirs, keys etc.. thus generating > segmentation faults? Mostly, my clients either get me to install the system for them. A GUI wrapper is in development, but due to my health situation, that has been delayed. > Hopefully this will be my last barrage of 'rsyncrpyto newbie' > questions... > > Thanks once again > Julian > PS i dont know if you got the email below late yesterday... > > OK, I understand... however not too sure about the syntax.. (can i use > the gzip.exe that came with the rsyncrytpo for windows?) > Yes, but you need to make sure it receives the correct parameters, probably through a wrapper. Unfortunately, I'm not aware of an easy way to do that in Windows. In Unix, you could write a tiny shell script. Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. Have you backed up today's work? http://www.lingnu.com/backup.html |