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