Re: segmentation fault at decryption

[Frederico R. A. <dev...@gm...>]

  The file you asked exists.
  Strange is that I think I had already been able to decrypt a single 
file successfully. And I was using the public key.
  I tried now to decrypt recursively using the private key and it's working.
  Now that I think of it, it's pretty obvious. It shouldn't be possible 
to decrypt using the public key file, just using the private key.
  Thank you,
  -- Fred

Shachar Shemesh wrote:
> Frederico Rodrigues Abraham wrote:
>> rsyncrypto -v -r -n /home/ugah/.ssh/filemap -d 
>> /home/ugah/filesencrypted/files . /home/ugah/filesencrypted/keys 
>> /home/ugah/.ssh/backup.crt
>>
>> I am getting the following output:
>> -------------
>> Decrypting 
>> /home/ugah/filesencrypted/files/A1D29FC1ED101FFC4DAD1CD3C92B9699
>> Segmentation fault
>> ---------
>>
>> What could be wrong?
>>   
> The only known cause of a segfault with rsyncrypto is documented in 
> the man page:
>> BUGS
>>        Not providing a correct key file may result in segmentation 
>> fault.
> In particular, if you try to perform a cold decryption (i.e. - without 
> a stored symmetric key) using the public key file will, at present, 
> produce a segmentation fault rather than an error message.
>
> At least by going over the command line, it does not appear that this 
> is what you tried to do. Please check the following:
> Does /home/ugah/filesencrypted/keys/A1D29FC1ED101FFC4DAD1CD3C92B9699 
> exist? If not, this is the cause of the problem.
>
> If it doesn't exist, decrypting using backup.key (i.e. - the private 
> key file) rather than backup.crt (the public key file) should solve 
> your problem. If it does exist, please try the following in order and 
> let us know what the results were:
> 1. Back up both keys/A1D29FC1ED101FFC4DAD1CD3C92B9699 and 
> files/A1D29FC1ED101FFC4DAD1CD3C92B9699.
> 2. Try to decrypt it using the single file command line.
> 3. Run
>
> tr -n '\0' '\n' < /home/ugah/.ssh/filemap | grep 
> A1D29FC1ED101FFC4DAD1CD3C92B9699
>
> Find out what the file's original name was. Assuming it was called 
> "/home/ugah/files/foo" (should actually appear without the "home" 
> part), try running:
>
> rsyncrypto -v /home/ugah/files/foo /tmp/foo.enc 
> /home/ugah/filesencrypted/keys/A1D29FC1ED101FFC4DAD1CD3C92B9699 
> /home/ugah/.ssh/backup.crt
> rsyncrypto -v -d /tmp/foo.enc /tmp/foo.dec 
> /home/ugah/filesencrypted/keys/A1D29FC1ED101FFC4DAD1CD3C92B9699 
> /home/ugah/.ssh/backup.crt
> diff /home/ugah/files/foo /tmp/foo.dec
> diff /home/ugah/filesencrypted/keys/A1D29FC1ED101FFC4DAD1CD3C92B9699 
> A1D29FC1ED101FFC4DAD1CD3C92B9699.backup
>
> Tell us whether the whole cycle completed successfully, and whether 
> the files compared were identical 
> (A1D29FC1ED101FFC4DAD1CD3C92B9699.backup is, of course, the back up 
> you made at step 1 above).
>
> I am currently on vacation and not very available. I'll be back with 
> normal Internet connection on Tuesday. Sorry if I'm not very 
> responsive until then.
>
> Shachar
>
>