Re: Consolidating to Date.



On Mar 21, 6:12 am, gordonb.gs...@xxxxxxxxxxx (Gordon Burditt) wrote:
I think it could become a bit contentious to discuss hypothetical
system management bugs here but I think there are management solutions

What actual communication system does NOT have the problem of
corrupted messages or messages getting lost occasionally?  All of
these certainly have the problem:

- Talking face to face
- Talking over the phone (especially cell phones)
- Passing messages handwritten/printed on paper
- Postal mail
- Email
- Voice mail
- Sneakernet (flash drives, DVDs, or floppies passed hand-to-hand)
- Any communication protocol on the Internet
- Any communication protocol over radio (cell phones, WiFi, Bluetooth,
        long-range shortwave)
- Smoke signals
- Carrier pigeons
- Ads in newspapers

to every problem in this crypto system but first of all let me stake
out a few important basic facts for your perusal:

Please do not point to the historic OTP as an example in any
discussion - it doesn't fit any of the ciphers in hand - there's no
connection and it could become a damning untruth.  These are Vigenere
look-alikes (the OTP is in fact also a Vigenere adaptation) but they
are not OTP's.

I mention this primarily to point out that the management problems
are NOT unique to your ciphers, and I'm not only picking on your
ciphers.

Each channel comprises one only unique Alice / Bob pair of entities.

So when I receive a message, how do I tell which channel it came
in on, and therefore how (which database) to decrypt it?

Didn't you specify that there is a separate synchronized database
for each direction?  If not, you have the problem that if A and B
each start encrypting a message to the other simultaneously, they
will get their databases out of sync.  And there's really no way
to stop it without separate send and receive databases.  The problem
gets worse the longer the time between A sending the message and B
receiving it, or vice versa (machine-to-machine over the Internet,
little problem.  Postal mail, big problem).  And it's especially
likely to happen at a critical time when there is high message
traffic.

In practice Alice scrambles her server afresh each time => a lost
message means Bob cannot escape noticing this because he cannot ever
decipher the next message since he is now out of syn with Alice.

How does Alice know Bob is out of sync?  How do they re-establish
communication?  It is one thing to have a regular scheduled delivery
of new keying material by a secure channel.  It is quite another
to need such a secure channel on a moment's notice when one of the
parties may not have realized that communications are out of sync,
especially in an emergency when messages are flying back and forth.
It's *REALLY* bad if an adversary can deliberately cause this with
fake (or replayed real) messages at a critical time.



A case of misread machine code would mean an unreadable passage in the
decryption and alert the entities to retry or whatever else is needed.
I take your point that all of these hypothetical situations can happen
and it is beyond my ken to envisage even a few of what could happen in
reality.  This is why I am anxious to have these ciphers beta tested
by soneone who knows what they are doing.  I think there's enough
flexibility in the core cipher algorithms to adjust easily to anything
that is thrown at it.- Hide quoted text -

- Show quoted text -

I am taking onboard all of what you are saying and I have no doubt you
could go on for weeks tabling fresh
hypo problems:
< So when I receive a message, how do I tell which channel it came
< in on, and therefore how (which database) to decrypt it?

Off the top of my head I would say that the unsecured carrier email
will reference the ciphertext attachment - when I say that each Alice/
Bob pair is a closed unique loop I mean in crypto terms they are
securely isolated from corruption/confusion with other similar loops.
Hacker, error, attack attempts are not propagated from loop to loop
just by association. By comparison with mechanics and methods in some
physics ypu could envisage it as a system and boundary - nothing
crosses the boundary in this case - a closed system in other words.
But externally, all that ceases when the machine code goes into the
superhighway of electronic mail - the message as ciphertext and as an
attachment to an unsecured email covering letter simply has to take
its chances with all other mail at that stage.

How does Alice know Bob is out of sync? How do they re-establish
communication? It is one thing to have a regular scheduled delivery
of new keying material by a secure channel. It is quite another

Bob tells her - "couldn't decrypt your last message",

Then,- NB : The 'base' database never changes unless Alice changes it
- all interim external scarmbling of the databsesis done by ad hoc
scrambling parametres that Alice alone controls - it is quite easy for
herself and Bob to reset to any earlier time and resend any missed
messages. - they are back in sync again.

Didn't you specify that there is a separate synchronized database
for each direction? If not, you have the problem that if A and B
each start encrypting a message to the other simultaneously, they
will get their databases out of sync. And there's really no way

Yes - Alice is always the one who calls the shots for messages
emanating from her end - . (Note: the permutation space of all
possible databases - [(14250 **2) factorial] is out of this world) the
base database is used to set up new Bobs by means of a dedicated
permutation to each Bob - Then that base permutation remains unchanged
normally for the duration (but can be if needs be) and is scrambled ad
hoc for daily messaging between Alice and Bob in that direction only.
Any errors are safely reversible by resetting and resending with
fresh ciphertext.

What I'm saying here is coming off the top of my head quickly - if it
doesn't gel then there are still many other solutions in the locker.

Good to hear - keep coming - Austin.

.