Decoding the 90s: Cryptography in Early Software Development (2023)
botanica.software
botanica.software
As another example, Microsoft Outlook 2003 infamously used CRC32 to "hash" the personal folder (.PST) passwords: <https://www.nirsoft.net/articles/pst_password_bug.html>. Naturally, it was trivial to find a CRC32 checksum collision and open someone else's PST.
Thankfully, the industry has come a long way since then. These days, rolling your own cipher is, quite rightly, considered a red flag!
Bonus marks for when the key was also "<Product>Key".
I never like the idea of hand implementing crypto, ever. Why would I not just use existing libraries?
In this hostile environment, many wheels are reinvented
C programmers actually consider this a point of pride
Cryptography is such an esoteric and deep field that it's easy for a fairly smart but inexperience engineer to misjudge the security of a particular implementation or usage of a cryptographic primitive.
Indeed! As I just wrote in another comment on this page, Microsoft Outlook 2003 used CRC32 to "hash" the personal folder (.PST) passwords. Since CRC32 isn't a cryptographic hash, it was trivial to generate a collision and access someone else's Outlook personal folder. This flaw persisted until at least 2006! More details here: <https://www.nirsoft.net/articles/pst_password_bug.html>.
A fun thing to look at today is `deslogin`, the predecessor to SSH.
I admit I was too young to be well-versed in cryptography back then, but as far as I can tell the only well-known cryptographic algorithms that I can think of during the late 1980s were RSA and DES, maybe also ElGamal? I'm not aware of any cryptographic hash function which predates MD2. There must have been some, but I don't know of any of them really caught on.
Looking at PC software from the early 1980s up to the early 1990s, most of the software used 100% in-house roll-your-own-crypto. DES and RSA were initially too slow for microcomputers and even when processing power increased, they were not so trivial to implement yourself and there weren't widely available in libraries until the mid 1990s.
So what you eventually got in this period was mostly ad-hoc algorithms that did very rudimentary encryption and were only as good as the author's imagination. If you were particularly unlucky, they wouldn't be much better than a glorified monoalphabetic cipher. This seems to be the case in QText as well. At least the key derivation function seems to be completely in-house and as the paper has demonstrated (and as you'd fully expect from an in-house algorithm), it has weaknesses that make MD4 seem secure.
I think PGP (first released in 1991) is where we can see the trend start shifting into composing more-or-less standard algorithms using insecure in-house constructions. The first version of PGP used an in-house symmetric cipher called Bass-O-Matic (together with RSA and MD4), but PGP 2.0 replaced that cipher with IDEA[1]. It seems like in the beginning even the RSA signature format was non-standard, and PGP switched to a PKCS #1-based format only in version 2.3[2].
This where you start seeing all the famous 1990s schemes that go horribly wrong at misusing IVs or performing key derivation with a single-iteration of unsalted hash. But 80s crypto is even worse.
(of course, it’s still interesting to read about 90s encryption, so I appreciate that they did it the fun way)
I'm pretty sure you can automate DOSBox input, but if you're more comfortable with reversing algorithms than writing reliable UI automation script then what they did isn't necessarily an overkill.
It's the details that are the giveaway.
edit: I'm not sure why this is being downvoted. The website looks like this to me: https://i.imgur.com/q6846RF.png
edit2: not throttled by wix, although they are hosted with wix. There's some strange url parameters in the image src attribute, which I assume are supposed to do something fancy. That fancy bit isn't working.
edit: They work on my Android phone.
Are we still in "early software development"? Presumably most software that will ever be written hasn't been written yet.
On a practical note, we don’t tend to prefix zeroes to numbers because they are superfluous. If programmers are using strings to store a year and those strings are limited to four digits, your project likely has a host of other issues that will become problems long before Y10K.
We already have a precedent, in programming, for prefixed zeroes having meaning: “an octal number follows.” Much like 0x indicates a hexadecimal number.
Just in case it's serious or semi-serious:
It's utterly ridiculous to worry about 10k date problems given we first have these:
2038 problem ( Signed unix time overflow )
2069 problem ( strptime() parsing )
2079 problem ( unsigned days since 1 January 1900 )
2100 problem ( FAT/DOS )
2106 problem ( Unsigned unix time overflow )
Further out but still way before 10k:
2262 ( signed nanoseconds since 1 January 1970 )
And that's just the bigger ones. ( See: https://en.wikipedia.org/wiki/Time_formatting_and_storage_bu... )
What's the point of prefixing 0 to dates written forum posts? It just confuses contemporary human readers.
Historians do a reasonable job at adequately translating dates from thousands of years ago across multiple calendar changes and societal collapses. Whatever future historian 10k+ years in the future is reading your post, should it survive, will be able to work out the date in the post, just from the language and other context clues alone.
It'll be hard to confuse 12025 with 2025 in the same way it's hard to confuse 2025 with AD 25.
Its especially common in namings like: THING-01 THING-02.. we will never have more than 100 of them.. and then BOOM.
I always say: leave it at fucking 1 and count up. Thats why we invented Natural Sorting to sort this out...
For most situations, the better solution is storing the index separately to the name in another column or in metadata.
But for some stores, there isn't an easy way to do to store or sort on metadata, and so prefixing leading zeroes helps keep things stored more naturally while using the more efficient sort.
[0] ZIP codes and phone numbers are important exceptions, but it's a non-issue if you always process these as strings, never as numbers, which is a reasonable constraint because we don't need to sort these numerically. Lexicographical sort is perfectly fine.
[1] The concept mentioned in footnote 0 does not really apply to SEMVER, because we do like to sort versions numerically. Lexicographical sort is wrong. But it's a group of dot-delimited integers, not to be conflated with floats, so while 7.100 comes before 7.2 when sorting floats, 7.100 comes after 7.2 when sorting SEMVER because the 2 and 100 are just integers.
So, "the desktop GUI"? But Smalltalk-80 didn't have a desktop in the sense of a place to represent your files with icons, even if Star did. WYSIWYG? Direct manipulation? But Shneiderman's #1 example of "direct manipulation" is Emacs.
But it's also recognizably "the same" as medieval manuscripts in many ways!