NateLawson

MNIST is what the Post Office solved in the late 1990s. It's basically the "hello world" of visual recognition these days.

https://www.govexec.com/federal-news/1999/02/postal-service-...

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.

There's another reason why USB-to-parallel adaptors can't replace a PC with a printer port: the latency for round-trip applications is significantly higher over USB. It takes a few microseconds to read/write a byte from a PC printer port. Over USB, the control message latency leads to this taking tens of milliseconds. USB beats it on throughput, but only when transferring lots of data.

Before they disappeared, printer ports on motherboards began getting worse for latency and compatibility. This was likely due to cost reduction since low latency two-way communication was not needed for printing.

There was an interface for old Commodore floppy drives that is just remapped pins on the printer port[1]. When PC's circa 2005 stopped working with it, I designed a USB microcontroller board to implement the protocol[2]. It had to do some fancy state machines to get around the round-trip problem, caching a set of commands until the host was ready for the transfer. Then it would send them all back-to-back and start streaming back the bulk data. Fun stuff.

[1] https://www.c64-wiki.com/wiki/X1541

[2] http://www.root.org/~nate/c64/xum1541/

The slowness was due to a hardware bug in the 6522 VIA chip. The shift register (FIFO) would lock up randomly. Since this couldn't be fixed before the floppy drive needed to be shipped, they had the 6502 CPU bit-bang the IEC protocol, which was slower. The hardware design for the 154x floppy drive was fine, and some clever software tricks allow stock hardware to stream data back to the C64 and decode the GCR at the full media rate.

https://www.linusakesson.net/programming/gcr-decoding/index....

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.

These typically work by changing the media bit encoding to be easier to process with 6502 instructions instead of a lookup table. Others simplify the table and use more RAM so that fewer lookups are needed. I haven’t looked at how Transwarp works yet but it seems like the latter.

Some discussion with the author: https://www.lemon64.com/forum/viewtopic.php?t=78558&start=0

There’s a newer version here: https://csdb.dk/release/?id=214786

Release notes: https://csdb.dk/release/?id=214786&show=notes#notes

More details from another advanced loader:

https://www.linusakesson.net/programming/gcr-decoding/index.... https://www.linusakesson.net/software/spindle/v3.php

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.

Xprotect is part of GateKeeper, which arrived in Mountain Lion (and late versions of Lion).

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.

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.

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.

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.

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).

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.

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.

You need to get access to the raw entropy stream in order to characterize it and test it under a number of different situations. At Cryptography Research, we did a number of reviews of hardware entropy sources.

You have to look into behavior during very early startup (power on reset), suspend/resume from low power states, under high heat and thermal shutdown, as well as stable operation. You look at different samples of chips to look for production variation. You build software models that try to simulate the underlying hardware behavior to see how close they get to predicting outputs (which is a bad thing if it works too well!)

You then review how the system processes this entropy since ideas that look good to hardware engineers (like a string filter) are actually really bad for entropy. You analyze the path for side channels or race conditions that could leak raw entropy across process boundaries.

Anyway, here are the reports:

https://www.rambus.com/wp-content/uploads/2015/08/IntelRNG.p... (1999)

https://www.rambus.com/wp-content/uploads/2015/08/VIA_rng.pd... (2003)

https://web.archive.org/web/20141230024150/http://www.crypto... (2012)

QKD relies on many underlying assumptions, which researchers conveniently sweep under the rug while continuing to build castles ever higher on the theoretically "perfect" but insecure foundation. It is unclear how the underlying implementation for QKD can be made as secure as modern silicon countermeasures are against attacks like fault injection.

A while back, I summarized all the ways I could think of where the layer under QKD fall apart. I think the list is still valid:

https://rdist.root.org/2008/10/24/quantum-cryptography-is-us...

This is kind of a ridiculous announcement, but I appreciate what they're trying to do. I find it ironic that they're trying to improve security & privacy for app users, but then the first apps they certify are almost exclusively VPNs, which are some of the worst for user privacy.

VPN vendors collect all kinds of data on their users and are sometimes even backed by intelligence agencies. Sure, use them to get around region restrictions for something uncontroversial, but don't send all your traffic through them and expect privacy.

I also see that they didn't tackle the hardest part of mobile app security -- the backend services. Many apps scrape data from the device and then push it to the service, where it is logged (for how long?) and reused in who knows how many ways. The lack of transparency around backend processing is the real problem for app users.

How many users have been had their data exposed by an open S3 bucket or database versus by a vulnerability in the app code itself?

Kirk McKusick took this kind of scale into consideration when designing softupdates for UFS. One of his criticisms of the competing log structured filesystems at the time was that the replay process would require RAM in excess of any server's capacity once disk drives were large enough. He had designed the softupdates recovery process to be incremental and use a fixed amount of RAM that didn't scale with volume size.

This kind of holistic systems' awareness is a sign of software that's designed well.

Hacking became "cool" for the corporate world in the late 90's. Movies like The Matrix and the fact that nothing too valuable was online yet meant that getting hacked was likely just web site defacement. Meanwhile, there was finally real money to be made in developing security for when the web finally became worth protecting.

There was some ongoing consternation at ISS around 96-97 about an employee being a Phrack editor. Management talked to them but it didn't threaten their career.

My university had terminal labs in the early 90s, tables full of Wyse terminals hooked up to the central UNIX cluster. PCs and Macs were common in other labs, but a terminal lab was still a convenient place to check email or get on IRC between classes. I would log into two terminals next to each other in order to have a screen for IRC while coding on the other one.

One early morning, I walked into a lab that was vacant except for one person. He was slumped over the keyboard with a hand around an empty Coke can. The amber screen was scrolling upward every few seconds:

  YOU ARE HUNGRY...
  YOU FEEL TIRED...
  > 
  YOU ARE HUNGRY...
  YOU FEEL TIRED...
  >

Butler Lampson (Xerox PARC researcher who created the Alto) recently revised this classic paper from 1983, updating it for more modern systems and principles (e.g., eventual consistency).

Yes, parsing of untrusted data, race conditions, etc. are still a problem in general. My complaint was with the uninformed article, not your analysis.

Sure, how about linking against the platform OpenSSL implicitly by grabbing a lib.so from an actual Android phone, linking against it with the NDK, and hoping that the ABI will never change?

https://sourcedna.com/blog/20150806/predicting-app-crashes-o...

And all that only to get access to MD5 or AES...

I've spent a lot of time both reversing and creating these kinds of schemes. Anyone else here?

I gave a talk a few years back, comparing both retro and modern copy protection schemes. Also designed hardware for dumping floppies at the bitcell level (ZoomFloppy) and co-designed the Blu-ray content protection system.

http://www.slideshare.net/rootlabs/copy-protection-wars-anal...

Now my day job (SourceDNA) is building tools to reverse lots of code at scale. A never-ending stream of apps provides a ton of "wat?" moments as you never expect developers to make the choices they do.

There is no IOMMU in USB. You've got it backwards: the IOMMU in PC's is on the host side of the USB controller, not the device side.

There's an easy way to tell. Does the bus carry memory addresses? Then it supports DMA. Does it just send messages? No DMA to protect against.

The USB controller on a PC does support DMA. The OS device driver allocates buffers and passes them to the controller to fill. If it's properly programmed, it will only store data into those buffers. An IOMMU is there to prevent malicious kernel privileged code from bouncing through peripherals that support DMA to compromise other privileged code.

Messages on the USB bus side have no addresses in them and there is no DMA involved.