On 11/08/2011 09:36 AM, George Kadianakis wrote:
Some arguments to consider against the tagging idea are:
c) We most probably won't be able to tag CA-signed certificates.
TLS 1.0 over TCP port 443 with a server cert rooting to a well-known CA
is probably the biggest stream of opaque traffic o
On 11/04/2011 09:19 PM, Watson Ladd wrote:
On Fri, Nov 4, 2011 at 8:01 PM, Julian Yon wrote:
What if the GET request can be anything innocuous (e.g. robots.txt,
index.html) and a valid document is sent back. But the headers include
an ETag derived in some way from the document content (or just
On 11/04/2011 01:39 AM, Jon Callas wrote:
It's certainly laudable to worry about TLAs with ASICs. They probably
can't break 80-bit crypto yet, but that's why you need to get off of
it now.
On the other hand, no TLA worth their salt is buying ASICs to crack
crypto. They are buying zero-day kerne
On 11/04/2011 08:01 AM, Robert Ransom wrote:
On 2011-11-03, Jon Callas wrote:
However, the safe, sane thing to do is use SHA-256.
SHA-256 sucks unnecessarily on 64-bit processors. Our fast relays are
64-bit.
It may be worth mentioning the newly-standardized SHA-512/256 here. This
is not
I too have been following the development of SHA-3 and will toss in my
2c here.
On 11/01/2011 06:50 AM, Watson Ladd wrote:
Turns out that almost everything you said about SHA3 vs SHA256
performance is wrong:
http://bench.cr.yp.to/impl-hash/blake256.html
http://bench.cr.yp.to/impl-hash/blake25
On 08/25/2011 03:08 AM, Karsten Loesing wrote:
Hi everyone,
we have been discussing sanitizing and publishing our web server logs
for quite a while now. The idea is to remove all potentially sensitive
parts from the logs, publish them in monthly tarballs on the metrics
website, and analyze them
On 05/06/2011 09:40 PM, Marsh Ray wrote:
On 05/06/2011 08:00 PM, Nick Mathewson wrote:
int mem_neq(const void *m1, const void *m2, size_t n)
{
const uint8_t *b1 = m1, *b2 = m2;
uint8_t diff = 0;
while (n--)
diff |= *b1++ ^ *b2++;
return diff != 0;
}
#define mem_eq(m1, m2, n) (!mem_neq((m1
On 05/06/2011 08:00 PM, Nick Mathewson wrote:
. The particular case that you mention is (I think) safe (see
discussion there),
I figured it probably was, but illustrated some red flags.
but the problem in general is worrisome and we
should indeed replace (nearly) all of our memcmps with
data
Greetings all,
I happened to download the tor-0.2.2.25-alpha.tar.gz source yesterday
and I noticed something. Apologies in advance if this has already been
discussed and resolved, I did a cursory web search and didn't see anything.
There are a lot of places in the code where memcmp() is call
