format.
Robert Ransom
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
On 10/9/12, Nick Mathewson wrote:
> On Tue, Oct 9, 2012 at 12:31 PM, Robert Ransom
> wrote:
> [...]
>>> AES-CTR + HMAC-SHA512/256.
>>>
>>> AES-CTR + Poly1305. Poly1305 requires nonces, but we can use a
>>> counter for those.
>>
>&g
On 10/9/12, Robert Ransom wrote:
> On 10/8/12, Nick Mathewson wrote:
>> The second category (frob, encrypt, frob) is pretty elegant IMO. The
>> best-explained of these I've seen so far are in a
>> paper by Palash Sarkar [Efficient-Tweakable], though the earlier TET
&
tables,
> and get performance on high-end Intel boxes around 7-10 cycles per
> byte when doing GCM.) Full-on multiplication of two arbitrary
> GF(2^128) values is slowest still.
The obvious way to implement GF(2^128) multiplication of a large
number of secret inputs y by one learned-at-runtime secret c is:
* Compute a table of c*X^i for i = 0, ..., 127. (This table takes
128*128 bits, or 2048 bytes. Multiplication by X is easy and
tolerably fast.)
* For each input y (= y_0*X^0 + ... + y_127*X^127, with the y_i in
GF(2)), compute y_0*(c*X^0) + ... + y_127*(c*X^127). (You've done
this step for Pynchon Gate already; hopefully that runs in constant
time.)
> As a further wrinkle with GF(2^128), OpenSSL doesn't seem to actually
> expose its "multiply in GF(2^128)" functions as far as I can tell: we
> would need to snarf such code from elsewhere.
>
>
> Oh! ARMv8 has an optional crypto instruction set that supports AES,
> SHA256, and GF(2^128) multiplication [ARMv8]. If it looks like most
> of the ARMs we care about are going to get it, that could factor into
> our planning.
I won't believe claims that AES hardware will be widely available
until it actually is present in every new processor from a major
manufacturer.
Robert Ransom
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
believe TorSK was actually broken
> beyond Tor's current properties...).
Torsk relied on a trusted party to sign relay descriptors. Its goal
was to reduce the (asymptotic) total amount of directory
communication, not to remove the need for directory aut
cket
> 18:12 <@cjd> cjdns does the same thing
If this refers to including the circuit-extension packet which caused
a relay to open an OR connection in the first UDP packet that it sends
in order to open that connection, I agree that that would be a good
thing to do, although mostly for
Note that this scheme is not quite safe to implement with Ed25519 or
other DSA-like signature schemes as described; the base point needs to
be multiplied by the same number as the public-key group element.
-- Forwarded message --
From: Robert Ransom
Date: Wed, 19 Jan 2011 08:42
On 8/10/12, Robert Ransom wrote:
> On 8/8/12, Nick Mathewson wrote:
>
>> http://www.infsec.cs.uni-saarland.de/~mohammadi/owake.html
>
> Also, where does this paper specify that the participants must check
> that public-key group elements are not equal to the identity ele
is likely to break if
an attacker can force a server to open additional circuits to an
attacker using the same key material that a legitimate client's
circuit has.
Robert Ransom
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.
e-read and revise the
first few paragraphs of section 3.2. (Perhaps while they're at it
they can replace the mentions of ‘ppt’ algorithms and attackers
throughout their paper with a useful claim about execution time.)
Robert Ransom
_
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 Mohammadi have a paper in
>>> submission called, "An Efficient Key-Exchange for
On 8/9/12, aniket kate wrote:
>> Date: Thu, 9 Aug 2012 00:22:59 +
>> From: Robert Ransom
>>
>> On 8/8/12, Nick Mathewson wrote:
>>
>>> Michael Backes, Aniket Kate, and Esfandiar Mohammadi have a paper in
>>> submission called, "An Efficie
acr.org/1999/012), which requires only one
precomputed and one on-line exponentiation per protocol run on the
server when implemented with a slightly modified version of Ed25519.
(The client's performance is much less important than the server's.)
Robert Ransom
_
t?
Remove (or move) the port's ‘work’ directory and run ‘make’.
(You can't easily *install* an upgraded or recompiled FreeBSD port or
package without removing the old one, though.)
Robert Ransom
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
not
> published (if possible at all)?
Nothing. You also need to feed its descriptor to Tor using the control port.
Robert Ransom
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
>
> On Sun, Jul 22, 2012 at 2:26 AM, Robert Ransom
> wrote:
>>
>> Specifically, to obfuscate a ‘payload protocol’ data stream:
>>
>> * send it through an arithmetic-code encoder, using a model which
>> contains a (low-probability) ‘pad’ symbol;
>> * en
hat line). If They are using appid
with that particular protocol-recognition file, you win; if They
validate IRC using better regexps, you lose.
Robert Ransom
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
ossibly
truncated copy of that on the cell for transmission). (And now,
instead of specifying a particular authenticated encryption primitive
as Nick did, I'm specifying a particular AEAD primitive with a(n
extra) ‘chaining’ output. AE and AEAD are primitives themselves, not
things tha
s
corresponding ciphertext can recover the tweak.
Varying the tweak would allow an honest recipient to fail to decrypt a
cell if any previous cell was altered, but cells are not undecryptable
if only the tweak is unknown.
Robert Ransom
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
erprint in a descriptor is the hash of the relay identity key.
Robert Ransom
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
nd "bastikbridge" are
> similar? And are two IP address in the same, say, /30 located nearby,
> or is the same /28 or even /24 okay, too?
http://freehaven.net/anonbib/papers/pets2011/p1-perito.pdf
Robert Ransom
___
tor-dev mailing lis
e Tor.” (emphasis added) on
https://bugs.torproject.org/2289 . But when I explained on IRC that
there is a big difference between “this browser” and “your browser”,
no one believed that users would interpret them differently.
Robert Ransom
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
On 2012-03-26, Mike Perry wrote:
> Thus spake Robert Ransom (rransom.8...@gmail.com):
>> 3. Provide information about bridge sources to users
>>
>> BridgeFinder MUST provide complete information about how each
>> bridge was obtained (who provided
lays, thus contributing to the Tor
network rather than merely consuming its resources as a non-hidden
service would.
> Roger started writing up a spec on this and it can be found here:
>
> Filename: xxx-encrypted-services.txt
> Title: Encrypted services as a replacement to exit enclavin
Oh, I forgot to mention one requirement: check.torproject.org must be
usable by people who have turned off JavaScript in their browser
(whether TBB or not). That rules out XmlHttpRequest.
Robert Ransom
___
tor-dev mailing list
tor-dev
On 2012-03-23, Arturo Filastò wrote:
> On 3/23/12 4:34 PM, Robert Ransom wrote:
>> On 2012-03-23, Arturo Filastò wrote:
>>
>>> Since I noticed that check.tpo was removed from the front page I was
>>> thinking it would be a good idea to bri
On 2012-03-22, Mike Perry wrote:
> Thus spake Robert Ransom (rransom.8...@gmail.com):
>
>> [ snip ]
>
> Ok, attempt #2. This time I tried to get at the core of your concerns
> about attacker controlled input by requring some form of authentication
> on all bridge i
On 2012-03-26, Nick Mathewson wrote:
> On Mon, Mar 26, 2012 at 3:17 AM, Robert Ransom
> wrote:
> [...]
>>>(OpenSSL before 1.0.0 did not support ECDHE ciphersuites; OpenSSL
>>>before 1.0.0e or so had some security issues with them.)
>>
>> Can Tor d
ceptable to have a non-forward-secure link
> protocol[***]. None of these answers seems like a great one. Is one
> best? Are there other options?
The certificate-chain validation code and the v3 handshake protocol
would be a bigger issue with DSS or ECDSA ciphersuites.
>
> [**] Actually,
.
check.torproject.org cannot ever be run by untrusted parties, and
cannot ever use a JSONP service provided by untrusted parties.
> If check is moved to git and you think it is a good idea I can start
> working on this.
It is a more horrible idea now than it was the first time you propose
On 2012-03-16, Sebastian Hahn wrote:
>
> On Feb 10, 2012, at 12:02 AM, Robert Ransom wrote:
>> The sole exception to ‘non-safe cookie authentication must die’ is
>> when a controller knows that it is connected to a server process with
>> equal or greater access to th
On 2012-03-22, Mike Perry wrote:
> Thus spake Robert Ransom (rransom.8...@gmail.com):
>
>> [ snip ]
>
> I've updated the proposal to address your concerns at
> mikeperry/bridgefinder2.
>
> I've relaxed some of the requirements a little, but I think I
On 2012-03-22, Mike Perry wrote:
> Thus spake Robert Ransom (rransom.8...@gmail.com):
>
>> [ snip ]
>
> I've updated the proposal to address your concerns at
> mikeperry/bridgefinder2.
>
> I've relaxed some of the requirements a little, but I think I
ve not worked with TLS renegotiations before, but could Tor perform
> a renegotiation after the initial handshake, and the renegotiation
> ciphersuites are taken at face value? Less performant, but also less
> complicated?
Tor just got rid of TLS ren
On 2012-03-21, Mike Perry wrote:
> The following proposal should complete SponsorF tickets #5010-5012.
>
> I've pushed the proposal to my torspec.git branch
> mikeperry/bridgefinder, since the POSTMESSAGE Proposal ended up with
> some garbling at somewhere along the cut and paste chain. That branc
On 2012-03-12, Watson Ladd wrote:
> 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 dif
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.)
> Different how: if we simply increment the key we still remain open to
> replay attacks
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 a solution to the end-to-end tagging
>> attack, because (a) per-hop MACs
C, for
any MAC that Tor could use), you know with probability 2^(-n) that the
next hop is the last one.
(This sucks, because polynomial-evaluation MACs are faster and more
fun than most hash functions that would be suitable for
BEAR/LION/LIONESS.)
Robert Ransom
__
, thereby possibly denting Tor's link-protocol
forward secrecy if a bridge/relay is compromised soon after a
connection ends.
OpenSSL provides an implementation of session resumption, with the
code quality you should expect to find in a rarely-used piece of
OpenSSL. There have been several OpenS
at
>resolves to their IP.
>
>The simplest way to get a plausible commonName here would be to do a
>reverse lookup on our IP and try to find a good hostname. It's not
>clear whether this would actually work out in practice, or whether
>we'd just get dynamic-IP-pool hostnames everywhere blocked when they
>appear in certificates.
What if a bridge's IP address and reverse-DNS hostname change?
How does this interact with the v3 link protocol signaling mechanism?
How will a bridge's client be told what hostname to specify in its
server name indication field?
Robert Ransom
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
On 2012-02-29, Arturo Filastò wrote:
> On Feb 28, 2012, at 5:38 PM, Robert Ransom wrote:
>
>> On 2012-02-29, Arturo Filastò wrote:
>>
>>> When Tor is configured to use both a Pluggable Transport proxy and SOCKS
>>> proxy it should delegate the proxy
not read any PROXY line or it reads a PROXY-ERROR line
> and it is configured to use both SOCKS and PluggableTransport it should
> exit with error.
Are managed transports not permitted to report to Tor that they have
had a non-fatal error while attempting to connect to a proxy?
Robert Ransom
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
sulting names will be memorable. The
usability tests which will prove that your scheme does not provide
sufficient usability benefit to justify shipping many large
dictionaries with Tor cannot begin until after you have collected the
dictionaries.
Robert Ransom
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
. In
practice, this means ‘only if you're completely sure that Tor is
running in the same user account as the controller, and you're
completely sure that you're connected to Tor’, and no controller is
sure of either of those.
Robert Ransom
___
On 2012-02-07, Nick Mathewson wrote:
> On Sun, Feb 5, 2012 at 7:46 AM, Robert Ransom
> wrote:
>> See attached, because GMail would wrap lines if I sent it inline.
>
> Added as proposal 193.
Remember to push it.
> This seems like a general case of "A and B prove to e
testing
and a backport, and a few Trac tickets.
Robert Ransom
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
SAFECOOKIE handshake then this makes
> sense.
The old cookie authentication protocol exposes the *controller* to an
attack by (what it thinks is) Tor. Controllers which use PROTOCOLINFO
to determine which cookie file to use should be updated to remove
support for the old COOKIE protocol. Control
See attached, because GMail would wrap lines if I sent it inline.
Robert Ransom
Filename: xxx-safe-cookie-authentication.txt
Title: Safe cookie authentication for Tor controllers
Author: Robert Ransom
Created: 2012-02-04
Status: Open
Overview:
Not long ago, all Tor controllers which
On 2012-01-18, Nick Mathewson wrote:
> On Tue, Jan 17, 2012 at 1:28 PM, Robert Ransom
> wrote:
>
>> With that hack on top of the v3 protocol, any client able to detect
>> that a bridge is not being MITMed can impersonate the bridge through
>> the TLS handshake, unti
t's Telex ECDH key and the
Telex server's ECDH key. (This has the unfortunate side effect that a
client attempting to find Telex servers gives up forward secrecy for
its TLS connections.) This may be the part of Telex which requires an
OpenSSL patch.
Robert Ransom
detection for us, because we're using it
correctly for the first time since the v1 handshake. Profit.
* Add EXTEND2 cells so relay-to-relay connections can use v4 links.
Robert Ransom
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
it controls are used to
select a portion of the bridge pool. A more complex mapping of IP
addresses to bridge pool locations might work.
Robert Ransom
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
If so, how?
>In the end of a successful multiple round-trip protocol, an
>AUTHORIZED cell must be issued from the bridge to the client.
.-1s/multiple round/multiple-round/ # it's part of a phrase acting as
an ad-something
s/In/At/
> 4.3. AUTHORIZED s
On 2011-11-04, Robert Ransom wrote:
> On 2011-11-04, George Kadianakis wrote:
>>To avoid problems associated with the human condition, schemes
>>based on public key cryptography and certificates can be used. A
>>public and well tested protocol that can be u
;future authorization scheme is the SSH "publickey" authorization
>protocol.
Secret keys for DSA (with a fixed group) and EC-based signature
schemes can be short enough to be fairly easy to transport. Secret
keys for RSA are a PITA to transport, unless you either (a) specify a
d
y use a leading "$" to distinguish relay
identity-key fingerprints from relay nicknames; we should distinguish
new-style fingerprints by placing an algorithm identifier before the
"$".
> * Other comments. In the relay crypto comments, there was something about
> counter "in a less scary mode" -- just use what they describe in NIST
> SP800-whatever.
This is ‘less scary’ from the point of view of resisting side-channel
attacks. NSA was warned that array lookups with secret indices would
allow side-channel attacks. NSA told us to not worry about the
side-channel attacks. Now we know that we should have been worrying
about side-channel attacks all along, instead of just using the cipher
NSA told us to.
Robert Ransom
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
he first
protocol in the relay's list which (a) the client supports and (b) is
listed in the consensus as ‘approved’, unless the user specifically
configures the client to use a custom set of protocols. The
approved-protocol set in the consensus can both protect the anonymity
of clients which support new protocols and disable old protocols if
they break.
Robert Ransom
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
to a OR with
> AES-CTR and no integrity checks.
Bullshit. We have a 32-bit-per-cell integrity check at the ends of a circuit.
Robert Ransom
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
or its own, users who operate bridges can be deanonymized quite
trivially.
Robert Ransom
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
k we still won't add new versions to the list
reliably, and I assume you don't plan to add the many different TBB
version numbers to the list.
Robert Ransom
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
rectory which hosts older but still accepted as valid
> version of Tor which I did not see or is a torproject.org policy to just
> keep latest versions online?
Non-current Tor packages are somewhere on
https://archive.torproject.org/ . Current Tor pa
't know what confuses others, but IMO the
> proliferation of components that are all "tor" doesn't help me, and
> makes stuff slightly harder.
If these components were merged, I would have much more trouble
digging through a custom query to find a particular ticket.
Robert Ransom
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
things only more confusing for you (and for people who
> are new to Tor)?
The Trac wiki should die.
Most of the contents of the wiki consist of obsolete and/or bad
advice. These pages should be archived in a tarball where they will
not be readily accessible to web browsers and search engines,
build-bundle-
> installer.txt
https://gitweb.torproject.org/vidalia.git/blob/HEAD:/pkg/win32/build-bundle-installer.txt
Robert Ransom
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
nt per browser window. (Of course, you can and
should leave more detailed hooks in the browser's source if possible,
in case someone wants to experiment with a different scheme.)
Robert Ransom
___
tor-dev mailing list
tor-dev@lists.t
e,
> which can link me with temporary cache or session cookies.
The issue is that two different sites can use the sequences of exit
nodes to link a session on one site with a concurrent session on
another.
Robert Ransom
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
you maintain two long sessions within the same Tor Browser Bundle
instance, you're screwed -- not because the exit nodes might be
watching you, but because the web sites' logs can be correlated, and
the *sequence* of exit nodes that your Tor client chose is very likely
to be unique.
Robert Rans
tably, there is a link to
‘WikiFormatting’ above the ‘Comment’ entry box on every ticket.)
Robert Ransom
signature.asc
Description: PGP signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
gt; down the road.
The Tor Project cannot ship a backdoored product of any kind, *ever*.
No one would ever trust *any* of our hardware or software ever again,
and rightly so.
Robert Ransom
signature.asc
Description: PGP signature
___
tor-dev mailing
node leaks useful information about its
intended destination, as it does when using an ‘exit enclave’ and would
when using an exit node that exits to a small number of destinations.
Robert Ransom
signature.asc
Description: PGP signature
___
tor-dev
ning from a LAN-based computer to control it?
> The control port could autogenerate from the MAC address.
Vidalia is not designed to control or configure a Tor process that it
did not start.
Robert Ransom
signature.asc
Description: PGP signature
___
tor-
e bug, and thanks for finding and fixing it!
I'm setting up a cross-compiler now, and I'll compile OpenSSL and
libevent for Windows Real Soon Now, so this shouldn't happen again.
Robert Ransom
signature.asc
Description: PGP signature
__
report a ‘CANNIBALIZED’ circuit state in response to a ‘GETINFO
circuit-status’ control-port command?
Robert Ransom
signature.asc
Description: PGP signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman
khan/arm.git/commitdiff/5fd9b5f74a86eb7e641366ae1c0a1a47404cf873
> > titlewidth = max(map(lambda title: len(title), titles)) + 2
Why not “titlewidth = max(map(len, titles)) + 2”?
Robert Ransom
signature.asc
Description: PGP signature
___
tor-dev mailing list
void *procmon_);
This will break the build on libevent 1.x systems (until you merge your
bug3270 branch that #defines evutil_socket_t on such systems).
Robert Ransom
signature.asc
Description: PGP signature
___
tor-dev mailing list
tor-dev@li
tbb
> > is starting.
>
> This is a problem among many users, though one that is rather unrelated
> to anything Tor-specific. The solution to this is probably better
> startup notification systems, but that's very much out of scope for Tor.
We can't fix design flaws in
On Sat, 7 May 2011 00:57:12 -0400
Nick Mathewson wrote:
> On Sat, May 7, 2011 at 12:47 AM, Robert Ransom wrote:
> > On Fri, 6 May 2011 23:14:58 -0400
> > Nick Mathewson wrote:
> >
> >> Also, as I said on the bug, doing a memcmp in constant time is harder
> >
On Fri, 6 May 2011 23:16:14 -0700
Chris Palmer wrote:
> On May 6, 2011, at 10:25 PM, Robert Ransom wrote:
>
> > I would expect GCC (and most other C compilers) to use a
> > non-constant-time implementation of (v1 == v2).
>
> Are there machines that implement uint
On Fri, 6 May 2011 22:11:06 -0700
Chris Palmer wrote:
> On May 6, 2011, at 8:53 PM, Robert Ransom wrote:
> > GCC is likely to turn (v1 == v2) into a backdoor.
>
> Can you explain what you mean?
I would expect GCC (and most other C compilers) to use a
non-constant-time implem
a disassembly of
what GCC compiled DJB's functions to on a Fedora 12 AMD64 box. But I
couldn't tell that the technique was correct, so this time I added
comments to it.
Robert Ransom
int tor_memcmp(const void *x_, const void *y_, size_t len) {
const uint8_t *x = x_;
const
retval + diff;
> }
>
> return retval;
> }
GCC is likely to turn (v1 == v2) into a backdoor. Also, we would need
to make sure sign extension is constant-time; it *probably* is on IA-32
and AMD64, but we may need to disassemble the compiler's output to
verify t
.org/dist/vidalia/vidalia-0.2.12.tar.gz>.
I believe that these changes are appropriate, but they need to be
reviewed before they are put onto The Tor Project's website.
Robert Ransom
signature.asc
Description: PGP signature
___
tor-dev mailing
g trouble locating the new signing key. Any pointers?
That key is probably the one whose fingerprint is here:
https://trac.torproject.org/projects/tor/ticket/2621
Robert Ransom
signature.asc
Description: PGP signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
On Thu, 7 Apr 2011 17:18:12 -0400
Nick Mathewson wrote:
> On Thu, Mar 31, 2011 at 5:52 AM, Robert Ransom wrote:
>
> Hi! I'm going to wait on a full review of your create/extend proposal
> till it's done, but I though I could potentially answer some questions
> and of
On Tue, 5 Apr 2011 00:56:44 -0700
Robert Ransom wrote:
> On Mon, 4 Apr 2011 21:51:57 -0700
> "Jonathan \"Duke\" Leto" wrote:
>
> > Parrot recently added a GSoC proposal idea to embed Parrot into Tor.
> > It would be great to get the feedback from Tor
m within Tor via C
> 3) Write glue code for a High Level Language (HLL) to talk to libtor
I've never heard of ‘libtor’. What's that?
> There are various HLL's to choose from: Lua, TCL, Perl 6, Winxed, NQP
> and others.
Robert Ransom
signature.asc
Description: PGP signat
On Thu, 24 Mar 2011 01:28:42 +0100
George Kadianakis wrote:
> Nick Mathewson writes:
> >
> > On Wed, Mar 23, 2011 at 1:36 PM, Robert Ransom
> > wrote:
> >>
> >> The first step in the Great Tor Crypto Migration is to add new CREATE2
> &g
See below.
Robert Ransom
Begin forwarded message:
Date: 21 Feb 2011 02:51:21 -
From: "D. J. Bernstein"
To: curv...@list.cr.yp.to
Subject: curvecpclient+curvecpserver alpha test
Hi everybody,
I've posted information about CurveCP at http://curvecp.org; and today&#x
89 matches
Mail list logo
