Re: Hand Waving vs. Rigorous Analysis... (was Security Engineeringvs. Crypto Academics...)

• Previous message: Paul Rubin: "Re: original unix crypt program"
• In reply to: Joris Dobbelsteen: "Re: Hand Waving vs. Rigorous Analysis... (was Security Engineeringvs. Crypto Academics...)"
• Next in thread: Andrew Swallow: "Re: Hand Waving vs. Rigorous Analysis... (was Security Engineeringvs. Crypto Academics...)"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]

Date: Sun, 19 Sep 2004 21:29:07 +0200

On Sat, 18 Sep 2004 17:33:50 +0200, Joris Dobbelsteen wrote:

> "Ernst Lippe" <ernstl-at-planet-dot-nl@ignore.this> wrote in message
> news:pan.2004.09.18.09.03.54.640088@ignore.this...
>> On Fri, 17 Sep 2004 23:50:33 +0200, Joris Dobbelsteen wrote:
>>
>> > "Ernst Lippe" <ernstl-at-planet-dot-nl@ignore.this> wrote in message
>> > news:pan.2004.09.15.14.11.49.989714@ignore.this...

>> Disruptions in the communication with the key server are potentially
>> more troublesome than those in the communication with the broadcast
>> server. A
> short
>> interuption of the broadcast communication will prevent reception during
> this
>> interuption. Potentially a disruption in the reception of a new key from
> the
>> key server could prevent the user from watching the broadcast for the
> entire
>> validity period of this key, which is probably a much longer period.
>
> Disagreed.
I might understand why you disagree with the first sentence, but
I don't see what would be wrong with the rest of this paragraph.

> However, the point I'm trying to make, assuming the system is used in a
> conference that is happening at this time, the system has more points of
> failure than only the key server.
> The two most important one is the broadcast server. This is followed by
> the key server, the intrastructure and clients.
>
> Doing the proposed will ensure the key server will be reliable and failure
> of the key server will not cause many problems, except that new users
> cannot join the conference and key-changes are not possible. Failure of
> the broadcast server will result in no conference being possible.
> Intrastructure failure will result in no conference being possible for
> either everyone or some people participating (maybe the most important
> people).
> Client failure will result in some people not being able to participate.
>
> A short interruption of service will (most likely) result in a short
> interruption of service from both the key server AND broadcast server.
>
> In case the broadcast server is hosted by a third-party like Akamai and
> I'm hosting the key server (at the end of a DSL line), I would make use of
> your proposal, as the key server is not very reliable. In case both are
> hosted by me, I would choose to have a bit more control (allowing faster
> changes in policies) and not send many (if any) keys in advance.

But then your system will run into the type of problems that
Lassi described, after a large scale failure everybody will
be asking the key server for new keys. When you send the
keys just-in-time the key servers will be flooded with
requests for new keys. In this way you will have to dimension
your system that it can handle the case when all users request
a key at the same time. So immediately before the start
of a new key interval the systems and the network will be very
heavily loaded, and they will be mostly idle for the rest
of the time. Such a system is expensive and it is also very
brittle: when it is overloaded it will probably break down
completely. With my proposal the same hardware can service
a larger user group and it seems a lot more resilient
to overloads.

Ernst Lippe

• Previous message: Paul Rubin: "Re: original unix crypt program"
• In reply to: Joris Dobbelsteen: "Re: Hand Waving vs. Rigorous Analysis... (was Security Engineeringvs. Crypto Academics...)"
• Next in thread: Andrew Swallow: "Re: Hand Waving vs. Rigorous Analysis... (was Security Engineeringvs. Crypto Academics...)"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]