Lists Home |
Date Index |
On Fri, 2006-07-14 at 17:14 -0400, Mitch Amiano wrote:
> An encrypted file need not be signed at all, and a signed file need not
> be encrypted.
> The two things - signing and encrypting - are distinct operations.
Yes. I'm happy with that.
> One you do to ensure no one can read the data that shouldn't be reading it.
> The other you do to ensure that no one has tampered with data that
> shouldn't be tampered with, while not necessarily encumbering the
> ability to read it.
I'd like both, hence the need to get them in the right order!
After finding out that Sun (Solaris?) uses tail +386 rather
than tail -n +386, I've finally managed to install their jwsdp package
so I'm hoping today to have a play with dig-sigs. I'm not even sure
which jar files the crypto stuff is in as yet, but I'll chase it down.
> Now, I'm not a security expert. Someone with more experience in this
> area may correct me on this, and could speak to the issue a bit more
> But encryption alone is insufficient. One reason is that someone might
> well encrypt another file and substitute it for your original encrypted
> package. With a signature, both you and the receiver can perform a
> subsequent test that the signature and file still match up. Of course,
> if the signature is also with the original data, and that's your only
> copy, then someone could replace the signature too. Even if not, you or
> the receiver could conceivably maliciously replace both the file and
> the signature, thus creating an uncertainty about whose copy is authentic.
For our application I'm moderately confident of such maliciousness being
absent. I'm trying to find a balance between caution and paranoia.
XSLT + Docbook FAQ