On 2-Aug-08, at 13:23 , Ian Zimmerman wrote:
Ok, but how does that solve my problem? Even if I encrypt my file
with
a symmetric cipher I face the same issue - each encrypted copy will be
different.
Why is not having identical encrypted copies a problem?
The key will decrypt each copy to
Ian> I have a local file that I want to encrypt and upload to a remote
Ian> machine in encrypted form. Encrypting is farily quick, but
Ian> uploading is slow, so I use rsync for the other (unencrypted)
Ian> files. But the fact that the encrypted file is different each time
Ian> defeats the rsync
> So did you. This scheme is poorly specified, based on an incorrect
> understanding of user needs, as a practical matter can be cracked, is
> rife with implementation difficulties, and you seem to have no
> understanding of the implicit tradeoffs and compromises which go into it.
I'm sure you ar
Kiss Gabor (Bitman) wrote:
> Eeerrr... sorry to say but I think you missed something.
So did you. This scheme is poorly specified, based on an incorrect
understanding of user needs, as a practical matter can be cracked, is
rife with implementation difficulties, and you seem to have no
understandi
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
> May I quote from the readme of loop-aes:
>
> Recommended key setup mode is multi-key-v3, which is based on gpg
> encrypted key files. In this mode, the passphrase is protected against
> optimized dictionary attacks via salting and key iteratio
On Sun, 3 Aug 2008 20:07, [EMAIL PROTECTED] said:
>> No. Different ciphertexts may yield the same plaintext.
>
> A test speaks for itself:
May I quote from the readme of loop-aes:
Recommended key setup mode is multi-key-v3, which is based on gpg
encrypted key files. In this mode, the passp
> > $ cat /etc/passwd | aespipe | md5sum Password:
> > 9220c2e1d5a5a83710d020b04c306c24 - $ cat /etc/passwd | aespipe | md5sum
> > Password: 9220c2e1d5a5a83710d020b04c306c24 - $
> >
> ?
>
> Apples and Oranges. Consider:
Don't consider please. :-)
Original question was what are proper tools
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Kiss Gabor (Bitman) wrote:
>>> The password is not random therefore every time you encrypt the same
>>> plaintext you got the same cryptfile.
>> No, you won't. All sound encryption schemes use a bit of random to
>> make the resulting ciphertext differ
> > The password is not random therefore every time you
> > encrypt the same plaintext you got the same cryptfile.
>
> No, you won't. All sound encryption schemes use a bit of random to make
> the resulting ciphertext different. In the easiest case this is called
> a salt and used to stop dictio
On Sat, 2 Aug 2008 19:36, [EMAIL PROTECTED] said:
> The password is not random therefore every time you
> encrypt the same plaintext you got the same cryptfile.
No, you won't. All sound encryption schemes use a bit of random to make
the resulting ciphertext different. In the easiest case this
On Tue, Jul 22, 2008 at 12:08 PM, Ian Zimmerman <[EMAIL PROTECTED]> wrote:
> I have a local file that I want to encrypt and upload to a remote
> machine in encrypted form. Encrypting is farily quick, but uploading is
> slow, so I use rsync for the other (unencrypted) files. But the fact
> that th
> Ian> I have a local file that I want to encrypt and upload to a remote
> Ian> machine in encrypted form. Encrypting is farily quick, but
> Ian> uploading is slow, so I use rsync for the other (unencrypted)
> Ian> files. But the fact that the encrypted file is different each time
> Ian> defeats
> I have a local file that I want to encrypt and upload to a remote
> machine in encrypted form. Encrypting is farily quick, but uploading is
> slow, so I use rsync for the other (unencrypted) files. But the fact
> that the encrypted file is different each time defeats the rsync
> incremental upl
Ian> I have a problem to solve :(
Robert> I fail to see the problem.
Not your fault, since I didn't say what it was :-)
I have a local file that I want to encrypt and upload to a remote
machine in encrypted form. Encrypting is farily quick, but uploading is
slow, so I use rsync for the other (
If you need to have this guarantee, you could try overriding the session
key. Note you will lose security by the bucketload by doing so. I really
would not advice it. If you're trying to have some kind of filesystem
encryption (which is my impression, but not sure) gnupg is not the best
tool.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
> Ian Zimmerman wrote:
...
> | apalogies if that's the case. I have a problem to solve :(
> [snip]
> | So I suppose gpg puts some salt probably based on timestamp in. Can this
> | be disabled? Pretty please?
In my experience, people here is ve
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Ian Zimmerman wrote:
| I just noticed this today. I suppose this is completely obvious to most
| readers of the list and perhaps not something they want to be bothered with;
| apalogies if that's the case. I have a problem to solve :(
[snip]
| So
On Jul 20, 2008, at 4:45 PM, Ian Zimmerman wrote:
I just noticed this today. I suppose this is completely obvious to
most
readers of the list and perhaps not something they want to be
bothered with;
apalogies if that's the case. I have a problem to solve :(
So I suppose gpg puts some sal
Ian Zimmerman wrote:
> I have a problem to solve :(
I fail to see the problem.
> So I suppose gpg puts some salt probably based on timestamp in. Can
> this be disabled? Pretty please?
GnuPG uses a random session key to encrypt each message. That means the
payload of each message will be total
I just noticed this today. I suppose this is completely obvious to most
readers of the list and perhaps not something they want to be bothered with;
apalogies if that's the case. I have a problem to solve :(
[EMAIL PROTECTED]:~$ echo foo > foo
[EMAIL PROTECTED]:~$ gpg-encrypt.sh foo foo1.gpg
[E
20 matches
Mail list logo
