David Wagner

> Mac address of network card + current time? you're trolling, right? If not, begin your journey to enlightenment at http://www.cs.berkeley.edu/~daw/papers/ddj-netscape.html (15 years old now!), http://www.schneier.com/paper-prngs.pdf and the kernel source for your favourite OS' /dev/random (the OpenBSD one is pretty well commented)

I wondered the same thing, so I did a little extra footwork. Berkeley Professor David Wagner conducted basically the same research as this dude: http://www.cs.berkeley.edu/~daw/faa/ He came to similar findings regarding selectees: http://www.cs.berkeley.edu/~daw/faa/noid.html Neither of those pages are dated, though, so it's still possible things have changed in the past three years. Even so, it's worth noting that both these sites are reporting post-9/11 information. I'm curious and a bit adventurous, so perhaps I'll give it a shot. I bought the jetBlue pass, so I'll have plenty of opportunities. http://jetblue.com/deals/all-you-can-jet/?intcmp=HPHero1Eng_All-You-Ca…

You can't remove anything from the internet, that's the point, and that's why you should be very careful about what information you put in the internet. At best you can temporarily hide it. Anyone who truly wants to dig up dirt on you, or wants to do a background check, won't rely only on Google. You say it's not about a company in particular, but the principle, but notice how you are totally ok with a non-Google index. The reality is, any distributed system would converge eventually, and end up with the same issues you have with Google today, only just like with controlling nukes in a multipolar, vs superpower world, governments would lose power to regulate speech and publishing. Thinks would get harder and more dangerous for those wishing to remove information about themselves from being found. Notice how quickly people are to go hyperbolic on the precedent of Apple unlocking a single cell phone, because hey, if the FBI can ask Apple to do it, then the Chinese government can too. But I don't see any similar concern about the possible bad precedents European censorship will set for China, Russia, et al. How can tech companies put up a fight against Chinese requests for censorship, when the European Union is given that option? Given your history Jake, of nearly daily anti-Google articles on your social feeds, should I not be skeptical that this has less to do with principle, and more to do with your desire to see Google lose a battle or two? And before you chalk this…

During a review of W3C WoT & ETSI M2M standards I noticed that security is totally ignored in these tech-standardization bodies. The standards leave security as an exercise to the industry and the maker communities (who are not spending money on security until they have an problem). That said, it's also not trivial to implement something that at first sight seems straight-forward like 802.15.4 Security[0][1] without a deep understanding of the security architecture supported by the underlying platform: [0] http://www.jwcn.eurasipjournals.com/content/pdf/1687-1499-2006-093830.… [1] https://www.cs.berkeley.edu/~daw/papers/15.4-wise04.pdf Since the web is now getting "engaged" to the devices with CoAP and other protocols I wanted to create awareness of how bugs can spill over into the real world and do real damage there. If hacked insulin pumps or baby monitors don't scare you enough how about hacking a train? https://media.ccc.de/v/32c3-7490-the_great_train_cyber_robbery ?? (everyone should probably watch this simply because SCADA strangelove guys are crazy and awesome) Anyway to counteract the usually very "marketing intensive" tone of IoT groups on LinkedIn I decided to start this IoT Security group: https://www.linkedin.com/groups/4807429 it would be great to see people from all camps (IoT is a combination of 3 silos: 1) embedded, 2) web 3) infosec) actively contributing with technical topics in this group. I will keep it open to posts from marketeers but am heavily…

I'm flattered by the attention, as always. Couple quick things: On our original blog (I have nothing to do with this one; I haven't been at Matasano for several months), this was CSS-formatted to look like an actual script, which I think makes it significantly easier to follow. Dave Wagner copied it to his website, and it's closer to the original: http://www.cs.berkeley.edu/~daw/teaching/cs261-f12/misc/if.html Second: in case you're impatient (I would be), conceptually, this is what the post is trying to communicate: * Unauthenticated CBC is surprisingly malleable. There are two attacks in here that I thought were "clever": using totally random CBC block garbling strategically to eat quote characters and synthesize SQL injection (the motivating example for the post, after I pulled this attack off on a real system) and "stuffing" inputs with known plaintext to make rewriting easier. * CBC padding oracles. I would be interested if anyone knows a source outside of academic literature that walked through this attack published prior to 2009. It is not about how to implement single sign-on cookies. The nice thing about posts about cryptographic attacks, as opposed to cryptographic constructions, is that they age pretty well. :)

> The funny thing about all this is that (perhaps this case aside) Google is getting a lot of bad PR because they actually tell people what they do. Surely you jest? This story goes back 4-5 years ago. People have such short memories. [p.s.: missed the "aside".] http://epic.org/privacy/streetview/#timeline > Meanwhile, everyone .. facebook .. Target .. Facebook's very provenance is a matter of double dealing, lies, and thievery. I expect precisely zero degree of ethical and moral rectitude from that company. I have never used it and never will unless literally forced at gun point. Target (and other merchants): Rest assured I was never convinced that giving merchant x a track-me green light was worth saving a few bucks here and there. I expected so much more from Google and the people working for Google. I deeply regret the necessity to post the links below (and single out this one individual), but clearly $omething happen$ to otherwise (and previously) aware, concerned, and '"sword" wielding' engineers and scientists when they get sucked into Google's vortex: http://www.cs.berkeley.edu/~daw/papers/privacy-compcon97-www/privacy-h… https://twitter.com/#!/eric_brewer/status/68051541063503872 (What happened, Dr. Brewer? You seemed to have an informed clue in 1997 ...) It really makes you wonder. I guess we are all human, after all. > Your privacy is being violated all the time, constantly, and nobody tells you about it. If you care so much about the…

That's not trying to break the mitigations: it's simply testing if they stop an exploit which isn't designed to bypass the mitigations. Really easy to pull off. :) Below are examples of a clever scheme for stopping control flow attacks and a successful attempt to breaking it. When I say testing the mitigations, I mean work like what's in the second paper. https://www.usenix.org/system/files/conference/usenixsecurity13/sec13-… http://www.cs.berkeley.edu/~daw/papers/cfi-sec15.pdf Note: Native Client, which protects Chrome, is a form of Control-flow Integrity. Hence, me using it as an example.

Yes, it absolutely is[0] for essentially the exact examples you cite. [0]: http://www.cs.berkeley.edu/~daw/teaching/cs261-f12/misc/if.html).

There is an interesting comment below the article: "Yuhong BaoMay 23, 2014 at 10:14 AM On this matter, anyone remember the Netscape random number generator bug: http://www.cs.berkeley.edu/~daw/papers/ddj-netscape.html Notice the paragraph at the end about RSA Data Security!"

Some of the previous work on this involving timing attacks against SSH [1] is particularly interesting because it's so obvious in retrospect, but no one saw it when SSH was being designed. [1]http://www.cs.berkeley.edu/~daw/papers/ssh-use01.pdf

Thanks for that. But afaics, libgcrypt seems to be on a similar level of abstraction as the openssl lib? i.e. implementations of ciphers etc. I then fall into the mistake of http://www.cs.berkeley.edu/~daw/teaching/cs261-f12/misc/if.html I think? [linking to berkely.edu because the page seems to have gone from matasano.com?] And I think GPGME is a lib which "under the hood" spawns a command-line gpg process? http://www.gnupg.org/faq/GnuPG-FAQ.html#cant-we-have-a-gpg-library At the moment it looks like my choice is between implementing a cryptosystem on top of crypto primitives (from openssl or libcrypt) or seeing if I can get away with shipping a lib which spawns child processes via gpgme.

It refers to a blogpost from 2009 on the Matasano blog. I found a copy of it here (my apologies to tptacek I can't find it at matasano.com). http://www.cs.berkeley.edu/~daw/teaching/cs261-f12/misc/if.html The gist of it is that just having "256bit AES" tells nothing if it is properly implemented with a robust block mode, proper key generation and if it is signed.

In the US you are not required to have id to fly. e.g. http://www.cs.berkeley.edu/~daw/faa/noid.html I hope it'd be illegal in the US to require it, not sure though.

The authors didn't cite Netscape because the 40-bit key is too short, they cited it because the the PNRG in the SSL implementation was faulty. They link to this page with more details: http://www.cs.berkeley.edu/~daw/papers/ddj-netscape.html

It is a worst type of "bug" because it seems intentional: the implications are enormous, the temptation is simply too big. Remember the "netscape" crypto lib (ssl huh...)? With half-key repositories, weak rnd generators, "bugs". This doesn't happen so often by accident. Particularly after having been recognized. http://www.cs.berkeley.edu/~daw/papers/ddj-netscape.html

If you store binaries on the system and the system can recognize them, it could change the served versions to insert malware. This attack isn't purely theoretical. I believe Ian Goldberg and David Wagner's group at UC Berkeley demonstrated it in the 1990s against a LAN-based NFS server that was serving shared software to workstations. Instead of making the NFS server itself malicious, they raced against it to provide modified binaries that the workstations would then execute. However, if the NFS server had been malicious, it could have carried out the same attack, without directly leaking user data to the Internet. I guess this is a reference to that work: https://www.cs.berkeley.edu/~daw/papers/endpoint-security.html If you could compromise workstations this way, you could then try to find another channel through which to have the workstations themselves exfiltrate data. One example might be a variant on the Telex system: https://telex.cc/ Instead of signaling Internet routers with requests to browse censored websites, you could signal them with the content of exfiltrated files.