Dan Kaminsky

I've been saying for a while [1] that data is liability -- this is a bit of a set piece I think I'll keep dragging out as new breaches are reported....

Or as Cory Doctorow puts it, personal electronic data is the nuclear waste of the information age.

http://www.theguardian.com/technology/2008/jan/15/data.security

I've also been increasingly coming of the opinion that, while concerns for oppression of the unprivileged and general population are my principle interest, it's actually the establishment: governments, business, banks, etc., who are more vulnerable, if only because they have greater secrets, historically greater control over them, and, in breached security, greater vulnerability to either attack or manipulation.

An exceptionally peculiar aspect of digital data is that, while it may remain in the boxes and cages provided for it, it's got a notable tendency to find itself liberated. Often without warning, and not detected for days, weeks, months, or longer, afterward (as in this case). In the real world we've got friction, especially associated with data processing and transfer. In digital form, far less so. Sometimes friction is good.

I'm still backlogged wanting to write about last year's Nude Celebrity Phone hacking. Dan Kaminsky, fortunately, has written virtually everything I could say on the topic and then some:

"Not Safe For Not Working On"
http://dankaminsky.com/2014/09/03/not-safe-for-not-working-on

In particular:

Victim shaming is par for the course…

My best guess is that Gavin has been duped by a sleight of hand (like a magician would use) by Craig.

My best guess, based on what I've read so far, is this:

- Gavin supplied his own text for the message.

- Craig faked running "sha256sum" on this message on his own laptop. The real "sha256sum" program could have been overwritten with a fake program that always output the same "hash". This is the "magic trick": the "hash" is attacker-controlled, and doesn't actually correspond to Gavin's message. Rather, the hash corresponds to an old message on the block chain - see, e.g., https://gist.github.com/ryancdotorg/893815f426f181d838c1b44aa187f05a

- Then from there, presto. The signature validates (and can be validated on Gavin's clean laptop) - because it's a real Satoshi signature, from the public blockchain years ago. But what it validates against is a "fake" hash - that Gavin thinks corresponds to his own message, but actually doesn't.

Easy to see how that would be a very, very convincing demonstration, after some social engineering. But all sleight of hand.

This is (I believe) why Craig has all this blurb up on https://dankaminsky.com/2016/05/02/validating-satoshi-or-not/ - it's to hide the trick, which is that he doesn't give us the file "Spartre". He supplies only a (presumably faked) screenshot of sha256sum against this file. Making you type in the hash by hand is misdirection, so you don't realise that you don't have the original file.

Excellent comment.

For reference, dvanduzer is most likely referring to this blog post and the exchange that took place in the comments: http://dankaminsky.com/2011/01/13/spelunk-tri/

First, let me answer your question, "Does Namecoin square Zooko's Triangle?"

Yes, I believe it does. Whether or not Namecoin works depends on whether or not Bitcoin works. They are the same exact technology (they're just used for different purposes).

From what I could tell of Dan Kaminsky's comments, I believe his arguments boil down to the well known 51% attack. Two things of note here:

1. See Dan's 2013 post on businessinsider where he appears to be retracting his words: "I Tried Hacking Bitcoin And I Failed" http://www.businessinsider.com/dan-kaminsky-highlights-flaws-bitcoin-2013-4

2. The 51% attack is still a real threat. The Bitcoin community is on it:

Proof of blockchain fair sharing is a draft Bitcoin protocol change
proposal by Iain Stewart, with the goal of allowing the network to
continue to settle on a sensible consensus blockchain even when
subject to a considerably- greater-than-50% attack.

The protocol is under construction. The following description is a
"teaser", establishing its basic flavour and sketching how it exploits
an asymmetry in the goals of the honest (<50%) and malicious (>50%)
miners to avoid the usual reductio ad absurdum argument against any
protocol surviving a >50% attack.

From:…

This looks to be the same technique as Dan Kaminsky's DakaRand, including the debiasing: https://dankaminsky.com/2012/08/15/dakarand/

See also Kaminsky's implementation of the same approach in pure JS: https://gist.github.com/PaulCapestany/6148566

and Ryan Finnie's implementation in Perl: http://www.finnie.org/2012/08/14/twuewand-2-0-released/

The big concern I have is how reliable this is on virtual machines. Just about all physical machines I'd want to use have high-quality, trustworthy-within-my-threat-model (i.e., "if the NSA wanted to attack my silicon, there's easier silicon for them to attack") hardware random number generators, and all physical machines I'd want to use pick up sufficient randomness from the kernel's entropy magic thing. But virtual machines often don't have access to the hardware RNG, and they don't have access to enough other hardware to populate entropy. It seems like this technique would be particularly risky there ... although I don't think anyone's published an attack on DakaRand yet, so maybe it's fine!

I'm somewhat surprised there is no reference to scanrand[1][2], a fast stateless syn scanner by Dan Kaminsky in 2002. It wasn't directly geared towards scanning the entire Internet, but instead scanning large subnets (like for a pen test of a /16 network... takes a long time to scan).

It is a bit obscure, but it did do tricks like encoding encrypted data in extra mutable fields (just the sequence number for scanrand) for validation purposes. Actually, scanrand 2.0 can apparently measure latency (without state!) by encoding timing information in the source port field, which zmap doesn't currently do.

I think this research is great, but I just hate to see interesting old projects get forgotten.

[1] http://dankaminsky.com/2002/11/18/77/
[2] http://www.sans.org/security-resources/idfaq/scanrand.php
[3] http://s3.amazonaws.com/dmk/SBO_Hiver.ppt

Way back when I saw a system for streaming audio via DNS: by using TXT records with a TTL of a few seconds, and updating them in a ring buffer, and by stuffing each record with a fragment of Speex encoded audio, you could get quite viable 2kbps audio streaming. Plus, you ended up with totally automatic and really effective edge-of-network caching.

This could have been Dan Kaminsky's DNS Radio idea, which he mentions here: http://dankaminsky.com/2004/08/01/50/

However, I haven't seen any actual code.