NateLawson

Joined 17 years ago

Karma
1,409
Submissions
389
Member since
May 21
Root Labs (currently): consultant for design and analysis of embedded and kernel security, cryptography, and reverse engineering. https://rootlabs.com

Past companies:

- SourceDNA (founder): a web service that scanned binaries from the app stores, identifying the tools and libraries they were built with. We notified developers about security issues and tracked the market share of SDKs and developer tools.

- Cryptography Research (engineer): self-protecting digital content, differential power analysis, tamper resistance for ASICs. So many stories.

View on Hacker News

Recent submissions

Comment · 3 years ago
Comment · 3 years ago
It's important to point out that these programs have two different objectives.

The Mullvad client is designed to connect to a closed-source service, which is run by someone else. It supports a bunch of different plugins, including openvpn and WireGuard. So probably it could adopt rosenpass, at least with its WG plugin.

WireGuard is designed for minimal protocol variability, high assurance implementations, and ultra small code size. It's used by VPN services, but also by end-users creating their own tunnels.

Comment · 3 years ago
Comment · 3 years ago
Comment · 4 years ago
Yeah, the ISP I founded in 1995 (elite.net) was a PM2ER for both dialup and routing with a Pentium 90 as the shell & web server. We quickly hit the 30 line limit and went up to the PRI-based Portmaster models. Fun and exciting times, just bringing a rural community online for the first time ever.
Comment · 4 years ago
Comment · 4 years ago
A semi-legit app can later drop malicious code and run it. Think of a repackaged OSS project or pirated software that has an auto-updater built in.
Comment · 4 years ago
Xprotect is part of GateKeeper, which arrived in Mountain Lion (and late versions of Lion).
Comment · 4 years ago
Here's a good summary of the flaw:

https://guidovranken.com/2022/06/27/notes-on-openssl-remote-...

Note that the bug is only in 3.0.4, which was released June 21, 2022. So if you didn't update to this version, it's unlikely you're vulnerable.

Comment · 4 years ago
Sun did have a firewall by the early 90's. It had application-level proxies, and you'd have to configure applications to bounce through it if you wanted to get to the Internet. In many ways, this was more secure than today's default for firewalls where you can make any outbound connection you want but only the inbound connections are filtered.

Note that I'm not arguing that Sun was a leader in security, but they did make some efforts that other companies didn't.

Comment · 4 years ago
My company, Root Labs, has consulted on various lawsuits. We aren't trial witnesses but we've done supporting work, such as reverse engineering and writing a detailed technical analysis of how a product works. This report was then reviewed by the testifying expert, who wrote their own report to be entered as evidence.

I recommend not working as a testifying expert for a few reasons:

- You have to take sides, and the other side will never want to work with you again. Are you sure you'll never want to work with AT&T if you represented Verizon once, for example? What if you want a job there some day?

- Despite the term "expert", it comes down to how you present yourself in the courtroom versus what you know. The opponent's "expert" might seem more believable than you, despite being wrong about the technical issues.

- You have to stick to one particular area of technology your whole career, and many of the cases cover the same ground. Do you want to be "Ethernet Implementation Person" your whole life?

- A lot of the work is boring, and lawyers are generally not technically adept. Juries are worse. So if you love explaining something repeatedly in oversimplified terms, maybe you'd like this.

Usually testifying experts are older and do it after they've finished a career in some subject area. It might make sense at that point as a second career.

Comment · 4 years ago
If you did a pure analog copy (dual tape deck), you had generation loss. Eventually copies of copies would have too much noise and thus persistent load errors. Additionally, in-band signals were included in the gaps between blocks that would mess with the auto gain control, causing an unreadable copy as the tape deck tried to compensate. The loader would skip over these sections during the regular load process.

All copy protection relies on asymmetries between the production/mastering environment and the consumer equipment.

Comment · 4 years ago
Same year, and every engineering and CS student I knew had one in their dorm room. The lowest spec I saw was 386SX-16 with 2 MB and the highest was 486DX-50 with 16 MB RAM. Most used DOS/Windows but the CS students dual booted to Linux (Slackware mostly, some SLS).
Comment · 4 years ago
As late as the mid-90s in California, some kids showed up at university without a computer. There were PC and Mac labs on campus that were open pretty late, as well as VT100 terminal labs open 24/7 (though these were only used by most students to check email between classes and were on the way out).

All engineering students had a computer, though.

Comment · 4 years ago
This article is a good list of implementation flaws with RSA, both in parameter selection and protocols.

However, I disagree with the recommendation to use ECIES. It has a separate MAC and encryption algorithm approach which is better served by AEAD algorithms these days.

Live from the official Hacker News API

A modern reader for Hacker News · SvelteKit + Skeleton