> On 8 Nov 2015, at 05:39, s7r wrote:
>
> For all versions of the proposal, regardless if we use the conflict
> code or not, I think we should require authorities to participate for
> at least for 3 rounds of the reveal phase, otherwise not participate
> in the shared randomness calculation for
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Hi,
I am fine with that.There is no sense going only half way here. So,
without the conflict code, there is no sense keeping a SR key. The
only source of authentication will be the normal signature of the vote.
We should keep the older version of t
On 06 Nov (15:35:50), George Kadianakis wrote:
> George Kadianakis writes:
>
> > s7r writes:
> >
> >> Hello,
> >>
> >>
> >>
> >> 4.1.1. Computing commitments and reveals [COMMITREVEAL]
> >> "The value REVEAL is computed as follows:
> >>
> >> REVEAL = base64-encode( TIMESTAMP || RN )"
> >>
George Kadianakis writes:
> s7r writes:
>
>> Hello,
>>
>>
>>
>> 4.1.1. Computing commitments and reveals [COMMITREVEAL]
>> "The value REVEAL is computed as follows:
>>
>> REVEAL = base64-encode( TIMESTAMP || RN )"
>>
>> * Maybe it is useful to also sign the REVEAL value with the SR key fo
s7r writes:
> Hello,
>
> Epic work. I agree that the code enforcing commit majority was not
> making a difference in the partition attack. I also agree that the
> partition attack is (almost) useless, expensive and very noisy. An
> attacker can get the same result if, instead of a partition attac
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
asn,
Is it possible to add a field called 'NOTARY' in the COMMIT and REVEAL
values where we include the SR pubkey + certificates and everything we
need so that we can validate each COMMIT / REVEAL value and tie it to
the identity of a directory auth
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Hello,
Epic work. I agree that the code enforcing commit majority was not
making a difference in the partition attack. I also agree that the
partition attack is (almost) useless, expensive and very noisy. An
attacker can get the same result if, inst
> On 31 Oct 2015, at 01:07, George Kadianakis wrote:
>
> Jesse V writes:
>
>> David,
>>
>> I'm in the midst of reworking my OnioNS design around prop250 (and the
>> security
>> analysis therein) and as far as I can tell these changes make sense. I like
>> the
>> 00:00 -> 24:00 change as it'
Jesse V writes:
> David,
>
> I'm in the midst of reworking my OnioNS design around prop250 (and the
> security
> analysis therein) and as far as I can tell these changes make sense. I like
> the
> 00:00 -> 24:00 change as it's more intuitive as you said. I was at first very
> concerned that you
teor writes:
>> On 29 Oct 2015, at 05:26, David Goulet wrote:
>>
>> Finally, we would like your opinion also on if we should keep the
>> conflict mechanism or not?. Since those partition attacks are basically
>> dumb, do not achive much result for an attacker and it's at a high cost
>> of compr
> On 29 Oct 2015, at 05:26, David Goulet wrote:
>
> Finally, we would like your opinion also on if we should keep the
> conflict mechanism or not?. Since those partition attacks are basically
> dumb, do not achive much result for an attacker and it's at a high cost
> of comprimising a directory
David,
I'm in the midst of reworking my OnioNS design around prop250 (and the security
analysis therein) and as far as I can tell these changes make sense. I like the
00:00 -> 24:00 change as it's more intuitive as you said. I was at first very
concerned that you removed the majority requiremen
Hello Tor-Dev!
We've almost completed the implementation [1] for prop#250 so we've
reviewed part of the proposal to correct part of it to reflect reality
(because you know a proposal is just wishful thinking until you
implement it :).
Attached is the new version that we've been working on. We wou
13 matches
Mail list logo
