jeff_marshall

from the article:

>Domain validation is hard. It isn't as simple as one may think, and WoSign isn't the first to have a problem. They are still a trusted CA for now, and hopefully they will get their act together quickly.

The vulnerability exposed seems like a basic unit test to me (only assume ownership of validated domains or sub-domains - NOT all domains with a common root (or perhaps substring? the article is sparse on details)).

I had already lost faith in the 'everyone can be a root if they describe their process' model of trust before reading this post, but if software vendors that rely on trust anchors on their users behalf can't be bothered to do even basic due dilligence beyond vendor-sponsered audits, I'm left speachless.

Perhaps my experience with FIPS-140 has jaded me, but after seeing so much more money spent on paper-pushing than actual vulnerability assesment (and remediation), I can't help but feel lost after reading this.

When I worked as an RA while getting my BSCS (and for a time during my first post-college job), I spent quite a bit of time with ACL2 (a language, logic, and proof assistant using a first-order variant of common lisp). I spent a lot of time applying ACL2 to my research area (information flow analysis for secure systems), and I feel your pain re: proof strategies. It was almost like learning how to prove things again (e.g. learning new induction strategies that matched the logical framework used by the tool).

That said, there was an incredible amount of freedom in knowing that if the tool accepted a proof, it was (probably) correct. Occasionally I would stumble on to a strategy without knowing why exactly it worked, and the interactive nature of the tool helped me gain understanding by letting my apply transformations to terms interactively without having to worry about whether I screwed up some minor detail.

I'd love to see one of these tools (though, probably not ACL2 at this point - first-order logic frequently felt limiting (e.g. when proving things about parameterized equivalence relations)) used in a book covering some math topic I'd like to learn, as interactive formalism seems well-suited to self-exploration (you don't need an instructor to point out your trivial errors)

Only "Military or intelligence cryptographic (including key management) systems" are included in the current US munitions list [1]. Everything else is handled by the Department of Commerce as part of the export administration regulations (EAR) [2].

[1]https://www.pmddtc.state.gov/regulations_laws/documents/offi...

[2] https://www.bis.doc.gov/index.php/policy-guidance/encryption

Symmetric doesn't mean 'power of two'. Quite a few ICs have had even numbers of cores on them (I'm not aware of any with an odd number of cores, but that doesn't seem like the end of the world either). Lots of other things have to fit on the die, too (e.g. unified cache, which takes up a lot of real estate in chips that have them)

well, at least as recently as Windows 8.1[1], windows was on that list and microsoft said to use DHCP for that (which has always bugged me as it's yet another protocol to support).

Have things changed? I haven't checked on win 10.

[1] https://www.ernw.de/download/ERNW_Whitepaper_IPv6_RAs_RDNSS_...

How are you getting DNS configuration (server + search domain) via SLAAC?

If you would have substituted coq (or even ACL2 with guards checking enabled...) in the place of haskell I would agree.

hindley-milner style type checking is nice, but once you admit that things like arrays exist (rather than just algebraic data types or cons cells), the power of languages like haskell is in design patterns like map() and reduce() rather than the type checker, IMO.

Having worked in functional languages with an imperative bent (esp. ACL2 in the context of modeling microprocessors), you can get an awful lot of mileage out of a good static proof strategy that can be instantiated over a known design pattern (equivalence relations, map, reduce, etc) even when you pass a single, huge, state object to all your top level functions.

Yes, instead you have parameter passing bugs (what, it's not state if it's not an implicit global variable?).

I suspect the bugs have more to do with what is considered an acceptable design pattern (and resulting cognitive load) than the state-passing style.

IMO, the premise that hypervisors can have a smaller (thus more assurance-friendly) attack surface relative to a monolithic or microkernel-based operating system is not challenged by any attack against xen. Xen has a very feature-rich interface as far as hypervisors go (hello grant tables!). The interface to the hypervisor on x86_64 can be small while still being performant and functional (EPT and posted interrupts are very nice).

That said, I work for a company that sells a hypervisor built on the idea that hypervisors need not be complex to solve real problems. We look at hypercalls that include data structures (even ones as simple as C strings) with great skepticism.

I agree re: the secure backplane (though I would prefer to see it done outside server software in a more comprehensive manner).

I'm surprised that the bar isn't set a bit higher inside the cloud provider infrastructure for tenant separation at the network level. I suppose it boils down to the lack of assurance at an even lower level (who trusts Xen these days?) that seems unlikely to be fixed in the short term.

Which provider won't give you a /64 (that supports IPv6 at all)?

Even my residential cable provider gives me a /60. Anything less seems absurd.

Any details on handset availability (even rumors)? I'd love to get my hands on a phone with an LTE transceiver that can operate in this spectrum range having an unlocked bootloader on the application processor.

Setting up a base station at elk camp and being able to use a regular cell phone instead of a dedicated amatuer or FRS/GMRS transceiver would be very cool.

Thanks for the pointer to Seastar, I wasn't aware of that project.

Good luck with your work - I'm curious to see the result.

As I'm sure you are well aware, there is quite a large gap between the DPDK and a working TCP stack.

Do you plan to write the TCP stack from scratch? If not, are you planning to leverage one of the golang unikernel back-end ports?

10Gb/s (even per-core) doesn't seem like much of a selling point for a network stack on it's own, given where the rest of the industry is.

Using brute force (i.e. "immense computing capabilities") for properly sized keys is unlikely to ever be practical with classical computers. With quantum computers, many currently deployed key lengths that would be impractical to brute force with classical computers would become vulnerable to attack, but nobody is currently known to have quantum computers of sufficient power. See Wikipedia for basic details[1].

IMO, an intelligence agency would be more likely to invest in other methods (algorithm implementation weaknesses, software bugs, insider access, etc), due to the higher liklihood of sucess.

That said, it's interesting to note that the NSA is moving towards "post-quantum" cryptography[2], under the assumption that suitably powerful quantum computers will be, or have been, built. Whether the NSA already has such suitably powerful quantum computers is anybodys guess.

[1] https://en.wikipedia.org/wiki/Key_size#Brute_force_attack [2] https://www.nsa.gov/ia/programs/suiteb_cryptography/

Good point re: general purpose cores in devices whose primary purpose is other things. I've been spoiled by the ability to choose parts that don't go quite so retro for the CPU in my own designs.

Regarding power, is the difference all that great? some googling shows that there are cortex M3 devices that use 0.3 uA in standby. Do the PICs have some features that make standby mode more useful, or do they have significantly lower power draw in sleep mode?

I've never had to deal with low power draw in standby/sleep mode outside of FPGA-based designs, so I'm curious to know whats out there.

Fair enough, but the device in question would have to be made in serious quantity to feel the difference (though that is a rational use-case).

Per digikey, the cheapest 8-bit PIC is 0.35 USD in MOQ of 3K. When 15 cents matters to your BOM cost, you know you are making a lot of things :)

Tell that to the people who debug new CSP/BSPs using binary search on "which line did the boot sequence make it to" using GPIO to an LED.

Thankfully, most of us don't spend a lot of time doing that sort of thing these days (even in the embedded world).

I also feel for anyone who ends up using an upside-down air can to debug shoddy solder joints on a BGA device ;)

Is there any reason to use PIC instead of ARM these days? On the low end, 32 bit arm microcontrollers can be had for ~ 0.50 USD in modest quantities (digikey minimum order quantity in the thousands).

It's not like there is a shortage of compilers for the various ARM architecture revisions (though the BSP support may be lacking in the hobby market).

Yes, ASICs to break DES were done back in 1998:

https://en.wikipedia.org/wiki/EFF_DES_cracker

Detecting AC vs. DC coupling would be obvious to a practicing EE, if presented with the problem, yes? I'm just a software guy with an electronics hobby and I think I could have figured that one out.

That said, DC vs. AC coupling detection could probably be granted a patent if nobody had "disclosed" the idea prior to filing of such a patent, based on my experience with software patents.

Sorry to vent, but patents on this sort of thing drive me crazy. I don't have any gripe with you or your post.

Yes!

I did the telnet thing to mail servers while I was in high school to good effect ;). I would almost certainly cringe if I could see those mails today.

Showing the school IT department what could be done with a semicolon in a URL on their servers would have gotten me suspended if it weren't for some understanding teachers. Thank god I only put a fork bomb (cringe of 2016 me is real) in there.

I have fond memories of the transition from local BBSes (my parents were annoyed enough by my constant phoning of the local BBS to download commander keen and the like), to IP connectivity via Trumpet. The reach of the internet (esp IRC!) was mind-blowing for someone living in a relatively isolated community in Alaska at the time.

I feel like I don't fully appreciate the gradual transition from dial-up and Trumpet to LTE and a supercomputer in my pocket :) I wonder what people born today will experience that has as great of an impact.

While hearthstone may be fun, I don't think it's existence speaks to the value (good or bad) of the game engine it was developed in.

It's technical excellence (esp. w.r.t. rendering) was low relative to the competition the last time I checked (~ 1 year ago). If Hearthstone is great, I suspect it's because the game designers (the people who make something fun) are good at their jobs.

Really, I suppose it comes down to the strengths of your team and your goals (fun, mind-blowing visuals, dev time, etc.). I'm sure there is a place for quite a lot of game engines to exist given the trade-offs involved.

You are lucky you don't have astigmatism :)

Even with diopter adjustment, I still prefer to wear my glasses (oculus DK2 in my case). I should really look into corrective surgery (lasik, etc.) again...

I think there is still some nuance available.

Perl is great for succinct syntax, which is something I admire (who doesn't appreciate backtick for invoking another program?)

This same brevity is valuable in other contexts, but the challenge is in doing it and understanding the implications. So long as such mechanisms don't introduce hidden complexity (e.g. ';' in bash or it's equivalent), succint syntax has my vote. Working in C at a low level and still having to deal with integer overflow shows me that there is definately a middle ground w.r.t. expressivity and details. I'd be happy to see progress in this area.

For me, it's less about the throughput than the total experience given the services I use.

I have a less than stellar connection for the US (~25/5-ish?), and getting my voip to work took some real tuning in PFsense. The move to PFsense was basically motivated by the fact that I couldn't even do the things I wanted to prioritize voip via the gui provided by the mainstream combo wifi/router I had before. Without tuning (firewall, qos settings), it would frequently sound terrible as soon as someone fired up something bandwidth intensive.

I wonder how much is HW vs. SW, since the router I'm using these days is a low-end single core (2x hyper thread) atom box from Soekris that rarely has >10% cpu load. There appear to be much faster HW options available from various vendors these days at a lower price point than I paid for the soekris when it was new, but PFsense wasn't available on my cheap MIPS wifi-router.

"don't hate the employee, hate the employer"

That sums it up for me.

The existance of "the" key is not an inherent problem in situations like this. Instead, it speaks to poor key management practices by the people responsible for implementing cryptography for an organization.

Consider, as an analogy, the (poor) practice of using shared passwords. What do you do when you fire someone who had legitimate access to this password? You have to change everything or risk a compromise of all the systems sharing this password. Hence, the need for tools like sudo that separate authentication (what password / auth key) and access control (what rights).

With encryption, it's similarly possible to break one big risk domain into lots of smaller ones using things like separate trust anchors (for authentication) or encryption keys (for access control). For example, If your org gets served a subpeona for your financial records you can give them your tape backups for the relevant time periods plus the necessary decryption key, but withold the decryption key for the backups of your R&D data and the signing key for your VPN.

Back when I was doing crypto at the algorithm implementation level, I found the proceedings of the CHES[1] conference had a lot of good information on where the public state of the art was regarding side channel attack and defence.

Keep in mind that side channels are very much a moving target - an implementation that isn't vulnerable to a known attack today could fall to an attack discovered tomorrow. Unless you take extradinary measures to prevent physical measurements of your implementation and detect and respond to physical tamper events, some kind of attack (practical or not) will probably turn up during the useful life of an implementation, in my experience.

With small and/or low-cost devices, such physical countermeasures are usually impractical, so you have to take extra care on the HW/SW algorithm implementation side to avoid vulnerabilities.

[1] https://www.cryptoexperts.com/ches2015/index.html