You're talking to it. If you have questions about contributing to
code, this (or #tor-dev on IRC) is probably the best place to start.
- Sai
On Thu, Apr 26, 2012 at 02:23, 九零后 wrote:
> Hi, I come here from GSoc and want to join project Obfsproxy. But I can't
> find the co
Google "tor hidden service".
On Thu, Mar 29, 2012 at 22:36, Salva . wrote:
> Hello, I'm going to launch a website in TOR and I dont wanna it to be
> visible in clearweb.
> So I want my site was only accessible from TOR.
>
> Anyone knows how can I do this ?
>
> Thanks.
>
>
;, even though
the two are very similar phonetically (just one voicing difference).
While we're at it, homography is also a lesser concern — it'll mainly
come up when ensuring that parsing is unambiguous. (Granted, that's a
significant caveat. :-P)
- Sai
__
bbleBabble produces nonwords; as such it fails a basic requirement.
Making something merely look phonotactically valid isn't enough; it
has to be grammatically valid and composed entirely of known terms.
- Sai
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Reformatted again for your committing pleasure:
Filename: xxx-mnemonic_urls.txt
Title: Mnemonic .onion URLs
Author: Sai, Alex Fink
Created: 29-Feb-2012
Status: Open
1. Overview
Currently, canonical Tor .onion URLs consist of a naked 80-bit hash[1]. This
is not something that users can even
Authors
Sai, Alex Fink
Overview
Currently, canonical Tor .onion URLs consist of a naked 80-bit
hash[1]. This is not something that users can even recognize for
validity, let alone produce directly. It is vulnerable to
partial-match fuzzing attacks[2], where a would-be MITM attacker
generates a
) and distributed (i.e. not reliant on any centralized or even
coordinated authority). It simply assigns a memorable scenario /
phrase to each hash.
- Sai
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
ate a full set of templates;
there are some complicated linguistic interconstraints that make just
generating one without the other a bad idea.
Testing can be done in various ways, e.g. just asking subjects to
remember (both for recognition and input) a random hash-p
ut dictionaries — seems
pointlessly combative to me.
I suggest you try actually reading proposals before bitching about
them. We addressed most of the issues you mention in the proposal.
- Sai
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
out them, so that if any of it affects
the dictionary collation step we don't waste work.
Thanks,
Sai
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
t not technologically up to
speed yet.
I should emphasize that this is *not* a technical problem, it's a
problem of cognitive linguistics. Writing the code is relatively
trivial; it's just a simple parser / generator layer.
- Sai
On Wed, Dec 21, 2011 at 00:16, Nick Mathewson wrote:
>
from a discussion earlier today on tor-assistants.
Cheers,
Sai
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
12 matches
Mail list logo
