On Tue, Oct 22, 2024, 4:15 PM wrote:
> On Tuesday, October 22nd, 2024 at 9:04 PM UTC, Watson Ladd wrote:
>
> > On Tue, Oct 22, 2024 at 3:47 AM stifle_savage042--- via tor-dev
> > tor-dev@lists.torproject.org wrote:
> >
> > > Hi all,
> > >
> > >
be willing to write a proposal draft. Besides
> implementation difficulty, is there any outstanding flaw in this idea?
Uh, yes. Depending on how we class implementation difficulty.
- A node can go offline before revealing to influence the random
choice. This is very hard to deal with in general.
On Tue, Jun 18, 2019 at 6:29 PM Chelsea Holland Komlo
wrote:
>
> There are a couple approaches to consider.
>
> POW via hashing goes for a relatively simple to implement approach.
> However, this incurs a high cost for all clients, and also environmental
> damage, per previous email.
>
> Another a
Some comments: some purely editorial, some substantive.
Editorial: stuff is xored with zero, the concatenation language is not used
consistently. I found it difficult to understand the proposed scheme and
check equivalence to the paper. Maybe some more words to explain the
layering would help.
Sub
On Wed, Apr 18, 2018 at 6:15 AM, George Kadianakis wrote:
> Hello Ian, isis, and other crypto people around here!
>
> Here is an intro: In HSv3 we've been using revision counters
> (integers++) to do HS desc replay protection, so that bad HSDirs cannot
> replay old descs to other HSDirs. We recent
On Sat, May 7, 2016 at 12:41 PM, lukep wrote:
> Jeff Burdges writes:
>
>>
>> On Fri, 2016-05-06 at 19:17 +, isis wrote:
>>
>> > --- Description of the Newhope internal functions ---
>> >
>> > gen_a(SEED seed) receives as input a 32-byte (public) seed. It expands
>> > this seed through
On Tue, Mar 4, 2014 at 7:05 AM, Nick Mathewson wrote:
> On Mon, Mar 3, 2014 at 10:37 PM, Watson Ladd wrote:
>
>> How about 6: Tor server to server connections should use
>> ECDHE+ChaCha20 or GCM_AES ciphersuites only?
>> This closes the UKS hole that enabled th
; server
> communication use the v1 link protocol again. (That's the one where
> both sides present a certificate chain in their TLS handshake. We
> moved away from it because of protocol fingerprinting issues, before
> we'd hit upon pluggable transports as a better m
Is it just me, or is this protocol MQV with the client generating a
fake long term key?
Sincerely,
Watson Ladd
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
On Tue, Oct 8, 2013 at 4:49 PM, Mike Perry wrote:
> Jurre van Bergen:
> >
> > *OTR*
> > OTR support comes from the Go crypto package:
> > https://code.google.com/p/go.crypto/
> > This library only has support for OTRv2 and not the latest OTRv3
> > specification. If we want to be resistant to seve
On Thu, Nov 29, 2012 at 11:07 PM, Mike Perry wrote:
>
> Thus spake Nick Mathewson (ni...@freehaven.net):
>
> > Title: Improved circuit-creation key exchange
> > Author: Nick Mathewson
> >
> > Summary:
> >
> > This is an attempt to translate the proposed circuit handshake from
> > "Anonymity a
On Thu, Aug 9, 2012 at 2:10 PM, Robert Ransom wrote:
> On 8/9/12, Watson Ladd wrote:
>> On Wed, Aug 8, 2012 at 8:22 PM, Robert Ransom
>> wrote:
>>> On 8/8/12, Nick Mathewson wrote:
>>>
>>>> Michael Backes, Aniket Kate, and Esfandiar Mohammad
rd.
Do you think a DDH oracle cracks CDH in Curve25519? If no the theorem
says something.
>
>
> Robert Ransom
> ___
> tor-dev mailing list
> tor-dev@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Sincerely,
Watson Ladd
--
"Th
On Mon, Mar 12, 2012 at 9:04 AM, Robert Ransom wrote:
> On 2012-03-12, Watson Ladd wrote:
>> On Sun, Mar 11, 2012 at 10:45 PM, Robert Ransom
>> wrote:
>
>>> (The BEAR/LION key would likely be different for each cell that a
>>> relay processes.)
>> Dif
On Sun, Mar 11, 2012 at 10:45 PM, Robert Ransom wrote:
> On 2012-03-12, Watson Ladd wrote:
>> On Sun, Mar 11, 2012 at 8:32 PM, Robert Ransom
>> wrote:
>
>>> But http://www.cl.cam.ac.uk/~rja14/Papers/bear-lion.pdf and an
>>> end-to-end MAC is more likely as
mmodity
bandwidth with commodity hardware!
>
>
> Robert Ransom
> ___
> tor-dev mailing list
> tor-dev@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Sincerely,
Watson Ladd
--
"Those who would give up Essential Liberty to purch
er of making 1 application that works for
all threat models so that we can discover and root out bugs faster?
Sincerely,
Watson Ladd
--
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither Liberty nor Safety."
-- Benjamin Franklin
about. If you have
alternative ideas that's also good.
Sincerely,
Watson Ladd
-- Forwarded message --
From: Robert Ransom
Date: Thu, Feb 16, 2012 at 8:03 PM
Subject: Fwd: Plan of attack for part (c)
To: Nick Mathewson , George Kadianakis
Cc: Watson Ladd
Forwarding to Nick
On Tue, Jan 31, 2012 at 2:57 PM, Nick Mathewson wrote:
> On Tue, Jan 31, 2012 at 3:35 PM, Roger Dingledine wrote:
>> On Tue, Jan 31, 2012 at 10:04:21AM -0500, Nick Mathewson wrote:
>>> On Mon, Jan 30, 2012 at 1:34 AM, Roger Dingledine wrote:
>>> > So it looks like Tor would get two new libraries
aLoFQLzCvw7ruBBXu8j0Ghw5Q
> hcm8RMIa4UyB0szSpMqkt615sYQBgy7hhEkNKqxnfdP4zIqUIK8mJqBING6r7qU+
> EhnIT5VNzKG9FZPkYNzXOvzbtH0MegNfePsi6gDYlkjR7gekiT9wYH9n5tFTPQUu
> 4BwqaaHR/Wk+zfHaQOmz+KC3eefUqcd+XP82mcPTSUDj4mzG1Sio2ZHKX0IeJVw=
> =r0da
> -END PGP SIGNATURE-
>
places (getting to know Tor code)
I've got a more basic question: does the OP get enough information to
validate the DNSSEC data, or does it have to trust the OR? I don't
quite know enough to tell from the above.
Sincerely,
Watson Ladd
--
"Those who would give u
On Jan 16, 2012 2:38 PM, "Ian Goldberg" wrote:
>
> On Mon, Jan 16, 2012 at 03:16:31PM -0500, Nick Mathewson wrote:
> > On Sun, Jan 15, 2012 at 4:15 PM, Ian Goldberg
wrote:
> > [...]
> > > FYI: it's now been accepted to the Designs, Codes, and Cryptography
> > > jounral:
> > >
> > > http://www.spr
On Jan 14, 2012 8:55 AM, "Ian Goldberg" wrote:
>
> On Fri, Jan 13, 2012 at 08:18:06PM -0600, Watson Ladd wrote:
> > Dear all,
> > After thinking hard about the issues involved with new cryptography in
> > Tor I came to the following idea for a somewhat reason
;t addressed the problem of UDP transport: TLS has issues where
instead of sending another packet to be processed by the next router
it resends a dropped packet, holding up the queue.
I've probably missed a lot of issues here, but hopefully this
Note that the data sent from Alice to En is encrypted with a key only they
share, rendering this attack impossible.
On Dec 17, 2011 11:25 AM, "Daniel Cohen" wrote:
> Hi,
>
> I am new to Tor, but after reading about its design, and reading a few
> research papers on its vulnerabilities (specifical
On Fri, Nov 4, 2011 at 11:35 PM, Marsh Ray wrote:
> On 11/04/2011 09:19 PM, Watson Ladd wrote:
>>
>> On Fri, Nov 4, 2011 at 8:01 PM, Julian Yon wrote:
>>>
>>> What if the GET request can be anything innocuous (e.g. robots.txt,
>>> index.html) and a va
On Fri, Nov 4, 2011 at 8:01 PM, Julian Yon wrote:
> On 04/11/11 21:37, Watson Ladd wrote:
>> On Fri, Nov 4, 2011 at 4:10 PM, Robert Ransom wrote:
>>> | Should the client send a string of the form "GET
>>> | /?q=correct+horse+battery+staple\r\n\r\n" inst
+horse+battery+staple
and the response is garbled data, not an HTTP response, its probably
something unusual.
Bridge descriptors should include enough information for Tor to ensure
that the TLS connection is
safe. If we are protecting against passive scanning then we just need
to make it look like
mplementation that is quite nice to use in the form of
NaCL. Signing is implemented along
with batch signature verification (not in NaCL yet, but written). NaCL
is also a lot nicer to use
then OpenSSL, and is very fast (and ensures it always goes the fastest).
Sincerely,
Watson Ladd
>
> -
budget of
Golden Shields regular activities, the price drops.
Sincerely,
Watson Ladd
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
ts zig-zag attacks: there are no
clients who see bridges in two distinct authorities mandate.
Unfortunately this only works if bridges are careful not to be listed
by multiple authorities.
Sincerely,
Watson Ladd
--
"Those who would give up Essential Liberty to purchase a little
Temporary Safety
be an impediment to migration.
Sincerely,
Watson Ladd
torspec.patch
Description: Binary data
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Dear All,
What precisely is the timestamp? Right now it says "number of seconds
since the Unix epoch" which leaves open TAI, UTC, or UT1. We probably
are using UTC so I should say that, but I just want to make sure.
Sincerely,
Watson Ladd
_
(the role of OPs in
processing
RELAY cells is also unclear). Is this the case, or is this not
supported given that there are no points at which the spec explicitly
calls for them to be sent?
Sincerely,
Watson Ladd
___
tor-dev mailing list
to
On Wed, Nov 2, 2011 at 11:45 AM, Robert Ransom wrote:
> On 2011-11-02, Watson Ladd wrote:
>> Dear All,
>[...omitted..]
>
>> Right now Tor encrypts the streams of data from a client to a OR with
>> AES-CTR and no integrity checks.
>
> Bullshit. We have a 32-bi
alsa20, and the nonce lengthened.
Sincerely,
Watson Ladd
---
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither Liberty nor Safety."
-- Benjamin Franklin
___
tor-dev mailing list
tor-dev@l
out, but I'm not
that worried: Patents filled
in the 2000s seem a bit late to the party anyway.
Sincerely,
Watson Ladd
On Tue, Nov 1, 2011 at 2:05 PM, Zooko O'Whielacronx wrote:
> A few pointers. On the happy "yay we can use it freely" side, we have:
>
> * RFC 6090
&g
On Tue, Nov 1, 2011 at 4:40 PM, Marsh Ray wrote:
>
> On 11/01/2011 03:06 PM, Watson Ladd wrote:
>>
>> GCM is a Wegman-Carter authenticator with polynomial evaluation in
>> GF2^128 as the universal hash and AES as the encryption. As NIST
>> pointed out, neither of th
are (last column is bits per second), and that was optimizing
for speed. In the case of Keccak, that performance is impressively
greater. Its possible at the 512 level these reverse, but I don't see
that in there.
Sincerely,
Watson Ladd
>
> Below my signature is just me quoting a few of t
s, and for signatures collision
resistance is still the most important thing. But sometimes we do depend on
random oracle assumptions in proofs, and SHA3 is designed to be a better
approximation to a random oracle then SHA2.
Sincerely,
Watson Ladd
--
"Those who would give up Essential Libert
SHA1s for key expansion
>> And the server does:
>> One RSA private-key decryption
>> A full DH handshake in Z_p
>> A short AES decryption
>> Five SHA1s for key expansion
>>
>> While in the revised handshake, the client does:
>&
41 matches
Mail list logo
