On 28 March 2017 at 10:57, Scott Fluhrer (sfluhrer) wrote:
> Sorry, I wasn't aware that unlinkability was a requirement...
Yeah, it's the only hard requirement. :)
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
Sorry, I wasn't aware that unlinkability was a requirement...
> -Original Message-
> From: Martin Thomson [mailto:martin.thom...@gmail.com]
> Sent: Tuesday, March 28, 2017 11:51 AM
> To: Scott Fluhrer (sfluhrer)
> Cc:
> Subject: Re: [TLS] The alternative idea
On 28 March 2017 at 10:48, Scott Fluhrer (sfluhrer) wrote:
> The server recovers E_K(R) because the client sent it (along with i and the
> protected message). It recovers R because it also knows K.
So E_K(R) is sent directly? That would link packets.
__
> -Original Message-
> From: Martin Thomson [mailto:martin.thom...@gmail.com]
> Sent: Tuesday, March 28, 2017 11:46 AM
> To: Scott Fluhrer (sfluhrer)
> Cc:
> Subject: Re: [TLS] The alternative idea I had for token buckets.
>
> On 28 March 2017 at 10:41, Scott Flu
On 28 March 2017 at 10:41, Scott Fluhrer (sfluhrer) wrote:
> E_K(R); that is, R is encrypted with the server's long term key.
>
> (I meant to specify that...)
OK, so how does the server recover E_K(R)? The point here is that it
doesn't know R.
___
TL
: [TLS] The alternative idea I had for token buckets.
>
> I'm sorry, but I don't understand this proposal. I'm losing you when you say
> E(R) without specifying the key that you are using.
>
> On 28 March 2017 at 10:21, Scott Fluhrer (sfluhrer)
> wrote:
>
I'm sorry, but I don't understand this proposal. I'm losing you when
you say E(R) without specifying the key that you are using.
On 28 March 2017 at 10:21, Scott Fluhrer (sfluhrer) wrote:
> Here’s how it would work:
>
>
>
> - The server has a long term secret key K, which it never gives
