Re: Are ++ and -- operators really more efficient



CBFalconer wrote:
Keith Thompson wrote:
If you can describe a way to generate a 32-bit check value that
can verify the identify of the poster, please enlighten me.

Bringing it down to one line would do. As you pointed out, I am
not any form of cryptographer. But my instinct tells me something
is available. What about - take the crc (maybe a 32 or 64 bit one)
and encode that with a private key. Send the message with an
X-header, specifying the public key. So the receiver decodes the
crc, runs a crc generator on the content, and compares. Without
the private key that is hard to duplicate, which is all that is
needed. The decoding is short, thus fast. The crc generator is
fast. Instantaneous confirmation.

I am just generating some ideas. I am not especially interested in
the result; I just want to eliminate the monstrous additions to
messages. Let somebody else work it out.

In fact, you're not far off from the best known solution: hash the data with a secure algorithm like SHA1 (not a weak one like CRC), sign the result with your private key, and include the public key in the message with the signature.

The problem is that, to do it right, the amount of information required is far more significant than you seem to expect. While the signature itself will be fairly small (e.g. the size of the hash's output, 160 bits for the case of SHA1), public key certificates are not. The signature in the sample signed message I sent a few hours ago in this thread comes out to 2175 bytes before base64 encoding -- and most of that is the public key and the signature by the issuing CA. Without those, a random receiver cannot validate the (relatively small) message signature, which is the entire point. If you know who the parties are prior to receiving the message, that information only has to be exchanged once, but that does not apply on USENET (or in email, in most cases) so the overhead has to be added to every message for the system to be usable. There is provably no shortcut.

I suspect that your main problem with PGP is not actually the size but that it includes all this cruft in the message body itself, where it assaults the eyes. S/MIME uses the same (strong) high-level design as PGP, but the signature and public key certificate are not in the message body and thus can be easily ignored by news (or mail) readers that aren't interested in them. MIME has been around long enough that virtually all software understands it, even if many programs still don't understand S/MIME signatures or what to do with them.

S

--
Stephen Sprunk "Stupid people surround themselves with smart
CCIE #3723 people. Smart people surround themselves with
K5SSS smart people who disagree with them." --Isaac Jaffe

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature



Relevant Pages

  • RE: Encryption question
    ... Digital signature is done by applying the ... sender's private key at the message hash. ... has the sender's public key to check. ... >Alice encrypts her email to Bob using his public key. ...
    (Security-Basics)
  • Re: CryptVerifySignature fail with message NTE_BAD_SIGNATURE
    ... signature, the public key is for verification and private key for signature. ... and verifying signing i am using " CryptVerifySignature(hHash, ...
    (microsoft.public.platformsdk.security)
  • Re: An old gem - private key encryption
    ... understanding of what a signature really is, ... the block is encrypted with the appropriate private key .." ... > I don't see the reason to ENCRYPT your buffer with the private key because ... > anybody can decrypt it anyway (assuming the public key is public). ...
    (microsoft.public.platformsdk.security)
  • Re: Encrypted key file as a software licensing scheme, advice(s) needed
    ... If anybody ever happens to find a private key which is compatible with your ... public key, the found private key will probably be different from yours. ... that case it produces a different signature from the same data. ... I believe you need to use padding when preparing the key file. ...
    (sci.crypt)
  • Re: Soft signatures
    ... now, digital signature, typically just represents that you (in ... For some time there were arguments that if a certificate contained the ... certificate with your public key and the non-repudiation flag in it. ... for a number of different business purposes. ...
    (sci.crypt)