Forgot your password?

Comment: Re:Oh really ? (Score 2) 80

by Qzukk (#47569565) Attached to: Black Hat Researchers Actively Trying To Deanonymize Tor Users

Since you're not sharing, I'm guessing you're imagining some sort of multiplexing scheme where the node would take say 100 bytes from 14 different sources and combine them into one packet and send that. It's an intriguing idea that would slow down metadata analysis but it would have a lot of overhead to keep track of, but that "keeping track of" becomes an attack vector again especially with subverted nodes, since node B will need to know that the next 8 packets from node A will have 100 bytes of data that need to be kept together and sent on to node C.

If the network is busy it should actually not be bad for interactive small-packet connections. If the network is idle there could be a timer before the node fills unfilled slots with random data and sends it.

Comment: Re:Oh really ? (Score 3, Insightful) 80

by Qzukk (#47567501) Attached to: Black Hat Researchers Actively Trying To Deanonymize Tor Users

And sure as hell it is impossible to develop a mixnet that will generate Camouflage traffic

It would have to generate traffic in equal amounts for every flow, which would halve network speed to give an attacker a 50/50 chance of guessing the correct flow. Those fake flows would also have to be carried to something that looks like a reasonable endpoint as well.

PRISM-level metadata collection makes it trivial to see which computer sent the original 682-byte request (recurse as necessary until the 800 byte request starts at the "sender") as well as which computer the multi-megabyte response was sent to (recurse as necessary until the multi megabyte response returns to the requesting computer). Camouflage traffic can't fix this on its own, it's easy to exclude the data that wasn't requested from the analysis.

I think that Tor's best bet while maintaining performance at this point would be to round all packets up to the nearest MTU (lets say 1400 to account for PPPoE, VPNs, and other layers on ethernet), so every request and response becomes a multiple of 1400 bytes, would make most tracking rely on packet timing. The next step would be to introduce packet delays at each hop, but that will slow the already slow network down.

Comment: Re:No actual numbers (Score 1) 137

by Qzukk (#47524889) Attached to: Internet Explorer Vulnerabilities Increase 100%

The article, headline, story and comments are all bullshit.

Assuming the graph is not also bullshit, the correct story is that in the first 6 months of 2014 (1H 2014 on the graph), IE has had more vulnerabilities than all of 2013. IF this keeps up, then by the end of 2014, IE will have had more than a 100% increase in the number of vulnerabilities over last year.

User Journal

Journal: Holy shitballs, slashdot. Malicious ads being served up.

Journal by Qzukk

Love is over.

I was redirected to which dropped a java_installer.exe into my Downloads folder from some ad playing on around 2:30PM central time 7/24

Comment: Re:"Just let me build a bridge!" (Score 4, Insightful) 368

by Qzukk (#47518245) Attached to: 'Just Let Me Code!'

When you want to build a bridge, you don't just throw a bunch of construction workers at it and trust them to make the best judgements, even though you might trust each one of them individually to build a sawhorse or something equally trivial.

You also don't have the president of the company come in and declare that this week we're switching to agile bridge building and fuck six, we're going to seven sigmas so we can be on the bleeding edge and shift our paradigms into high gear to synchronize our release schedule and get out ahead of the pack as we swing around the final stretch into the processification.

Comment: Re:This would actually be useful the other way aro (Score 1) 205

by Qzukk (#47501215) Attached to: New Toyota Helps You Yell At the Kids

But just no, to the conversation mirror - most parents already don't keep their eyes on the road, we don't need to give them another excuse.

Ah, memories of my childhood. Things like my father flying down the freeway at 60 turning around in his seat and screaming "You look at me when I'm talking to you boy!" while everyone else screamed about oncoming traffic.

At the time I learned to drive, I considered my greatest achievement was being able to hold a conversation without looking at the person I'm speaking with.

Comment: Re:barf (Score 1) 154

That's also seen in bad console ports, by the way.

I've long since overcome my motion sickness (mom's van came with multiple barf buckets), but watching the screen move like I flicked google maps and it slowly pans to a stop (especially in any kind of curved motion) tickles the part of my brain that says "stop that, it's trying to make you sick".

Comment: Re:This is not how you inspire confidence (Score 1) 151

by Qzukk (#47476921) Attached to: LibreSSL PRNG Vulnerability Patched

Only if the master process quit after forking twice. This is not typical

No, this IS typical. The double fork allows the original process to interact with the user ("Enter your private key password:"), then exit and return 0 to the init script so init can print [ OK ] on your console.

The middle process needs to close file descriptors and do other cleanup then fork and die, causing the final process to become re-parented to init. Init then becomes responsible for cleaning it up if it dies, so it won't become a zombie.

Step-by-step "how to daemon" guide here.

Comment: Re:This is not how you inspire confidence (Score 4, Informative) 151

by Qzukk (#47471281) Attached to: LibreSSL PRNG Vulnerability Patched

OpenSSL's RNG is used in many places separately from the SSL communication protocol itself, sometimes just for encryption in general (S/MIME) or sometimes someone just wants really random bytes.

Many servers fork twice in order to reparent to init, repeated forking is a common idiom in unixland.

Apache with MPM-prefork forks a bunch of children from a master process, which is typically itself a descendant of apachectl. In apache's case, this shouldn't be a problem since the "master-process-rng" would have recognized the fork and reinitialized on the first openssl connection, so the children are protected because they cannot have the same PID as the master-process.

Where it would be a problem would be an application or daemon that starts up, initializes the RNG, forks twice, then without this fork touching the RNG, starts forking children to do something random (say, encrypting one file per process or establishing a single SSL connection per process or something). Without having the RNG reset by the master process, one in 65534 or so processes will have the exact same RNG, because it will have inherited the original RNG untouched and be assigned the PID that created the RNG.

Comment: Re:Rand Paul's a plagiarizing misogynistic racist (Score 2) 533

by Qzukk (#47466317) Attached to: Rand Paul and Silicon Valley's Shifting Political Climate

with fewer regulations for everyone

Ahahaha whoa there now, slow down sonny. Those regulations are there for a reason, mostly to keep people from competing against me and to make sure that nobody smokes anything I wouldn't openly admit to smoking. Let's back up to that low taxes thing.