Alexander Færøy:
> Hey,
>
> On 2020/05/15 16:36, Jeremy Rand wrote:
>> The Prop279 spec text is ambiguous about whether the target is required
>> to be a .onion domain, but the implementations (TorNS and StemNS) do not
>> have that restriction. TorNS and StemN
Alexander Færøy:
> Hey Jeremy,
>
> On 2020/05/15 15:53, Jeremy Rand wrote:
>> FYI I already wrote a Prop279 provider that looks up the names via DNS
>> (it's aptly named "dns-prop279"); it does pretty much exactly what you
>> describe. It doesn't h
though I've never
tried testing that feature.
I originally wrote dns-prop279 for Namecoin purposes, but I see no
reason it couldn't be used to achieve DNSSEC support in Tor. If there's
interest in pursuing this, let me know, I'm happy to contribute.
Code is at https://github.
eady has access to. The
security properties of onion services can't be changed by this -- if
they could be, then this would be security by obscurity, which is a scam
that the Tor devs (and any other legitimate software developers) don't
engage in.
Cheers,
--
-Jeremy Rand
Lead Application En
#x27;s important to prepare
for in advance?), but I figured it's worth at least getting it onto your
radar.
Cheers,
--
-Jeremy Rand
Lead Application Engineer at Namecoin
Mobile email: jeremyrandmob...@airmail.cc
Mobile OpenPGP: 2158 0643 C13B B40F B0FD 5854 B007 A32D AB44 3D9C
Send non-securi
sent, and where would I find them (in both the spec
>> and the source code)? If not, is there any documented reason (e.g. "the
>> attack is too hard to pull off" or "we want to mitigate it but haven't
>> gotten to it yet") for the lack of mitigation?
>&g
t but haven't
gotten to it yet") for the lack of mitigation?
Cheers,
- --
- -Jeremy Rand
Lead Application Engineer at Namecoin
Mobile email: jeremyrandmob...@airmail.cc
Mobile OpenPGP: 2158 0643 C13B B40F B0FD 5854 B007 A32D AB44 3D9C
Send non-security-critical things to my Mobile with O
motivation for my inquiry was to
determine if I should be submitting patches to those clients to make
them mimic what Bitcoin Core does). Using a torrc setting would
probably provide some useful defense-in-depth in case a Bitcoin client
isn't doing stream isolation on its own.
Cheers,
- --
I am CC'ing Patrick from Whonix in case he wants to weigh in.)
Cheers,
- --
- -Jeremy Rand
Lead Application Engineer at Namecoin
Mobile email: jeremyrandmob...@airmail.cc
Mobile OpenPGP: 2158 0643 C13B B40F B0FD 5854 B007 A32D AB44 3D9C
Send non-security-critical things to my Mobile with OpenPGP.
Please
he
still-developed project Ricochet; Tor Messenger is an Instantbird fork
(similar to how Tor Browser is a Firefox fork).
(I don't have any answer to your actual question, which I guess is about
TorChat, hopefully someone else will chime in on that.)
Cheers,
- --
- -Jeremy Rand
Lead Applicat
k.
Cheers,
- --
- -Jeremy Rand
Lead Application Engineer at Namecoin
Mobile email: jeremyrandmob...@airmail.cc
Mobile OpenPGP: 2158 0643 C13B B40F B0FD 5854 B007 A32D AB44 3D9C
Send non-security-critical things to my Mobile with OpenPGP.
Please don't send me unencrypted messages.
My bus
tedly the documentation is pretty weak at the moment (and it
hasn't gotten much testing), but maybe you'll find it interesting.
Feel free to play around with the code and/or ask questions and/or
submit bug reports/patches.
Cheers,
- --
- -Jeremy Rand
Lead Application Engineer at Namecoi
uses DNS to talk to Namecoin software, but the difficulty of
doing stream isolation properly with DNS and the rather large set of
DNS features that have no relevance to many Prop279 providers suggest
that it's unwise to force that coupling.
Cheers,
- --
- -Jeremy Rand
Lead Application Enginee
would also be useful for OnioNS and GNS, but I guess that it would be
beneficial for DNSSEC.
Anyway, I don't have a strong view on whether using DNS as the
abstraction protocol is the right choice -- but it's good to have the
discussion, I think.
Cheers!
--
-Jeremy Rand
Lead Appli
things to your Tor instance (and I make
no guarantees that it's properly sanitizing the input that's passed to
Tor's control port).
Huge thanks to Jesse for OnioNS (on which this code is based), and also
thanks to Nick for sharing helpful info on this mailing list.
Let me know ho
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Jesse V:
> On 04/03/2017 05:01 PM, Jeremy Rand wrote:
>> Maybe this topic has already been brought up, but in case it
>> hasn't, I'll do so. I notice that Prop279 (onion naming API)
>> defines its own API rather tha
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Daniel Achleitner:
> On 2017-04-02 05:22, Jeremy Rand wrote:
>> (Thinking out loud.) It would be interesting to have some kind
>> of algorithm agility here. For example, a Tor client could send
>> a request for a Namecoin doma
damage this can do in practice, but caution is warranted in the
absence of evidence. Maybe looking up a few junk names immediately
after initial boot would be sufficient to fix this.
> We should probably add a security notes section for how to write
> plugins that aren't dangerous: a
e there would be complexity in implementing
stream isolation?).
Anyway, just figured I'd bring up the topic so that everyone's on the
same page regarding figuring out whether it's a good idea.
Cheers,
- --
- -Jeremy Rand
Lead Application Engineer at Namecoin
Mobile email: jeremyrandmob.
mecoin domain name, and the exit relay would return a
Namecoin merkle proof in the same way that it would return a DNSSEC
signature if were a DNS doman name.
Cheers,
- --
- -Jeremy Rand
Lead Application Engineer at Namecoin
Mobile email: jeremyrandmob...@airmail.cc
Mobile PGP: 2158 0643 C13B B40
string that looks like a .onion URL or a Bitcoin
address, even if they're not links.
Cheers,
- --
- -Jeremy Rand
Lead Application Engineer at Namecoin
Mobile email: jeremyrandmob...@airmail.cc
Mobile PGP: 2158 0643 C13B B40F B0FD 5854 B007 A32D AB44 3D9C
Send non-security-critical things to my M
Aaron Swartz made some compelling arguments
that Greg Maxwell's proof of impossibility of decentralized consensus
algorithms also applies to Zooko's Triangle.)
Cheers,
-Jeremy Rand
signature.asc
Description: OpenPGP digital signature
___
tor-d
teor:
>
>> On 12 Oct 2016, at 09:29, Jesse V wrote:
>>
>> On 10/11/2016 12:53 AM, Jeremy Rand wrote:
>>> It's also worth noting that it's been hard enough to get IETF to accept
>>> .bit (that effort stalled) -- adding a bunch of other TLD&#
lso be useful to have someone present from the I2P community, to
provide some perspective on interoperability between what Tor does and
what I2P does. (Or for that matter any other system that might use a
pluggable name system API with similar use cases to Tor and I2P.)
Cheers,
-Jeremy
signature.asc
De
nly place where it matters to Tor or Tor
Browser is when a non-TLS connection is established and the end user
wants end-to-end encryption+authentication, in which case .onion is
okay, but both A/ records and CNAME records are not. It's unclear
to me exactly what the mechanism shou
tever good will exists
at IETF right now), and I fully understand why this would annoy them.
I'm not really sure what the right mechanism is for a user to specify "I
want this request to either use TLS or be resolved to a .onion record"
(which seems to be the primary use c
o get an EV
CA-issued cert to cover their .bit domain name, due to the political
issues around the P2P names proposal at IETF.
I'm aware that Alec Muffett isn't at Facebook anymore, but perhaps he
would be able to offer feedback on what issues m
ra TCP port listening on the onion service, an HTTP header
sent by the onion service, or some other mechanism is an open question.
A.2
> g) Namecoin/Blockstart
I'm not sure what Blockstart is; is that intended to be Blockstack?
Cheers,
-Jeremy Rand
(Lead Application Engineer at Namecoin)
pecify exit relay pins might reduce those issues here. Of course, this
only is helpful for services that have a Namecoin domain name.
Would there be interest in this capability?
Cheers,
-Jeremy
signature.asc
Description: OpenPGP digital signature
Jesse V:
> On 09/27/2016 10:05 AM, Jeremy Rand wrote:
>> Namecoin also can be used for name-level load balancing, although I
>> haven't really carefully considered the anonymity effects of the load
>> balancing (e.g. does it open the risk of fingerprinting?), so that
&g
Jesse V:
> On 09/27/2016 02:27 AM, Jeremy Rand wrote:
>> Hello! I just had a chance to look through the latest state of the wiki
>> page (thanks to everyone who's been expanding it). I've added several
>> items to the security properties and drawbacks sections
Jesse V:
> On 09/27/2016 02:39 AM, Jeremy Rand wrote:
>> Relatedly -- I had some trouble summarizing some of the items in the
>> Namecoin section because the security, privacy, and scalability
>> properties of Namecoin are somewhat different depending on whether the
>>
Jeremy Rand:
> George Kadianakis:
>>
>> I made a wiki page for Naming Systems here:
>> https://trac.torproject.org/projects/tor/wiki/doc/OnionServiceNamingSystems
>>
>> Feel free to start adding information and links and make it look nicer.
>>
>>
de a mistake, please let me know.)
I notice that kernelcorn added an item to the "drawbacks" section of
Namecoin, which says "Hard to authenticate names." It's not entirely
clear to me what is meant by this item, so it's hard for me to evaluate
its accuracy.
Any cha
fficial.
>
> We really need to start serious work in this area ASAP! Maybe let's start by
> making a wiki page that lists the various potential solutions (GNS, Namecoin,
> Blockstack, OnioNS, etc.)?
I'd be happy to provide feedback on the Namecoin section of such a w
nts.
>
> How are you going to deal with this?
Hi,
It looks like you must have missed my message that answered these questions:
https://lists.torproject.org/pipermail/tor-dev/2016-July/011245.html
Cheers,
-Jeremy
signature.asc
Description: OpenPGP digital signature
__
grarpamp:
> Hi Jeremy.
Hey grarpamp,
Sorry for the delayed reply.
> In regard your post 'Tor and Namecoin' here...
> https://lists.torproject.org/pipermail/tor-dev/2016-July/011245.html
>
> In this thread prefixed 'Onioncat and Prop224' started and
> spa
Nick Mathewson:
> On Tue, Aug 2, 2016 at 5:10 PM, Jeremy Rand wrote:
>> Nick Mathewson:
>>> Hi, all!
>>>
>>> I've seen a couple of emails from people looking into new ways to do
>>> naming for onion services. That's great! Before anybody ge
rvices seems to be a prudent
step to take before any kind of adoption of Namecoin by Tor.
Hope this answers your inquiry -- let me know if I was unclear about
anything.
Cheers,
-Jeremy
signature.asc
Description: OpenPGP digital signature
___
tor-dev ma
a stream,
which is problematic if the name lookup needs to be done before
attaching a stream to a circuit.
It's likely that I'm just misreading the spec, but any chance you (or
anyone else) could provide some pointers here?
Cheers,
-Jeremy
signature.asc
Description: OpenPGP digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
George Kadianakis:
>
> Hello Jeremy,
Hi George, thanks for the reply.
> I'm a big noob when it comes to blockchains, namecoin, SPV clients and such,
> so
> I'm mainly going to focus on how to integrate this with Tor.
I know this isn't necessarily needed given t
is really good with reproducible builds (you probably
know him since he's the author of the Debian guest support in Gitian),
so I'm reasonably confident that a way to do it can be found.
I'd love to hear feedback on all of this.
Cheers,
-Jeremy Rand
Lead Application Engineer of Name
no one tried it?
Cheers,
- -Jeremy Rand
-BEGIN PGP SIGNATURE-
Version: GnuPG v2
iQIcBAEBCAAGBQJWifxjAAoJEAHN/EbZ1y0686cP/3kdRz3va8dZ056j4x9k+sd7
XJsfsj9eWJ/tPxdpppPsBIoseTVNrPSCOB/cJ/bc0Xl75KGQkHFsmGusnUp6kg9L
bwJK8wcNoO+s5EjjiY/Rk39UQTNJ3YKOaanvUnGXolYy4LtgU
t & work on it more.
If it is a big miss, then I might start with a smaller contribution.
Thanks,
Jeremy
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
100% okay and runs for several
>minutes before crashing on cells it doesn't handle properly.
>
>I'm happy to share my code with anyone interested.
Hi Jeremy!
This is great! Thanks for this. You should definitely post your code (link to
branch or .diff) to ticket #7572 [1] so s
I've been working on the volunteer project described here
https://www.torproject.org/getinvolved/volunteer.html.en#useMoreCores
but can't spend much more time on it.
Right now, I have refactored circuit_receive_relay_cell() in relay.c
(which calls relay_crypt() and eventually the AES crypt rou
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 09/29/2015 07:39 AM, Jeff Burdges wrote:
> On Tue, 2015-09-29 at 00:59 +0000, Jeremy Rand wrote:
>
>> The issue I do see is that SPV validation doesn't work well
>> unless you ask multiple peers to make sure that you'
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 09/28/2015 01:34 PM, Jeff Burdges wrote:
> On Sun, 2015-09-27 at 22:31 +0000, Jeremy Rand wrote:
>>
>> Hi Jeff,
>>
>> Thanks for working on this; Namecoin is definitely interested in
>> this effort. I have
GNU Name System to know how this issue affects it, if
at all.
Thoughts on this?
Also, trivial spelling nitpick: "Namecoin" is typically spelled with a
lowercase "c", like "Bitcoin".
Thanks again for working on this!
Cheers,
- -Jeremy Rand
-BEGIN PGP SIGNATUR
tor-browser-bundle.git/tree/gitia
n/descriptors/windows/gitian-pluggable-transports.yml
A number of Go projects are built in that Gitian script. It looks
pretty straightforward. (I haven't tested that Gitian script for
determinism, but I assume that Tor wouldn't be using it if it weren't
David and
Joseph have shared, Namecoin is probably going to (where feasible)
port to Golang (which Tor is successfully building reproducibly with
very minimal code). I'm curious whether the Tor devs have come to a
similar conclusion.
Cheers,
- -Jeremy
-BEGIN PGP SIGNATURE-
Version: G
ng Python), but maybe they'll learn something from your
notes, and maybe they'll be able to move things forward.
Cheers,
- -Jeremy Rand
-BEGIN PGP SIGNATURE-
Version: GnuPG v2
iQIcBAEBCAAGBQJV7OrfAAoJEAHN/EbZ1y06MgsP/ji+pb+yq5s4JgSxErv4ChRh
VXhhtmtTG4bP4IaGq0FPRcBDh6wPMQJaXxWJ
d just still on the
to-do list? I don't see any relevant ticket on Trac.
Thanks,
- -Jeremy Rand
-BEGIN PGP SIGNATURE-
Version: GnuPG v2
iQIcBAEBCAAGBQJV7Mt1AAoJEAHN/EbZ1y06nL8QAM4qhFMupoippBIvI4JwlLZ6
Vf4wNWA2/IY+62DQ4hpkPRPX/vT48lJIJnPXUxQ427ru
nk you will find that a number of users are unlikely to
exclusively use bookmarks and not use web links. Hyperlinks are an
incredibly useful feature which many users are not going to throw out.
From what I can tell, your argument makes certain assumptions.
Making other assumptions changes the resul
a .onion name
changes. So this isn't really a clear win for .onion -- it's a
tradeoff, and which is more "secure" depends on which end users we're
talking about, and what threat model we're dealing with. There are
probably a significant number of cases where Namecoin (o
s with a SOCKS5 client/server
> implementation and a stub control port implementation.
>
> A picture is worth a thousand words:
> https://raw.github.com/Yawning/or-ctl-filter/screenshots/or-ctl-filter
- -tor-i2p.png
>
> [snip]
Thanks Yawning, this looks very useful indeed.
-
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 05/20/2015 04:36 AM, Fabio Pietrosanti (naif) - lists wrote:
>
>
> On 5/19/15 4:43 PM, Jeremy Rand wrote:
>> Hello Tor-Dev,
>>
>> One of the criticisms of Namecoin which seems to be raised
>> sometimes is
target as you yourself described,
>>> so there might be room for collaboration.
>> I'm aware of OnioNS, but haven't yet had time to thoroughly read
>> the proposal. It's certainly on my to-do list, if nothing else
>> for cross-pollination of ideas.
>
>&
;t yet had time to thoroughly read the
proposal. It's certainly on my to-do list, if nothing else for
cross-pollination of ideas.
- -Jeremy
-BEGIN PGP SIGNATURE-
Version: GnuPG v2
iQIcBAEBCAAGBQJVW1WyAAoJEAHN/EbZ1y06VmgQANTvkb4YiQ513LKSERk77wFD
hNIhyFhcawSGXW1/GcJ8JJSxH1Z/MZrqVKaxYv
o endorsing
domain.bit, and not being a revocation of that .bit domain) in a way
that won't open up attacks on the .onion key's normal protocol usage?
I'll write up a more formal spec after feedback is received, just to
make sure I'm not missing some important d
cheaper service like DO, Linode, Vultr, etc. At
least DO and Linode would be trivial to setup.
In summary, there is no need to replace AWS, but instead to supplement
it with other providers and make the Tor Cloud project more robust.
-Jeremy
On Fri, Jan 2, 2015 at 6:10 PM, Vlad Tsyrklevich
with some select beta testers but I'm not
ready to make it public yet (some changes are expected). It is my idea
that once the final AMI is produced, the Tor Cloud project will not
have to publish another AMI unless wanting to change the instance
type, or other "infrastructure"
en recently went to the latest
> IETF in Hawaii to discuss it with some folks in person and we're
> going to update it after we review his feedback.
>
> All the best, Jacob
Good to hear that it's still being worked on; the Namecoin guys were
getting a little worried that
> and then filter it to decide the future deliverables of SponsorR.
Hi,
Is it worth mentioning Namecoin under section 4, since other naming
systems are mentioned?
Cheers,
- -Jeremy Rand
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
iQEcBAEBAgAGBQJUdQwxAAoJEFgMI9bDV/9q6vwI
Thanks George - that is where the discussion is happening. Unfortunately,
public participation is really limited in the CAB Forum. However, if you want
to help, please reach out to the individuals advocating against the proposal
(or submit your suggestions to me) to see if we can get a secure,
h is a legitimate
>concern. Perhaps after there's a spec Tor likes, some large
>organization concerned about preventing phishing could throw some
>engineering time at the problem.
Jeremy
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
(CCing to Namecoin dev list.)
- -Jeremy Rand
Lead Application Engineer, Namecoin Project
On 11/02/2014 11:48 PM, yan wrote:
> +tor-dev. tl;dr: Would be nice if there were an HTTP response
> header that allows HTTPS servers to indicate their .onion domain
> names so that HTTPS Everywher
//geti2p.net/en/docs/naming
>
Namecoin is playing around with a decentralized way of doing this.
We'd be happy to work with Tor in this area.
Cheers,
- -Jeremy Rand
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
iQEcBAEBAgAGBQJURUjNAAoJEFgMI9bDV/9qy3MH/2rf49cmo15GhVjF0nKeWQrq
2xg3waZiIRq5w
deadline? Or should I just post a link in an e-mail to the Tor-Dev
list? Also, does Tor prefer proposals in plain text, PDF, or some other
format?
Thanks,
-Jeremy Rand
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi
On 03/02/2014 09:33 PM, Damian Johnson wrote:
Hi Jeremy. I'll leave the rest of the questions to George but as for
this one, yes. It's perfectly fine to apply to multiple projects (or
multiple orgs). Be wary though about spreading yourself too thin.
Submitting a fistful of poor
#x27;s tough competition for one project
I can still be considered for the other? Or does GSoC only permit one
proposal per student per organization?
Thanks,
-Jeremy Rand
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
while I
haven't touched the YaCy source code, I think I'm a good match for this
project.
Do either of these sound like good proposals? Is one significantly more
likely to be approved than the other, so that I know which to submit?
Thanks,
-Jeremy Rand
_
72 matches
Mail list logo
