Re: Consolidating to Date.
- From: gordonb.ch1hi@xxxxxxxxxxx (Gordon Burditt)
- Date: Fri, 19 Mar 2010 15:57:33 -0500
With these crypto systems everything is simulated at home first of all
before committing it to the internet as encrypted email. Alice can
simulate Bob and decrypt her own message at home before sending the
encrypted message to him. Bob of course becomes Alice in return
Simulate the following problems, which *WILL* occur in real life.
Now tell me how you avoid getting your crypto message system out
of sync (causes problems for more than the one message in question)
in these situations. The classical One Time Pad has these same
administrative problems, but you're the one claiming that it is
practical for a real-world communication system. Alice may send
several messages after the lost one before Bob notices a problem
and asks for re-transmission.
Messages get lost (even properly addressed ones). Sometimes this
occurs for email due to servers running out of disk space, power
failures, long downtime of a destination server, etc. (How do you
decrypt subsequent messages?) Sometimes it's misfiring SPAM filters.
Messages are duplicated. If you think about it for a while, in any
communication over a lossy medium, it's impossible to ensure that
two parties communicating agree on whether the message was successfully
sent between the two parties. (In particular, if the last required
acknowledgement gets lost or delayed, one side may think it failed
while the other thinks it succeeded. I've seen this happen in real
life on loaded SMTP servers, to the point that mailbombing was
suspected.) There's a classical problem about two military commanders
agreeing to both attack (victory assured) vs. having only one attack
(certain defeat) by sending messengers (who may be captured or
Messages get corrupted. This is why things like checksums, CRCs,
and MACs are used. However, these aren't perfect.
Messages arrive out of order. This may happen due to retransmission
because of corrupted messages.
An adversary sends a fake message that looks real enough that you
try to decrypt it. (See phishing and all sorts of scams.) The fake
messages may outnumber real ones by 10:1.
Note that UDP doesn't guarantee against packet loss, packet
duplication, out-of-order reception, and it has no 100% protection
against corrupted packets (*16-bit* checksum).
After that is up to the communicatons infrastructure
which is as reliable as you know how - I have never known a computer
to misread machine code yet ?
You think there's no reason for ECC memory to exist? (Even though
most consumer-grade PCs don't use it, high-end servers do, and they
*DO* correct errors occasonally). That there's no reason to put
CRCs on sectors for floppies, hard disks, CD-ROM, DVD, etc.? (Yes,
I've seen CRC errors on floppies, hard disks, and CD-ROMs. Especially
floppies). You think transmission errors don't occur on modems?
That messages sent by radio (think cell phone calls, WiFI, Bluetooth,
or military battlefield communications) can't have errors, even
with weak signal, noise, competing signals on the same channel, and
possibly someone attempting to jam it?
Wow. You must have tremendous luck or you've got your eyes shut.
Cell phone companies even advertise having fewer (not none) call
drops than the other guys.
I agree it needs to be proved over a
longer time span - Many thanks for your interest - adacrypt
In your encryption setup, if you have N communication partners, you
have 2N shared databases (one for each direction/partner). Somehow
you have to decide which one to use to decrypt it. How do you do
this without leaving necessary information unencrypted (in, say,
email headers)? Can't this information be an advantage to an enemy?
(E.g. emails with the same ID are sent from the consulate, somewhere
in the USA, and a farmer in their country. Doesn't this suggest
that the three are the same spy, even if they have no idea what's
*in* the messages?)
- Re: Consolidating to Date.
- From: adacrypt
- Re: Consolidating to Date.
- Prev by Date: Re: Consolidating to Date.
- Next by Date: Re: Is this a secure key derivation function?
- Previous by thread: Re: Consolidating to Date.
- Next by thread: Re: Consolidating to Date.