[
Lists Home |
Date Index |
Thread Index
]
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.
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.
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
practically.
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.
Dave Pawson wrote:
> On Fri, 2006-07-14 at 13:21 -0400, Mitch Amiano wrote:
>
>> https lets you send the data within a stream of packets of encrypted data.
>> The signature gives you confidence that an unencrypted packet of data
>> hasn't been altered.
>> To take a document and encrypt it, so it is unreadable without
>> decrypting, you could use encryption software such as GNU Privacy Guard
>> or an API's crypt function.
>>
>
> Would this be prior to or after 'signing' it?
> If xml-sig is an analogy of an sha1sum, surely after?
>
> I guess a 'standard' crypt library is good enough for data protection
> act, due care etc;
> though I do need one for a Java client and Microsoft server (which
> doesn't make
> for an easy life :-)
>
> regards
>
>
>
|
