to confirm that I can reproduce the issue without
stem (using bulb) [1]. It seems that the underlying issue should be
in little-t-tor and not in stem.
Or yes, maybe it's not even a bug (though it seems weird to me).
[1] https://github.com/nogoegst/onion-abort-issue
--
Ivan Markin
__
DER -RSAPublicKey_out | sha1
On GNU/Linux sha1 is probably sha1sum.
Happy hacking
--
Ivan Markin
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
-$ go get https://github.com/nogoegst/whatonion
+$ go get github.com/nogoegst/whatonion
Whoops, sorry.
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
/to/secret_onion_key
Hope it helps, enjoy!
--
Ivan Markin
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
ive?*
It's not a big deal really to parse onion address from a 'hostname'
file. Especially for an app that wants to know the protocol version (what
for?).
Personally I belive that there are no(t so many) apps that would
mess with onion services without using an onion-rel
o include examples with correct checksums.
--
Ivan Markin
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
0669feec96a146551c87109376f01b07ec065de1daa2b12da5fc2d8b8ae516b23d4a2cbe00edc11c87636c2f3d2129
a7wamxpb3krlclnf7qwyxcxfc2zd2srmxyao3qi4q5rwylz5eeu35xqd
--
Ivan Markin
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
On Tue, Jan 31, 2017 at 09:02:35AM +1100, teor wrote:
> How does an application tell the difference between a v2 and v3
> directory?
>
> What's the supported method, that we will continue to support in
> future, regardless of key or algorithm changes?
I guess by looking at the address and checkin
ss
generation. I guess (?) that it supposed to be SHA3-256 but it
definitely should be specified here.
I think that it just a typo since there is definition of H() above.
Thanks,
--
Ivan Markin
___
tor-dev mailing list
tor-dev@lists.torproj
hanging order has no effect (maybe should, like in
DER?). As a side effect plain-old-onion-addresses can be encoded here
(even with a checksum).
I'm not sure whether it's reasonable as it seems to me.
--
Ivan Markin
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
ason why dynamic linking has been invented was not to decrease
> the general executable sizes or to save memory consumption, or to
> speed up the exec() -- but to allow changing code during runtime --
> and that's the real purpose of dynamic linking, we shouldn't forget
> that
econds, and why it can't possibly be any worse under any
> circumstances.
Hmm, okay. I've created this ticket and submitted a patch there. :)
I just lost the point of this discussion and what steps should be taken
next with this delay.
--
Ivan Markin
_
Hi tor-dev@,
Ivan Markin:
> IMO an onion service should publish its first descriptor instantly. If
> something happens afterwards and one has to fix the descriptor - deal
> with it with backoff/delay to prevent DoS on HSDirs.
> I think that most of the ephemeral services are not going
sh "alias" v2 descriptors
without any intropoints and thus making no v2 service.
Thoughts, comments?
> ... that only informed power user will be able to understand what the
> hell is going on (but that we can maybe fix with good documentation,
> blog post and good practices guid
n't know if such transparent connection thing is secure or not. It
seems to be as secure as v2 services.
Thoughts?
--
Ivan Markin
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
s not anonymous.
* Yes, it does break end-to-end principle and makes the Internet less
fault-resistant etc, etc. Anyway, the Internet is already broken. Deal
with it.
** It definitely needs a proposal. :) Maybe I missed one? Something like
xxx-rsa1024-rend-id-migration.txt.
[1] https
hat way someone is going make huge
mistake(s). If crypto is bad, just put it into museum.
So I don't see _any_ reason to manage outdated and less secure system
while we have a better option (if we already deployed it).
--
Ivan Markin
___
tor-dev ma
So my two cents is to migrate to prop224 as soon as possible and make
everyone secure (RSA1024 and SHA1 are bd).
* Maybe just hostnames with variable length?
[1] https://trac.torproject.org/projects/tor/ticket/15951
--
Ivan Markin
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
ervices and I think also for HSs with OnionBalance
Same here. Most of the stuff that uses ADD_ONION is meant to setup onion
services instantly but has to wait 'until descriptor gets published'.
30s is too much.
--
Ivan Markin
___
tor-dev ma
I think it's safe to drop it back to at
> least 5s (3s?) for all services. Or even remove it at all?
The questions are:
* Can we drop this delay? Why?
* Can we set it back to 5s thus avoiding issues that can arise after
removing the delay?
* Should we do something now or postpon
Ivan Markin:
> Hi,
>
> I've also recently improved Atlas but it changes major part of the user
> experience. So this is a kind of Request For Comments.
>
> Most of the changes are my vision of how-it-should-all-look-like. The
> most notable changes are:
> * There is
on/deploy/atlas-new-design/
--
Ivan Markin
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
stem based on Onion Services, please
have a look at Ricochet [1]. I would be absolutely awesome if someone
port/implement/improve it on Android!
* The problem with XMPP is that there is a central system (server) to
which metadata is exposed in order to work. It's bad. :)
[1] https://github.com/rico
have a PIN-protected card for this to work.
* A bit tricky, I know.
--
Ivan Markin
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
ically, I'm currently creating such setup right now. I'm
transferring signed digests via UART]
[1]
https://gitweb.torproject.org/torspec.git/tree/proposals/250-commit-reveal-consensus.txt
--
Healthy bulbs,
Ivan Markin
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
re, but I want to create a small MVP ASAP).
Oops, should be fixed now. Thanks for noticing.
P.S. Please use direct email for such kind of issues to not to litter
the list.
--
Ivan Markin
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.t
ystem for Linux" or WSL. [1]
[1] https://en.wikipedia.org/wiki/Windows_Subsystem_for_Linux
--
Ivan Markin
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
an easily modify the applet to
have more than two signing keys (keep in mind that there are some card
limits).
[1] https://subgraph.com/sgos/documentation/smartcards/index.en.html
--
Have fun,
Ivan Markin
___
tor-dev mailing list
tor-dev@lists.torproject
but I think making Single Onion Service
> operators compile their own tor is unnecessary.
Gosh, it would be really inconvenient and nontransparent. And error-prone.
--
Ivan Markin
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
nymousOnionServiceMode 1"
should be enough. It looks pretty clear and simple.
[NB: a service cannot be Hidden and NonAnonymous at the same time :) ]
--
Ivan Markin
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
ising fingerprints, chemical
traces, serial number of the hard drive (with proprietary firmware!),
place of origin and other 'physical' metadata. It's not "just
ciphertext" in a vacuum.
--
Ivan Markin
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
So at what
point the source should stop the transmission
(size/time/etc)/change location or the guard/
pick new RP?
--
[1] http://panamapapers.sueddeutsche.de/articles/56febff0a1bb8d3c3495adf4/
--
Happy hacking,
Ivan Markin
___
So at what
point the source should stop the transmission
(size/time/etc)/change location or the guard/
pick new RP?
--
[1] http://panamapapers.sueddeutsche.de/articles/56febff0a1bb8d3c3495adf4/
--
Happy hacking,
Ivan Markin
___
> device or app) through usb port through armory to swissbit,
> that is never secure.
No, I will be secure. An adversary could sniff your PIN and sign
whatever they want to, true. But revealing the PIN != revealing the key.
In this case your identity key is still safe even if your P
of
frontend and then they can be included into a frontend descriptor.
[using OB terminology]
[*] Also there is still only RSA crypto in the OB.
[1] https://trac.torproject.org/projects/tor/ticket/15951
--
Ivan Markin
/"\
\ / ASCII Ribbon Campaign
Xagainst HTML email & Micr
y
you're protecting actual content to transmit over the net that is
already stored in plaintext. You may regard "onion" keys as "TLS
symmetric keys" because they are ephemeral and used "just for one
purpose". Keep in mind that these keys are disposable and
t think
that decrypting via SC is necessary. If somebody already knows your
backend keys then certainly they know any of your data on this machine.
Maybe I missed something.
[1] https://gitweb.torproject.org/torspec.git/tree/rend-spec.txt#n63
[2] https://gitweb.torproject.org/torspec.git/tree/r
y encryption so that it never has to see the private
> key used to unlock it. You would still need to trust the VM, but the
> encrypted container would allow you to establish a chain of custody.
It's OK to unlock some encrypted block device/VM with some 'unpluggable'
key. B
d use
> your smartcard/dongle/whatever to unlock the VM.
The point is that one can't[*] extract a private key from a smartcard
and because of that even if machine is compromised your private key
stays safe.
[*] Not so easy, but possible.
--
Ivan Markin
/"\
\ / ASCII Ribbon Ca
d key there is no need to decrypt anything
- they already have an access to the content on your instance. Also
backend instances' keys are disposable - you can change them seamlessly.
P.S. Notice about bandwidth issue when you're decrypting all of the
traffic on a smartcard (half-duplex, e
at provide readablity will provide
security then.
I think/hope so.
[1] https://github.com/mark-in/onionbalance
[2] https://github.com/mark-in/openpgpycard
[3] http://sourceforge.net/projects/javacardopenpgp/
[4] https://subgraph.com/sgos/documentation/smartcards/index.en.html
Hope it helps.
--
41 matches
Mail list logo
