dakami

Funny you should ask. I just looked into this:

https://twitter.com/dakami/status/884715382061252608

Yeah. Ethereum blew up and all that compute is going towards GPU Mining.

My understanding (and please correct me if I'm wrong!) is that it's pretty easy to burn out FPGAs, electrically, in a way that it's not particularly trivial to do with other sorts of circuitry. So one downside of exposing your bitstreams is people are going to blow things up and demand new chips.

Rust isn't a sandbox. The whole point of a sandbox is it survives incorrect software at runtime. Rust is compile time magic. Sure, cool, different thing.

was that...like...a hundred megs for a web page?

We don't build houses (he said from San Francisco)

-D flag in OpenSSH.

No apparent backend integration.

Does Webstorm actually integrate with front end development? I'd like to whip together simple projects that aren't actually hideous, and literally every cloud IDE I'm finding just doesn't have a way to go from HTML5 code to WYSIWYG or even structured output...

Are your Win10 devices domain joined? Sounds like malware.

So I just started experimenting with ZFS, because it seemed required for container snapshots.

Then I found out it fragments badly, and nobody can figure out how to write a defragmenter. So, uh, keep the FS below 60-80% full apparently.

Yeah.

Ah, there you go. Repro code:

#/usr/bin/python

from random import *

count=0

def get_bit():

   global count

   count+=1

   if (count%2)==0:

      return random()<0.9

   else:

      return False

def get_fair_bit():

   while 1:

      a=get_bit()

      b=get_bit()

      if a!=b: return a

while 1:

   print get_fair_bit()

I'm wondering how often this one shows up the field -- my interest here comes from the ~1% failure rate of RSA keys in the field because manufacturers actually will not install hardware RNG or externally inject key material. Field vulnerability trumps religion. It looks like you need a really stateful vuln -- something akin to "a 1 is always followed by a 0 due to power drain" wouldn't be enough because the number of 0's is still acceptably unbound.

I know there are debiasers that look at statistics across a group. Wonder what else is out there.

I'm not convinced Von Neumann debiasing is vulnerable like you think. You're dropping runs (00's and 11's) so you don't care if it's 90% 0 or 90% 1, you care if there's an even number of a run or an odd number of a run.

In other words:

0000000000000001 000000001 001

...are all interchangeable. So biases can change all day.

There are _other_ issues I've seen in real world data, but not this one.

It's definitely based on my approach, but it's missing the concept a bit. The only way this approach gets entropy is if you cross two clocks at very different speeds, and get randomness from the mismatched tolerances. For example, using a computer's microsecond accurate clock to measure a human's 100 millisecond scale behavior yields bits, because we can't be microsecond accurate even if we try.

The bitflipping I was exploring involved matching the CPU clock (nanosecond scale) with the real time clock (millisecond scale). This of course has some risk because the OS can easily implement the latter with the former. And in fact, in this implementation, that's actually what happens -- he's measuring the number of bit flips at nanosecond accuracy. Output is distinguishable from PRNG, as seen elsewhere.

If I remember right somebody did break my "Defcon Challenge" with Firefox.

I'm interested in more of your perspective here. I was around back in the Mojo Nation era as something of an observer, but there's lots maybe I didn't see.

Where does he claim this?

That's exactly what makes this cool! Since we know the signed hash is a chunk from the Blockchain that is most assuredly not Sartre, we also know with cryptographic certainty that Wright does not possess a copy of Sartre with that hash. That would be what's known as a preimage attack -- given the hash from the Blockchain, find another SHA256 file with that hash. Wright could not even generate a malicious Sartre document with that property, without having executed a much larger crypto hack than Bitcoin itself.

He said something was X, we have cryptographic proof it's Y.

Everything before Bitcoin was really obsessed with anonymity, whereas Bitcoin was actually scared of centralization.

I like the metaphor that ants are "cells with legs".

Life really isn't constrained to any of our neat categorizations; life really is whatever works over time.

You might be right, you might not be, in the general case. In the specific case getaddrinfo is not performance sensitive (to say the least) and that entire block could be specially compiled 10x slower or run inside of a trivially available sandbox.

We have options we're not exploring.

Very specifically, I'm interested in exploit mitigations that eliminate undefined states, rather than just hope an attacker doesn't know enough to redefine them. One can show "zombie pointers" (fine, we've got lots of space in 64 bit land) will never allow an attacker to exploit a UaF much easier than we can show memory is randomized enough.

At the end of the day hard bounds checking (however slow it might be) also falls into this category of "approaches that do not try to survive falling into undefined states". I'm not saying ASLR et al isn't useful, just that we should put more energy intostaying within well defined states.

That's ultimately what "better" languages promise, after all. I'm curious if there are approaches that don't require rewrites, and very interested in actually measuring what does and doesn't absolutely suppress vulnerability, at what performance cost. We're not doing enough of that.

I've updated the post with further details.

No argument from me about the seriousness of issues like Rowhammer. Computers are built in layers, and layers require reduction to logical assumptions. The degree to which Rowhammer destroys logical assumptions is astonishing.

However, we've got lots and lots of common flaws that our present coding patterns aren't quite covering. This exact code written in JS wouldn't have been a problem. It wouldn't have been a problem even if it was just transpiled to JS and kept in a well defined sandbox (which isn't how we're doing sandboxing right now).

If this bug ends up traversing caches, it'll affect Amazon just like everything else. That the bug is so resistant to clear-cut answers on cache traversal vulnerability is unique, practically unprecedented.

What I'm saying is that a lot of energy has gone into "Assuming an attacker has gotten us into an undefined state, let's try to prevent them from pushing us into a chosen redefined state." And what I'm saying is, maybe we can create an environment where we don't end up in undefined states, or at least, there are bounds to how undefined they can be.

For example, I'm exploring ending use after free bugs by just not freeing memory. This sounds ridiculous until you realize that on 64 bit, leaking virtual memory (and therefore never recycling pointers) is actually not an insane idea, particularly for browsers that get to kill processes outright because they feel like it. Also, lots of UaF in there.

I stand corrected, there are in fact a decent number of people who mentioned HMAC(K,X)==HMAC(H(K),X) when len(K)>blocksize. So, you had no reason to cite Solar Designer and I shouldn't have implied you should. Sorry about that!

Still interested if you can find an earlier cite for HMAC collision. Most of what I find implies mad crypto cleverness, not this silly little construction.

Er, syntax without tax. ANYWAY

It's the crazy little things that people don't understand. You can't spell tax, without syntax.

Sure!

HMAC keys are exactly one block long. But lets say an app wants to have a key that's two blocks long. No big deal, hash that app key and now two is one.

Ah, but now let's say the attacker has control of input keys. He can provide both the two block key which HMAC will hash for him, or he can do the work himself and prehash the two into one. Now two different input keys seem to provide the same output (assuming identical messages, of course).

Clever, no likely security impact.

You're right. HMAC keys, from the internal hash perspective, are always one block long. So if the key coming into HMAC is less than blocksize, it's zero padded to blocksize. And if the key coming into HMAC is length greater than blocksize, it's hashed down to blocksize. Obviously this does create collisions if the key ends with nulls and is less than 64 bytes, or if the attacker can specify keys.

None of this likely matters in practice.