1. Yet Another Dan Kaminsky Talk
(About much more than RNG)
Dan Kaminsky
Chief Scientist
White Ops
Special Guest: Ryan Castellucci, Security Engineer, White Ops

2. Back To Defcon!
• This is my thirteenth rodeo
• Why?
• It’s fun tech, but why this tech, why this place, why this way?
• Fundamentally subversive, even for Defcon
• Defcon loves to show what can be broken
• I love to show what’s possible
• We can scan the whole Internet, in seconds!
• We can bust violators of Network Neutrality!
• We can play video of Darth Vader doing Riverdance over DNS!
• Among other tricks involving DNS
• Like DNS rebinding and hacking home routers
• These are not actually the same thing
• So why are we here?

3. Subjects For Today
• Why do we keep getting owned by bad Random Number Generation?
• Users are expected to recognize and maybe even repeat complex
patterns, and they’re failing. Can we do better?
• What do we do about the infinite supply of Browser 0day?
• What do we do about DDoS, which is actually growing substantially?
• So, just how much did the NSA shit the bed?
• But first…I want to talk about why all this stuff we do is useful. By
discussing hard drives.

4. A Scenario
• An attacker has compromised a system, and put something malicious
on the hard drive. How bad could it be?
• Added an autolaunching daemon?
• Replaced core OS files?
• Put a virus in the MBR?
• Can you just wipe out the drive and be done with this?

5. What Is The Difference Between…
A Hard Drive A Brick

6. Given Sufficient Research, None
A Hard Drive == A Brick
==

7. Theory Vs. Reality: What Is A Hard Drive

8. Xzibit’s Iron Law Of Computer Architecture
• Yo Dawg, I heard you liked computers, so I put a computer in your
computer so you could compute while you compute
• This is basically how computers work – hard work is offloaded to hardware,
which is really just another computer that has a fast way to influence you
• Fast == trusted == insecure
• Everything is generic now – the iPhone has seven ARM chips
• The biggest lie about your computer is that it’s just one computer
• That hard drive is just another computer with direct access to your system
memory via specially designed protocols
• Doubt me?

9. From An Old Project with Travis Goodspeed:
Lets Get A Shell On This Here Seagate!

10. Oh Shell, You’re even self documenting!

11. Documents commands, their locations, their
arguments…

12. Get some internal drive metadata…

13. Learn about the disc you know…

14. …and the disc you don’t…

15. Can Even Read It Out…

16. Nice Test Code!

17. Don’t think that you need that serial link…

18. …or that I was kidding about making bricks
• Fate: Platters exposed, fingerprinted. Firmware dumped as 001.rom.
• Fate: Bricked by Dan when he wrote to the buffer. Probably
repairable.
• Fate: Bricked by dan with HDPARM, then sawed apart by Travis for
post-mortem firmware analysis.
• Fate: Semi-bricked by Dan by raising the serial port rate to 625000.
Repairable.

19. The Paper That Eventually Followed
• Implementation and Implications of a Steath Hard-Drive Backdoor
Jonas Zoldach, Anil Kurmus, Davide Balzarotti, Erik-Oliver Blass,
Aurelien Francillon, Travis Goodspeed, Moitrayee Gupta, and Ioannis
Koltsidas
• I’m an unindicted co-coconspirator 
• 10 months of solid reverse engineering to create the malicious
firmware payload
• Not at all the first time this has been done, but maybe the first time
publicly/academically

20. The Significance of the Research:
S^X (Storage XOR Execution)
• Highly desirable property for secure clouds
• “It’s not about ownage, it’s about continued ownage. It’s about coming back in a year and
having the door still open for you”
• Requires exploitation and persisted storage
• If your storage doesn’t parse, it can’t be exploited
• If your execution doesn’t store, there’s nowhere to persist
• You can’t start thinking about S^X if you think you already have it
• There are ways of building S^X out of existing gear – but nobody thinks you have to
• Nobody thinks you have to have exclusive hosts on cloud providers either 
• Thus, the value of hacker engineering
• No delusions
• Operation from first principles
• The best thing hackers break are assumptions
• We are needed.

21. I Believe In The Internet

22. The Internet Is Not Just For Us
• I believe in TexasGirly1979 having six and a half MILLION people loving her
damn cat
• Without Bob Saget, a laugh track, and a baseball to the testicles as followup
• I believe in responding to being told your music sounds like “rats being
strangled” by becoming a dubstep violinist and getting a half billion hits on
YouTube
• Remixing Skyrim and Zelda and Halo may have something to do with my opinion
• I believe in email over Interoffice memos, Skype over (very) plain old
telephone service, online banking over waiting for a bank teller
• And I believe we could lose it all, and there are some who might even
prefer that

23. The Thing To Remember
• The Internet was not the first time we tried to create the Internet
• It was like the 8th
• Prodigy tried
• Minitel tried
• America Online really, really tried
• Spent a billion dollars on modem lines!
• (They actually still make $160M/yr off that.)
• The Internet was free
• Not just free as in murka
• It was free as in no rent – all of the above wanted to charge transaction fees
• The Internet just wanted a few pennies a year for a domain name
• The free Internet has disrupted a heck of a lot
• Don’t think there are those who wouldn’t like to disrupt back

24. The Challenge
• We know what’s really possible
• We know that breaking everything, is really possible
• We don’t know that fixing everything, is really possible…
• …but technically, we don’t actually know fixing everything is impossible
• Technically correct is the best kind of correct
• So why do I do this, and why do I do this here?
• Because here, I see openness to possibility
• Including the possibility the Internet might turn into AOL
• I see the sheer joy of understanding the actual mechanisms at play
• I see the skepticism that allows BS – especially security BS – to be discussed
and recognized

25. Let’s Talk Random Number Generators
• “The generation of random numbers is too important to be left to
chance”
• Many processes require a generator of unpredictable numbers
• Last 1000 numbers don’t tell you the next number
• Last 1000 numbers also don’t tell you the number 1001 times ago
• That they require such a generator doesn’t mean they’re using such a
generator

26. What’s happening to all these web
frameworks
• You actually don’t log in very frequently
• Top 10 e-commerce platform: 7 logins a second, worldwide
• Logging in gives you a token
• If you’re lucky, it’s HMAC(who_you_are, key)
• In the real world, it’s often Random()
• Sure would suck if that wasn’t actually random…

27. Dominique Bongard’s (AKA @reversity)
Beautiful WPS Attack From #Passwords14

28. Details
• WPS Protocol assumes 128 bits of entropy in AES keys
• Reality: 32 bit LFSR, 32 bit LFSR, 0 bit (aeskey is always 0)
• 2**128: Big
• 2**32: Not so big (~4B, remember your CPU does that many operations in
seconds)

29. Why Do We Keep Getting Owned By Random
Number Generators?
• Wrong Answers
• “Because we used SHA-1 instead of SHA-256”
• Freaking MD4 would work
• “Because we used HASH_DBRG instead of HMAC_DBRG”
• “Because we used the same entropy for too long”
• “Because we had only one pool for mixing entropy instead of thirty two”
• There’s a thousand ways to build a CSPRNG (cryptographically secure
pseudo random number generator) and all of them would fail less than
what we’re doing
• Even forking/cloning VMs doesn’t fail this frequently
• Right Answers
• 1) No entropy
• 2) No CSPRNG by default

30. A Little Dab’ll Do Ya
• CSPRNG’s expand a little bit of entropy (128 bits) into billions of
gigabytes
• Best attack would be to brute force the 2**128 possible initial seeds and find
the one that matches the stream
• Good luck with that…unless there’s actually not even 128 bits
• There’s often actually not even 128 bits   
• Turn on a machine, no keyboard, no mouse, no disk…no entropy.
• 1/200 RSA keys on the Internet were badly generated, meaning actually
probably 1/50
• Heninger attack only found all identical private keys, not similar keys
• Private keys are just small chunks of randomness that ended up prime
• Shouldn’t /dev/random or /dev/urandom have prevented this?

31. Perfection Is The Enemy Of The Good
• Why we like kernel RNGs (/dev/random, /dev/urandom)
• Kernel code gets events from hardware
• General thinking is that event timing from foreign hardware is on a separate clock
• All good entropy is a fast clocked system measuring a slow clocked system
• Inter-keystroke timing from a human to the CPU nanosecond
• There’s also only one kernel
• If anyone gets entropy everyone gets entropy
• Operating systems are supposed to provide services that are easy to screw up
• Can get more complexity/correctness encapsulated in the OS rather than monkey-shoved into
each language or application
• What went wrong
• /dev/[u]random still fails when there’s no events coming in from the hardware
• No keyboard, no mouse, no disk == no events
• Yes, it’d be nice if there was hardware entropy generators, but not happening

32. Solving The True Entropy Problem
• You don’t have to be perfect every time
• You just need to be better than the ONE NINE OF RELIABILITY the status quo has
achieved
• Be embarrassed
• 1) Force synthesis of events
• 2) Don’t necessarily be afraid to do this in userspace
• Especially in a world of VMs, kernel is nothing but a single threaded process
• What this means
• Measure the real time clock (kilohertz at best) with the CPU (megahertz to gigahertz)
• Possibly do some work with non-deterministic time (atomic memory writes)
• Do standard whitening (Von Neumann – drop 00 and 11, 01 is a 0, 10 is a 1)
• This is the Dakarand (Truerand) approach. It may fail in some very rare scenario. It will
fail less than the status quo.
• Security means it’s OK to fail less.

33. Solving The True Problem
• Operating systems have /dev/urandom which is generally pretty good – but does
anything use it?
• JavaScript Math.Random(): no
• Ruby Random.rand(): no
• Java.util.Random(): no
• PHP rand(): no
• Glibc rand(): hellllllllllllllll no
• Standard RNG is LFSR or Mersenne Twister – if you want security, you’ve got to hunt
down some other API
• And it’s always funky and different!
Math.random();
var a = new Uint32Array(1); window.crypto.getRandomValues(a);
• How well does insecure by default work anywhere else?
• Pretty badly

34. The Obvious Question: Why not be secure by
default?
• Instead of requiring some special, magic, and consistently overcomplicated
API for Secure Random™, why not just have all random calls not be crap?
• Liburandy
• Silently hijacks standard randomness functions in common languages, backs them
with /dev/urandom (on Linux)
• Would be CryptGenRandom on Windows
• The OS already does this right, lets just hook dev intent to something that’s not busted
• Initial support for JS(Node, Browsers), Ruby, LD_PRELOAD (arbitrary libc), PHP,
Python. OpenJDK soon
• Ryan Castellucci of White Ops helping to write this
• Will eventually support some important runtime features
• Entropy Metadata (runtime will be defining security rather than source code)
• Fixed seed
• High speed mode

35. What’s Wrong With Liburandy
(Lets play chess against myself a bit)
• Two General Objection: Seed and Speed
• Seed: Useful for getting consistent test results (Random, but the same
random set)
• 99% of the time you see seeding, it’s C seeding time because people don’t want the
same random results
• Can set a special flag (environment variable)
• Speed: urandom is slower than LFSR/MT
• If you wanted it to be fast why are you writing in in ruby
• This is actually why things have been left crappy – so as to not lose benchmarks 

36. The Headaches Of Speed
• /dev/urandom is fast enough for almost all uses
• That being said, it’s still a lot slower than LFSR/MT
• Linux: Only 3.7MB/sec – that’s only 947K ints/sec (and that’s with CPU drain)

37. Should we use a userspace CSPRNG, just not a
crappy one?
• Seed with [u]random from time to time to still absorb whatever entropy it does
get
• Minimal/Fast CSPRNG: SipHash(Seed, Counter++);
• Yes, this actually works
• ~20x speed of /dev/urandom on Linux
• Possible improvement: CLOCK_MONOTONIC
• Ideally, we’d just be able to ask the CPU for some random bits whenever userspace wanted a
few
• That’s way too easy (and we’d probably never trust the output anyway)
• But we can ask the CPU for time
• Even forked, likelihood near zero of repeated return value
• For VMs, you don’t get a surfaced event on clone, but you do get to plunge into the host to find out
nanosecond time
• Also can be done on a per query basis, which cleans up a bunch of buffering issues from
reading off a file handle

38. My preferred CSPRNG
• SipHash(Secret || Counter++ || Previous_Output || ShiftedTime)
• ShiftedTime is CLOCK_MONOTONIC, shifted by some absolute amount so the
attacker can’t just look up the global time and predict bits
• Previous_Output means if ShiftedTime only has one shot to repeat
• Not using this yet, because I’m an ornery member of Team Just Use
Urandom
• Let’s not debate userspace vs. kernelspace
• We agree: DEATH TO LFSR
• Also possible that other hashes besides SipHash are good
• Blake
• Skein (can actually be 2x speed of SipHash, due to larger output)
• Maybe we make /dev/urandom fast on Linux?
• Probably need an API to probe for metadata about urandom?

39. The Other Entropy Problem
• d3b07384d113edec49eaa6238ad5ff00
• 1Ngju42mHfxJJDEKA15rHUum17rcDEf699
• A1$jh-89)&@4bc (oh wait, no: **************)
•

40. STOP PUKING BITS (Images of 8 Bit Vomit)

41. The Problem At Hand
• Computers need Humans to recognize and remember larger numbers
of bits
• Human face recognition only works to about 16 bits (1/65536)
• Computers want 24-128 bits depending on context
• Recognition: Is this the hash from before?
• Repetition: What is your password?
• Standard Bit Representations are terrible
• Humans did not evolve to recognize hex, Base64, Base58, or…squiggly

42. Previous Work On Cryptomnemonics
• Some previous work from 2006: Names
• 512 Male Names (9 bits), 1024 Female Names (10 bits), 8192 Last Names (13
bits) == 32 bits per couple
• Heteronormative, but surprisingly diverse!
• Julio and Epifania Dezzutti
Luther and Rolande Doornbos
Manual and Twyla Imbesi
Dirk and Cuc Kolopajlo
Omar and Jeana Hymel
• Important to show names every time a connection is made, not just on
challenge
• Would you remember a face you saw only the one time there was an auth challenge?

43. Can We Do Better?
• Humans do have memory capacity, it’s just not for arbitrary bits
• We remember objects, and specifically stories, more than we remember 1’s
and 0’s
• So if you can represent 1’s and 0’s as stories, humans will recognize and
repeat them better
• Also, you’ll be able to put a password in and have it spell check
• Experiment: Use triads of adjective/noun/verbs, set up to be
“maximally distant” from eachother
• Encode them in a way that is order independent, i.e. it doesn’t matter if the
dog or the cow is brown or orange
• Ryan Castellucci has been implementing this, here’s how he did it and
where we’re seeing this being immediately useful

44. Storybits v0.1
• Hex bits: 5e4dcc3b5aa765d61d83 (80 bits)
• Story encoding (early):
• macho acid answering
rustic cable fetching
stuffy jacket forbidding
wacky riot opening
• Story decoder autocorrects
• node demo.js "wckay jacket forbidrustic fetch cableacid mache answering
open riot$$"
• 5e4dcc3b5aa765d61d83
• Words are misspelled, out of order, in different tenses, missing spaces, etc.

45. Details
• Implementations in JavaScript and Python
• Rough, but releasing soon
• Two major components
• Combinatic Encoder
• Encodes information with symbols that may not repeat
• BADFGC is legal, AABBCC is not
• Because symbols are independent, order doesn’t matter
• Word Mapper
• Maps combinatorial numbers to words in part-of-speech wordlists
• Adjectives, nouns, verbs
• Instead of 321, 561, 312, it’s “rustic fetching acid”
• Allows for strong correction from word variants to original numbers
• Words are chosen to have maximum distance for maximum correctability

46. On The Selection Of Passwords
• We have to get past l33tspeak as a security technology
• We punt generation of passwords to users because we don’t want to
“screw it up” and we imagine if the user does it, it’s at least their fault for
failing
• This scheme lets passwords be generated server side, that have a hope of
being memorable
• Passwords that can be corrected are passwords that are more easily
remembered
• Faster recovery from silly typos allows password stretching to be more aggressive
• Don’t suffer the stretch delay because you missed a key – it autocorrects and still
works

47. Major Use Case: Phidelius Approaches Are
Going Mainstream
• Phidelius: Trick from a previous talk that seeded RNG w/ a passphrase
• Allowed passphrases for SSH, SSL certs, pretty much mapped words to asymmetric
crypto
• A little fragile because it was a /dev/[u]random hijack
• These approaches are now popular for asymmetric key management
• Brainwallet:”Word/phrase to a Bitcoin address”
• Minilock: “Word/phrase to a PGP key”
• Incredibly vulnerable to insufficient entropy in the word or phrase
• Because the public key is public, and the whole world can try to crack it
• Has been an expensive problem in Brainwallet
• Tens of thousands of dollars worth of BTC have been taken

48. Squaring The Circle
• Brainwallet and Minilock need human-memorable entropy
• Actual security needs more entropy
• Storybits increase memorable entropy, allow the entropy to come from
the machine (which can generate it) and not the user (who clearly can’t)
• Extensions
• Split Mode – Allow entropy to be split between two words, one that’s easily
remembered (but very slow to crack), another that’s kept on a hard drive or offline
to allow fast transfer of the key to a new device
• The user gets to transfer in seconds
• The attacker has to try to crack for hours per guess
• Breaks the ~20 bit limit on how much you can stretch a key

49. Two More Tricks (Not Necessarily Advisable)
• Local Shrinking
• Will always be easier to recognize 24-32 bits instead of 80-128 bits
• If you only force the attacker to match 24 bits, he can brute force random keys until he finally gets
one that matches just the 24 bits you’re looking for
• Olde trick against PGP KeyIds – “DEADBEEF attack”
• But what if the attacker doesn’t know which 24 bits to match?
• If you have a local shrinking code – sort of a password for recognition – it’s hashed against the full size 128 bit
hash and truncated secretly to 24 bits
• The attacker doesn’t know the code for the truncation, so he has to match everything. You do know the code
so you only have to match a little.
• Local Stretching
• Technically can have a “master password” that’s mixed with all your otherwise small passwords
and shared across many sites
• Whether the site uses scrypt or some other key stretcher, its stored password is guaranteed to be
stretched outside of cracking range
• Password Policy Survival: We have mutually exclusive requirements (symbols, no symbols,
numbers, no numbers). Can infer server policy from supplied password, persist it post-stretch

50. Browser 0day: The Shoe Finally Dropped
• IE had more attacks in 2013 than Java
• How is this possible? MS has been working to secure IE for a decade!
• IE is basically Windows: The Remix (feat. The Internet)
• Take a local object model (COM), hand it to bad guys, wait
• This ultimately applies to every browser, because the spec ends up encoding a COM-like
implementation (there’s an interface description language / IDL).
• Plugins were nice because they were across browsers and tended to be the thing outside
the “sandboxes” but now the browsers themselves are the low hanging fruit
• “My TOR deanon has a first name, it’s Firefox 0day” as the Grugq would sing

51. Use After Free: The Infinite Well Of Browser
Vulns
• Browsers are constantly allocating memory for objects of all sorts of
interesting types
• Objects can point to eachother
• When nothing points to an object, then you can free/reuse that memory
• Lots and lots of ways to point to an object
• Ever screw it up, all hell breaks loose
• Allocate a table (0x12341234 == Pointer to Table)
• Free the table (0x12341234 == Available For Allocation)
• Allocate an image (0x12341234 == Pointer to Image)
• Access the image via its old context as a table (0x12341234 contains contents of Image, being
accessed via handlers for Table)
• “Use After Free” == 90%-95% of the “deep vulnerable” attack surface for the web

52. Google and Microsoft Have Solutions
Firefox Doesn’t, And Is Suffering For It
• Google Solution: Typed Heap
• Chrome is allocating all objects of the same type, in the same “sub-heap”
• Memory once used for a table, will never be used for an Image, because that’s going into
the Image heap
• Microsoft Solution: Nondeterministic Freeing
• (Oversimplifying, they’re doing a lot of stuff)
• They’re making it so you don’t quite know when the memory has been freed,
and thus aren’t guaranteed a reliable or rapid attack
• This is great. Attack the unique needs of an exploit – this is counterexploitation

53. My Trick: Iron Heap
• (Thanks Rob Graham for the name!)
• You can’t Use After Free if you don’t free!
• This is too expensive if you do it with physical memory
• But on 64 bit machines, we have a damn near infinite amount of virtual
memory
• The basic idea is to never reuse an allocation – the physical memory is reused
but the handles aren’t
• 0x1234123412341234, once freed, stops pointing to any physical memory
• Exploit that

54. Iron Heap Efficiency
• Efficiency
• Finite number of active allocations allowed – you’re leveraging the page tables which
don’t like to be that stressed
• Can have a “hot list” of pages that are directly mapped, and a secondary list that’s
“swapped in” on demand
• How compressed RAM works
• Can potentially add guard pages between allocations to prevent overflows
• Overflows have actually gotten kinda rare
• Forces 8K per alloc, which is a bit high, though the compressed backing store can be fully
packed (no pointers to it are exposed in user space)
• Implementation
• Can be run in both userspace (with libsigsegv to catch the extra accesses) and in
kernel (which is already handling this sort of swapping for, well, swap)
• Don’t necessarily object to kernel dependencies or modules
• Linux has a crazy limitation where you can’t get page permissions without parsing text!

55. Downsides of Iron Heap
• No code available (yet, just PoC’s are built)
• Really leans on 64 bit
• Browsers aren’t entirely fantastic at that yet

56. What May Work Today: Diehard(er)
• Interesting secure allocator from Emery Berger @ UMass
• Advanced ASLR implementation w/ out of band heap metadata
• Supports Linux and Windows (and Mac, to some nonzero degree)
• Suppresses Use After Free, mostly by delaying free (similar to MS
approach)
• Available today (you do need to recompile with --disable-jemalloc)
• Probably worth exploring for Tails etc.
• ASLR, NX/DEP, other methods assume corruption has occurred and try to
enforce limits to make the corruption unexploitable
• UAF blockers actually prevent the initial corrupting moment
• There’s nothing going on in Infosec that’s killing more 0day

57. The Plan
• Firefox needs a story around memory hardening
• It’ll take quite a bit to get them to give up their incredibly efficient jemalloc
• First step, let’s get something production worthy for “special Firefox
installs”
• Tor
• Tails
• Then let’s look at getting it mainstream
• “Like millions of 0day cried out all at once, and were silenced”
• Dr. Emery Berger has agreed to join this effort – we’re going to make
something production worthy!

58. Need To Start Thinking about DDoS Again
• 1 >100GB flood in 2013
• 114 >100GB floods in 2014
• Generally, we think of DDoS involving botnets firing their hordes at
some poor web server
• The largest and most damaging floods are actually involving spoofed
traffic that’s reflecting off Internet DNS and NTP servers
• No DNSSEC involved or required
• Important to understand why spoofed reflection is so dangerous

59. Why Reflected Floods
Are Nasty
• Here’s a network.
• Lots of routes
around the core
• Fewer routes from
each source, to each
destination

60. An unreflected packet
stream
• Packets are always
taking the “fastest”
next hop to the
target network
• Bandwidth ==
maximum available
for the slowest
single hop
(wherever that is)

61. The Reflected And
Spoofed Packet
Stream
• It goes out to
everywhere,
spreading the load
across all the
inbound hops
• Everyone replies to
just one place, via all
inbound links
• Boom.

62. What To Do?
• BCP38/URPF
• Ideally, there wouldn’t be networks that allowed you to lie about who you are
• Every network link would have a computed range of addresses it could speak
for, and that would be that
• This actually is a complete success in the DSL/Cable world
• Not saying we shouldn’t continue to strive for BCP38 compliance
• At least 2300 networks w/ no BCP38 compliance
• Can we do more?

63. Stochastic Tracing: Bringing Back An Old Idea
• This is at least 12-13 years old of an idea (roughly, I’m adding some quirks)
• The Internet and it’s problems were different that long ago. What wasn’t
ideal then might be good now
• Basic idea: One out of every 100K-10M packets, a “tracer” goes out
declaring a hop along the route that sent traffic
• Sort of like a “background traceroute”
• Irrelevant network load for normal streams, but DDoS would become traceable
instantaneously – the bigger the DDoS, the faster degraded networks would identify
themselves
• Implementation receives a GRE stream of a small subset of packets – well supported
• Probably a way to do this w/ command line haxory as well

64. Maintaining Privacy and Security
• Tracing traffic only goes to hosts that should otherwise be able to see the original
payloads
• Destination IP for all traffic
• Source IP for DNS and NTP (and any other blind responding protocols that pop up)
• Haven’t decided what the payload would be – ICMP, HTTP, etc.
• To be on the open Internet is to get random stuff, so the only question is what’s easily catchable by a
DDoS victim
• One variation: Allow alternate destination to be declared in Reverse DNS space
• 4.3.2.1.in-addr.arpa IN PTR blabla.foo.com
• The in-addr.arpa space could be used for more than just PTR records
• Could declare an alternate destination for tracer traffic, or flags for format / multidrop
• Still under the authority of the IP address
• Obviously should sign tracer payloads with ED25519 keys, possibly declared in
DNS

65. Long Term Vision
• Reduce the time between receiving a DDoS and tracing the involved
networks
• Ultimately, automatic suppression of DDoS (though this gets really
messy really fast, because so many hops on route see enough to send
the shutdown signal)
• There are large enough floods growing at fast enough frequency
that work like this is necessary
• And since Paul Vixie would kill me if I didn’t say it, please update your DNS
server to support RRD, which dramatically reduces DDoS participation

66. What I’m Really Nervous About
• Can’t just not talk about the NSA revelations
• Not here to recapitulate Bruce Schneier et al.
• I’m nervous about people’s reactions to them.

67. Competing on Political FUD instead of
Technical Merit
• “Sure, you could go with that competitor, that’s cheaper, faster, nicer,
more powerful…but OOGA BOOGA $NATIONSTATE”
• Seems ridiculous, until you hear proposals to keep all traffic to and from a
country, within that country
• “Sure, BGP does say you should use this route, because it’s
cheaper/faster/nicer/network neutral/peered…but the law says you have to
keep it within our borders where we’re the only provider, because NSA”
• Again: The Internet was not the first attempt at large scale Internetworking!
It was the first one that worked at large scale, because everything else
demanded gatekeepers and rentiers
• This is the network made by nerds, not by bizdudes and certainly not by politicians
• It seems to work pretty well

68. Not to put too fine a point on it, but…
• We didn’t exactly want the Chinese Internet, or the Iranian Internet,
before Snowden
• I’m hoping we don’t want that now.

69. The General Reaction To NSA Corrupting
Crypto Standards (DUAL_EC_DBRG)

70. The Nuanced, Even More Disturbing Reality
• There’s a reason we were asking the NSA’s advice to avoid
cryptographic vulnerabilities
• Most cryptographic functions do not need the NSA’s help to be fatally
flawed
• That comes for free
• It takes an enormous amount of time and effort to find functions that might
not be flawed, and the NSA seemed good at telling us when we were wrong
• DES
• It’d be nice if we had a governmental department focused on
defensive operations…
• Or maybe a conference…

71. Even Obviously Good Advice Is Being Treated
With Deep Suspicion
• NIST: Heh, Keccak (SHA-3) is actually too slow. Performance matters.
• Zooko Wilcox-O’Hearn, creator of Tahoe-LAFS (probably the best
cryptographic distributed file system out there right now): Heh,
Keccak (SHA-3) is actually too slow. Performance matters.
• Community: NIST IS DOING MORE EVIL

72. …are we about to replace NIST with DJB?
(Who keeps releasing fast crypto functions)

73. No, seriously, I’m actually a huge DJB fan
• I’ve been advocating Curve25519 for use in a TLS-replacing protocol
for years
• But, uh, fewer trusted resources in a time of great need is not helpful
• “Linux scales. Linus does not scale.”

74. The Problem
0
0.5
1
1.5
2
NSA DJB
Mission Count

75. We’re All Kind Of Waiting For The Other Shoe
To Drop
• Not implementers, everything new keeps using DJBsec
• Academics aren’t really allowed to “know things” without some degree of
evidence
• Science!
• We do know that DUAL_EC_DBRG is compromised, but nobody was using that
except other feds (sadface)
• Pretty much everyone assumes the NIST P curves are compromised
• Big complex process to turn a “nothing up your sleeve” number (like pi) into a safe ECC curve
• Innocent string used by NIST P curve is c49d360886e704936a6678e1139d26b7819f7e90
• Every shirt has two sleeves
• NIST took the time to declare two curves, a P curve and a K curve, almost as if they assumed
eventually there would be a problem and it’d be nice if the standard could survive it
• The above does not pass scientific epistemology. Nobody cares.

76. The Larger Issue
• It’s not like cryptography worked particular well before the NSA
revelations
• The hard problems in crypto are not in the math, or the
implementation. They’re not even in “side channel vulnerabilities”, as
Shamir has said.
• Key management is the hard part, because that actually touches
users.
• Cryptography keeps getting seen as Math and Implementation. There
is a third aspect
• There is a complexity that generally goes unmodeled: Operations

77. My First Law of Operations
• Every project must be measured by the number of meetings required
to accomplish it
• If there is a meeting with someone outside your department, it’s 5x the cost.
If outside your company, 25x the cost.
• When’s the last time you saw meeting count in a crypto function?
• We have to learn to respect usability, and the sacrifices it may
demand
• Alex Stamos at Yahoo backing PGP for their mail interface is actually a pretty
big step – Yahoo knows UX

78. Summary
• Don’t let an attacker touch your storage – S^X
• Actively gather true entropy and kill the non-CS PRNGs with fire!
• Represent entropy in a way other than bit vomit
• Browsers become vastly more secure once UaF is prevented
• The NSA crypto fallout continues
• Yahoo’s PGP news is fantastic
• And…just one more thing

79. It’s Apple Related, So I Totally Get To Pull That
Line
• “Safari now blocks ads from automatically redirecting to the App
Store without user interaction. If you still see the previous behavior,
or find legitimate redirection to the App Store to be broken in some
way, please file a bug.”
-- IOS 8 Beta Release Notes from Apple
• YES ACTUALLY, THIS DRIVES ME CRAZY
• “I know you’re trying to browse this website, but I bet what you really want to
do is buy our ****ty game”
• **** THOSE GUYS
• Apple wants help? Hackers, lets do it
• And not for free

80. Third Party Bug Bounty
• I’ve become a believer in bug bounties
• This is new
• External bug quality can sometimes be of poor quality
• If you want richer bugs, maybe we should enrich bug hunters
• White Ops hereby sponsors an enhanced bug bounty for this particular
Apple bug
• $5,000 to the first autoredirection bug finder
• $2,500 to the second finder
• $1K to the next five finders
• We offered $250 six weeks ago, sorry, my bad
• We believe hackers can help fix things, and we’re putting our money
where our mouth is