Hm, an hour later it succeeded:
May 17 20:40:43.000 [warn] Your server (...:9001) has not managed to confirm
that its ORPort is reachable.
May 17 21:00:43.000 [warn] Your server (...:9001) has not managed to confirm
that its ORPort is reachable.
May 17 21:20:43.000 [warn] Your server (...:9001)
> as you will rightfully point out because of things like windows returning -1
> but probably neglect things like redhat's patched-up version blowing up on
> invalid unicode sequences, etc.
clarified: windows snprintf() returning -1 on 0-length buffer inputs;
lacking nil-termination in some cases
> Win64 is the *only* flat-memory-space ABI ever promulgated in
> which pointers cannot safely be converted to 'unsigned long'
> and back without loss of information. This is a willful
> violation of requirements in C89 and is IMNSHO sufficient
> justification to refuse to port to this platfor
> Look more closely at those libevent headers: this is only the case on
> Windows. Yeah, it's at least arguably wrong, but it's not interfering with
> anyone else.
why on earth anyone thought this was a good idea ever is beyond me.
Even if we consider a 32-bit box with an OS that doesn't exist t
Hi,
I had to reboot my bridge for a (Ubuntu) kernel upgrade but now it cannot
confirm that the ORPort is accessible:
May 17 20:20:36.000 [notice] Tor 0.2.4.12-alpha (git-a1bb0df9be95ce7a) opening
log file.
May 17 20:20:36.000 [notice] Not disabling debugger attaching for unprivileged
users.
Ma
On 2013-05-17 11:32 PM, not me wrote:
... using intptr_t as a return value for socket() ...
Look more closely at those libevent headers: this is only the case on
Windows. Yeah, it's at least arguably wrong, but it's not interfering
with anyone else.
(This is on my list of things to fix in
On 2013-05-17 11:04 PM, Blibbet wrote:
On the positive side, it seems like many Win32 projects get about 15%
faster (when run on NT64 systems, removing the overhead of the Win32
subsystem)
Just one point of information: this is almost certainly due to the
larger register set and newer, more e
On 2013-05-17 10:07 PM, not me wrote:
Hi,
It seems fairly self-evident that tor hasn't been build for 64-bit
windows and questionable whether it's ever been built in an
environment that doesn't utilize mingw. There are literally hundreds
of thousands of warnings about integer truncation, at leas
> AFAIK, Tor has only been compiled as a Win32 app, never as a Win64 app.
More or less what I thought, tyvm.
> In the past, most of the time, Tor only builds on Windows with GCC/MinGW. But
> recently,
>Tor works primarily on Windows via MinGW toolchain, AFAIK still MinGW32. It
>has worked a few
adrelanos:
> George Kadianakis:
> > If we move to the higher security of (e.g.) 128-bits, the base32 string
> > suddenly becomes 26 characters. Is that still conveniently sized to pass
> > around, or should we admit that we failed this goal and we are free to
> > crank up the security to 256-bits (
> It seems fairly self-evident that tor hasn't been build for 64-bit
windows and questionable whether it's ever been built in an
environment that doesn't utilize mingw. [...]
...
AFAIK, Tor has only been compiled as a Win32 app, never as a Win64 app.
I realize that many/most/all of the develo
Hi,
It seems fairly self-evident that tor hasn't been build for 64-bit
windows and questionable whether it's ever been built in an
environment that doesn't utilize mingw. There are literally hundreds
of thousands of warnings about integer truncation, at least some of
which seem somewhat problemati
George Kadianakis:
> If we move to the higher security of (e.g.) 128-bits, the base32 string
> suddenly becomes 26 characters. Is that still conveniently sized to pass
> around, or should we admit that we failed this goal and we are free to
> crank up the security to 256-bits (output size of sha-25
> George Kadianakis:
>> Thoughts?
>
> Can you make .onion domains really long and therefor really safe against
> brute force?
>
Oh. That reminded me of a topic I forgot to insert in my original post.
An onion address is the truncated (80 bits) hash of the public identity
key of a Hidden Service.
George,
I would definitely create an extended transition time frame. 6 months or
a year where both keys will work. just make it clear there is a cut off
date.
And I think Adrelanos's concept is a valid one. Since we may need to do
this again, why not put a structure in place that facilitate
On May 17, 2013 11:29 AM, "David Vorick" wrote:
>
> Why are so many bits necessary? Isn't 128bits technically safe against
brute force? At 256 bits you are pretty much safe from any volume of
computational power that one could fathom within this century.
It sounds like you might be mixing up publ
On Fri, May 17, 2013 at 11:29 AM, David Vorick wrote:
> Why are so many bits necessary? Isn't 128bits technically safe against brute
> force?
Not for RSA keys. A 1024-bit RSA key is considered approximately as
strong as an 80-bit symmetric key; 2048-bit keys are approximately as
strong as a 112-
Symmetric cryptography (AES et al) key length - the 128, 256 etc bits
you are talking about - is not directly comparable to public/private
key cryptography, specifically RSA in this case. 1024 bits was
considered a good strong RSA key... in 1995.
On Fri, May 17, 2013, at 08:29 AM, David Voric
David Vorick:
> Why are so many bits necessary? Isn't 128bits technically safe against
> brute force? At 256 bits you are pretty much safe from any volume of
> computational power that one could fathom within this century. The only
> real danger is a new computational model that is nondeterministic
Why are so many bits necessary? Isn't 128bits technically safe against
brute force? At 256 bits you are pretty much safe from any volume of
computational power that one could fathom within this century. The only
real danger is a new computational model that is nondeterministic or
something crazy li
George Kadianakis:
> Thoughts?
Can you make .onion domains really long and therefor really safe against
brute force?
Or have an option for maximum key length and a weaker default if common
CPU's are still too slow? I mean, if you want to make 2048 bit keys the
default because you feel most hidden
On 2013-05-17 15:23 , George Kadianakis wrote:
[..]
> That is, when we change the identity keys of a Hidden Service, its
> onion also changes (since the onion is the truncated hash of its
> public key). This will be quite problematic for Hidden Services that
> have a well-established onion address.
Greetings,
I'm supposed to write a Tor proposal for the migration of the
long-term identity keys of Hidden Services. When I began writing the
proposal, I realized that some of my choices might not be appreciated by
Hidden Service operators, and that starting a discussion thread might be a
good ide
23 matches
Mail list logo
