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