>How do the does node A know node B’s ID and that the ID is really the one
of the B he/she wants to communicate with?  Isn’t the ID really just the
shared secret (credentials) Ralph mentions in his question?

The problem is that schemes tend to assume that Node A knows who Node B is,
(Alice knows that Bob exists and that Bob's name is Bob). To communicate
with any one in particular you must know a way of uniquely identifying
them, be that face, name, social security number. In all communication
schemes either you received that information using a secure communication
channel or you didn't.

This scheme does away with that prior condition. Node A doesn't know who
has that particular ID. How do any of us learn who we want to communicate
with, by communicating with other people. Node A merely selects that ID at
random.

It's like dialing a random phone number, maybe you have an interesting chat
and decide to talk to that person more, maybe you don't and you choose a
new partner to communicate with. Philosophically you must first learn who
you want to communicate with over the a communication channel, why not
secure the process of finding interesting people.

Of course you can always break all the messages sent to a particular id,
but if the network has a lot of traffic and decryption is expensive enough
(1 year-20 years), Eve is unlikely to succeed since she would need to get
the right packet for a particular id. Furthermore the first message should
be a public key, so that Eve could only decrypt prior messages if she
happened to get that first message.


On Thu, Jun 6, 2013 at 4:38 PM, Wyss, Felix <[email protected]> wrote:

>  How do the does node A know node B’s ID and that the ID is really the
> one of the B he/she wants to communicate with?  Isn’t the ID really just
> the shared secret (credentials) Ralph mentions in his question?****
>
> ** **
>
> --Felix****
>
> ** **
>
> *From:* cryptography [mailto:[email protected]] *On
> Behalf Of *Ethan Heilman
> *Sent:* Thursday, June 06, 2013 16:04
> *To:* Matthew Green
> *Cc:* Crypto List
> *Subject:* Re: [cryptography] Looking for earlier proof: no secure
> channel without previous secure channel****
>
> ** **
>
> Consider a network of N nodes each given an id from 1 to N, each node uses
> a protocol where any message it receives it decrypts with it's id. All
> messages get sent to every node instantly, and decryption has a very high
> cost.
>
> Node A wants to send a message to another node (node A just chooses an id
> randomly). Node A encrypts the message with the other nodes ID and sends it
> into the network. Node A has just securely communicated with another node
> (let say node B) without any prior secure channels and for another node to
> break that communication they must try ~n/2 decryptions. Of course A is
> blindly communicating with node B, but as long as node B wants the
> communication to be secure, the communication is secure and it requires no
> prior secure communications other than the protocol itself.
>
>
> ****
>
> ** **
>
> On Thu, Jun 6, 2013 at 3:12 PM, Matthew Green <[email protected]>
> wrote:****
>
> I assume you're talking about confidentiality and authenticity. If all you
> care about is authenticity then you can proceed under the assumption that
> the channel /may/ be authentic and then later perform the authentication to
> retrospectively authenticate it. This is obviously "duh", but it's also how
> modern protocol negotiation works.****
>
> ** **
>
> Matt****
>
> ** **
>
> ** **
>
> On Jun 6, 2013, at 2:32 PM, Jonathan Katz <[email protected]> wrote:****
>
>
>
> ****
>
> Isn't it obvious? (I mean, there is some value in formalizing the model,
> but still...)****
>
> Consider authentication of A to B. If there is nothing distinguishing
> (impersonator) Mallory from (honest) A, then anything A can do can also be
> done by Mallory.****
>
> ** **
>
>
> _______________________________________________
> cryptography mailing list
> [email protected]
> http://lists.randombit.net/mailman/listinfo/cryptography****
>
> ** **
>
_______________________________________________
cryptography mailing list
[email protected]
http://lists.randombit.net/mailman/listinfo/cryptography

Reply via email to