Comments
mee • August 12, 2020 7:55 AM
@Ismar
Any software or hardware made by human is even more unrelieable, and what’s even worse, inherently less secure. You can’t have security and convinience at the same time.
Mr. H • August 12, 2020 9:32 AM
@mee,
You can’t have security and convinience at the same time.
Amen!
Furthermore, if you automate it (for convenience) so it’s marketable (making profit by mass producing it and by selling it to non-techies) then you just take the money and run. Who cares about the security? Gimme that shiny plastic gadget, it looks awesome, wait till I show you things it can do. No accountability! That’s the bottom line. Design garbage, sell garbage, take the money and run. There is NO way around the machines. Machines will have to rule us humans when it comes to designing better security concepts for many reasons, an important one being randomness. Most humans are creatures of habit and our brains can only compute so much. Think of the hard drives made 20 or 30 years ago. A tiny USB stick today with density of 128 GB versus a huge HDD from 30 years ago that stored 4GB or 8GB. And that’s just comparing the physical size vs. density, and let’s not get into read/write/transfer speeds since they’re different types of memory to begin with. While designing amazing things we are unable to keep improving ourselves, in fact, us humans tend to go in the opposite direction – machines can be programmed to learn and to improve while we tend to deteriorate as we age. That is until someone invents external storage (USB?, hot-pluggable preferably-LOL) so us humans are “compatible” for future “upgrades” and memory/speed/storage “expansions”. Oops, almost forgot to take my meds.
echo • August 12, 2020 9:32 AM
Old versions of Zip files were known to be broken and easily cracked for over a decade. I can’t remember if it was this case or another case but the second I heard data had been lost inside a Zip file this would have been the first thing I checked. Their processing fees even at $7000 seem a little on the high side. Methinks they’re bundling the costs of their coding error in. As a client it’s not something I’d want to pay for.
The client was pretty smart just to give them the headers.
“It’s one of these ancient attacks on a crummy scheme, and nobody would have thought about it being relevant. But believe it or not, this bad stuff is still out there everywhere, so it’s actually really relevant.
It was the first thing I thought of. As you get older you notice the world begins to loop in a number of ways. With regard to “you cannot step in the same river twice” nonetheless it helps to have a long memory. Younger people can be energetic and smart in their own way but things which are new to them are old (for relative definitions of old) to someone else.
Kronos • August 12, 2020 10:03 AM
Had to work on an old Windows XP PC for a client several years back. It had a critical database that a software vendor planned to use for upgrading the client to a new, whiz-bang database system. The only problem they had was getting the actual database file off the computer. It wasn’t connected to a network, it had a CD drive (no CD-R) and the single USB port didn’t work. The file was too big to put on a single 1.44Mb floppy disk.
I thought of two ways to get it off. Remove the hard drive and add it as a second drive to my desktop PC and simply copy the file off. It would have worked but it would take too much time (client was far from my desktop and didn’t want the hard drive to leave their premises). I successfully did my second idea: use an old version of PKZip to SPAN the database across 4-5 1.44Mb floppy disks. One of the disks was bad so I had to make a second set, then use PKZip to recombine the file on one of the only other PCs they had with a floppy disk drive.
They were astounded that it worked and I never told them it was a common fix … twenty or so years ago.
NotKronos • August 12, 2020 11:09 AM
@Kronos,
just curious what your post has to do with the TOPIC:
“Cryptanalysis of an Old Zip Encryption Algorithm”?
Bob • August 12, 2020 11:31 AM
@NotKronos
He was clearly expanding on the thoughts expressed by @echo, especially those in the final paragraph of @echo’s post. Sometimes, when multiple people are discussing something, the conversation will veer somewhat from the sentence or phrase that started the discussion. Most human brains, especially given a set of common interests related to the matter at hand, are capable of following the context. When working with a written medium, one even gains the advantage of being able to re-read the context before asking passive-aggressive questions whose answers become clear upon considering context.
echo • August 12, 2020 12:46 PM
@Bob @Kronos
I didn’t see the connection but yes I agree it helps prove that “knowing tricks” and “older knowledge” from earlier problem solving is a thing. It’s far to far off topic but I’ve been learning things to do with DIY and repairs during the pandemic and it’s pretty similar with these areas too plus law and I dare say many other things too.
Back on topic I know custom ASICs and GPU clusters are a thing but depending on which algorithmic approach they were checking, and the article didn’t say, it’s difficult to know exactly how much the client was ripped off for or if they inadvertently went the long way about. lol. The same is true with DIY. Even professionals get in a knot over whether to use PVA or not. This is partly because of branded products and partly because nobody shares information. So you get a lot of people either picking the wrong product or using it wrong or not doing preparation or finishing work they are supposed to so swearing off it which for some jobs is the wrong thing. Much like this zip decryption problem it’s likely they didn’t have to code much for optimisation in the old school way and could rely on more memory and fast GPUs but again DIY is the same. Power tools and the technology now baked into paint does all the work for you. Farming isn’t too different either as in a similar time scale we now have soil technologists and automated milk parlours.
Yes the old days were better in a lot of ways but nobody would want to go back.
Of course the next thing is now their client has effectively paid for their R&D they now have a toolkit they can commercialise and possibly even securely automate. That’s pretty much free money. Lawyers do the equivalent of this all the time. Lawyers (and the state sector) don’t always catch their own mistakes though and that can get VERY expensive.
MarkH • August 12, 2020 12:56 PM
@echo:
Is it likely that the customer who searched down a practitioner with sufficient expertise to take on his problem, and was thoughtful enough to furnish only the file header, didn’t do a web search on a phrase like “crack zip archive” … which would immediately have led to numerous cheap software crackers?
To my knowledge, all of those zip crackers apply password guessing.
If the customer recalled that he had made quite a long password, not composed of dictionary words (as a conscientious person might do for valuable data), then it might soon have become apparent that available crack software couldn’t do the job in a feasible time frame.
I don’t know that this is what occurred, only speculating …
lurker • August 12, 2020 1:11 PM
@Mr.H, you had 4GB disks 30 years ago? I remember 30 years ago doing sneakernet with 20MB external SCSI disks. I also remember being put off disk encryption by the loss of a 800K floppy due to bitrot. We had tools to recover minor bitrot on unencrypted disks.
About 30 years ago I was given the task of recovering a fat Mac with an encrypted 10MB HD. Since the user was long gone, the disk was believed to contain nothing mission critical, and we still had versions of MacOS 3.1 and 3.2, it was simple to just pass the HD a few times over a videotape eraser. The system reinstall was frighteningly like most of the BSD of the time: it booted you as root with no password.
Winter • August 12, 2020 3:30 PM
The above link is to the YouTube version, which does not honor the CC license and blocks downloads. All Defcon presentations can be accessed for download and reuse directly from
https://media.defcon.org/DEF%20CON%2028/DEF%20CON%20Safe%20Mode%20video%20and%20slides/
Michael Stay’s presentation is:
Winter • August 12, 2020 3:46 PM
@echo
“Outside of a lab nobody needs to know and they neither gain nor lose anything when not knowing about it.”
I do not see it like this.
This substance, like biological warfare, is in the class of agents that will kill everyone but the best equipped parties if they try to produce it. Anyone trying it out is a contender to the Darwin Award.
Remember how the USSR produced Anthrax only to kill 100 Soviet citizens (Sverdlovsk anthrax leak).
In the end, bullits and explosives are cheaper, easier, and more accurate than exotic poisons or germs.
echo • August 12, 2020 3:51 PM
@Winter
imho everyone is trying to be “clever” just a little too much. I’m not going to argue it. Mind made up and not budging. Yapping is irresponsible.
Tatütata • August 12, 2020 10:02 PM
I was playing with 1Gbyte 8inch hard drives back in 1982-3 for use with a body imaging system (what was known as “Nuclear magnetic Resonance immiging” (NMRI) back then.
Clive, are you sure? The first IBM 3380 models announced in 1980 had a capacity of 1GB, but on 14″ platters. They were BIG, and their housing had the volume of a yuge US-style fridge.
https://aphelis.net/first-gigabyte-hard-drive-ibm-3380/
IBM was a leader in magnetic storage, and achieved among the highest densities, so this would have represented the leading edge SOTA.
Their I/O channels weren’t particularly fast. Specifying files on “DASDs” was fairly inconvenient by modern standards, on a system such as MVS you had to precisely define in advance the number of tracks and cylinders occupied, fixed size sectors weren’t really a concept.
The 4GB mark was reached with the 3390 series a decade later.
I remember splurging the better part of a young engineer’s salary on an 85 megabyte drive around 1989.
Just checked patents. EMI and Picker were the main UK companies in the NMR field back then (but in different markets), and ICL had some stuff in HD error control. I couldn’t find anything resembling your description in the 1980-1990 time frame.
Recovering the [Microsoft Word 97] key was usually instantaneous, but to help people feel like they’d gotten their money’s worth, we’d put on a little animated show like a Hollywood hacking scene with lots of random characters that gradually revealed the right password.
OK, they must be the guys who do all these crummy special effects in spy thriller films. 🙂 At least they seem to have left Clippy alone.
MarkH • August 13, 2020 1:08 AM
@Tatütata:
By a little web archaeology, I found that Fujitsu had 1 GB (and even 2 GB) models in the 8 inch form factor.
Looking at the first part number (in numerical sequence), I found a controller for same listed under replacement parts for Philips MRI machines — but no dates.
From other reading, I estimate that Fujitsu probably reached 1 GB not sooner than 1985.
What do you think, Clive? Do you recall which drive manufacturer? Could it have been a few years later?
Clive Robinson • August 13, 2020 2:47 AM
@ Tatütata,
Clive, are you sure?
It would appear I’ve had my post censored per someones “catholic request”.
But yes the clue was “hand carried” from Japan, you could say we were field trialing them. The company concerned is a now well known Japanese industrial conglomarate, that also was in the body scanner business oh and they still make super computers.
As for SASI (later SCSI) it surfaced about three or four years before in the late 1970’s. It was at the time an interface that could deliver the required performance unlike most others then available that kind of assumed the HD controler would be “off drive” with just analogue and motor control signals comming onto the drive.
It later interested me greatly because it potentially was a lot faster than most standard “back plane” data busses of the time (it gave 5MByte / 40Mbit, many computer busses were slow in comparison at 1 or 2 Mbyte). As I quickly came to realise it had some other advantages –multiple initiators– which was why I was looking at it for computer PCB to computer PCB comms to make what we would now call a “cluster”. The reason being the popularity of the Uni of Essex MUD. Lots of people wanted to play it but even very expensive DEC computers could only handle a few users. Higher end micro chips from the likes of Motorola were getting very very inexpensive by comparison a group of us got together to look into what would be needed, one of whom who was quite interested was a popular author. As it turns out whilst the hardware could be got to work the multiplexing and demultiplexing of user actions into block sizes that were efficient to move around was a problem the software side could not solve back then. However they were fun times when anything appeared to be possible.
BosnianBill • August 13, 2020 4:34 AM
@echo
I used to think you were MI6 until you broke your opsec by … – you need to lift your game before Russians and Chinese eat you for breakfast
Mee • August 13, 2020 4:42 AM
@Mr. H
The most facepalm worthy technology is a smartphone automatic password manager with auto-fill feature. But now when I’m thinking about it, there is one thing that’s more secure than a strong password in your head. Not having the information to secure in the first place. It’s the best security measure for handling personal and sensitive information.
Tatütata • August 13, 2020 9:33 AM
If you want to scrub all references to a certain compound because of its terrifying nastiness, good luck. A German chemistry handbook right here on my shelf has slightly more than one full page (out of ~1400) discussing this class of compounds, but without any safety caveats. Wikipedia (EN) has at least two directly relevant entries, and other languages offer a few additional references. There are 1400+ patent families mentioning this compound, which has/had a surprisingly broad range of applications (at least to my eyes). A recent filing from 2017 mentions this compound as a candidate in the treatment of certain cancers. (Which reminds me, chemotherapy literally has its origins in mustard gas warfare. That figures.) The US NIH medical literature database returns about 350 related references, of which half are available online. Some papers discuss the evolution of the attitudes toward these compounds in the last ~150 years (including ill-advised attempts for use as a medication, even though its acute toxicity was known since the 1860s). This compound is also spread in the environment as a by-product of an industry many, if not most, would like to disappear ASAP (except perhaps SCROTUS). The EPA.gov web site (still?) has about 9000 (YMMV) Google hits. If you were to consign all that to the memory hole, how can present and future generations be warned against them? How can you discuss this danger without naming it?
The mere mention of a name on a blog will hardly make things worse, unless perhaps one was to draw attention to it.
While you’re at it, you might also want to take out other compositions out there. Botox for instance. Or Dioxin — together with polonium, a trusted potion of the Muscovite poisoner’s toy chest — which shouldn’t be too difficult to prepare in your kitchen, if you don’t mind dying. (I had a power engineering professor who was appallingly casual about PCBs. Idiot.) Or beryllium oxide (you probably have several milligrams of it in the computer before you, but you can also buy by the tub). Or fluoride. (Col. Jack D. Ripper: Do you realize that fluoridation is the most monstrously conceived and dangerous Communist plot we have ever had to face?. In fact, there was a conspiracy, but it wasn’t from where some would have thought.)
Regard the cracking of ZIP encryption, if I understand correctly, the blog entry states that five bytes were needed as a crib, but only four were available. I suppose that the author used the four-byte ZIP local file header signature (0x04034b50), but it’s not too clear to me whether this is the case, as one can make a good guess at the first bytes immediately following (“minimum version needed to extract” and “general purpose bit flag”, each with two bytes). Directories entries are present twice in a ZIP file. There is a local directory before each compressed file. Then all local directory entries are copied into a central one at the end of the file, for faster access. You set the file position at EOF, walk back a few bytes, look for a pointer, and then you find your directory. There is therefore a lot of predictable information near EOF, but can their cracking method work from the end?
[As an aside, I maintain a dataset of several terabytes in a multitude of (unencrypted) ZIP files, which is way faster, simpler, and more portable and efficient than a DB engine with BLOBs. My shlockware handles the ZIP files directly in memory, which makes the data mining feasible on laptops – one updates the data every week under Linux, and the other one crunches under Windows. One of my programs didn’t sync properly the local and central directory entries after updating, and I was completely befuddled for weeks. I’m rewriting parts of it, and hope to get finally get threading to work (my speedup is embarassingly below 1…). The bottleneck is in the XML processing, and the apparent culprit the memory manager. Porting to Linux results in a performance hit, and I began rolling my own fast, read-only, XML parser.]
@Clive,
Tnx for the clues. Back then, my IT horizon didn’t extend very far beyond Armonk, Maynard, and a bit of Cupertino (before it became a cult). What seemed to me a crufty way to access IBM DASDs is actually a feature called CKD.
I’ll probably be off-line for a while, heading to a place in the countryside without an internet connection (I fear the withdrawal, but then I’ll escape the generalised crazy). I just have to get off my chair, and spend several hours on a train sweating with a mask on my mug.
Clive Robinson • August 13, 2020 12:32 PM
@ MarkH, Tatütata,
By a little web archaeology, I found that Fujitsu had 1 GB (and even 2 GB) models in the 8 inch form factor.
The old “I can neither confirm or deny” rule applies as NDA’s apparently go with you to the grave, even if the company you worked for has long since split up and kicked the bucket one way or another.
That IBM drive by the way had been designed a lot earlier than the available Internet articles would suggest. From what I’ve been told most of it was based on work done in the early 1970’s but IBM had a policy not to bring out products with competition with it’s existing products… (wgich is why the OC was a “skunk works” project). They also had an “artisanal” aproach to design which ment things got over engineered in entirelt the wrong way, which might account for that drive mechanics –not the electronics etc– comming in around 75kg (yup not far shy of 12stn or “one and a three quater pre war brides or one labouring man”).
Infact that drive had several other claims to fame apart from power consumption due to excesive need for temprature regulation. But whilst it gets remembered for being the first 1Gbyte unit, less well advertised is it was the swan song of that type of hard drive system. IBM effectively forced the market to pay for the development cost by it’s “tied-in” tricks but it was the death knell of that sort of over engineering.
It was not just Japanese engineers that had solved a lot of drive head problems etc in ways their managment liked, but that IBM’s had not. A look around modern drive technology tells you who’s ideas were right and who’s had entered an evolutionary “dead end”.
As for,
If you want to scrub all references to a certain compound because of its terrifying nastiness, good luck.
My reasoning for mentioning it was not the chemicals potential for doing truely unpleasant things, but the effects of what happens when people realise they have got things badly wrong (a leason we are currently relearning).
Back then the safety advice was based on “assumptions” not “practical testing”, the result was an expert in her field following the safety advice died an untimely death.
When you examin nearly all ICT Security advice, what you find is it is likewise nearly all based on “assumptions” not “practical testing”. Thus knowing this it’s not hard to guess how many of the security failings were entirely predictable on known facts derived from “practical testing”[1]…
Yes there are “unknown unknowns” waiting to be newly discovered, but there are one heck of a lot of entirely predictable “unknown knowns” that is once a class of attacks is correctly identified other new instances of attack become all to easily predictable.
An example of this is the recent anouncment about the likes of Meltdown on Intel Chips being incorrectly assumed to be software prefetch failings… By looking at other instances it became clear they all had infact a common failing and it was not prefetch… Which has made several people realise that there is now “fresh kill” to be made on new instances of this now known class of attack.
But the realy sad thing is how even the same instances of attack, given a little time get to work again. For instance as we were talking about hard drives the overwrighting of the MBR, which was a thing of the “sneaker-net” days came back in the Internet days…
The reason we get so many “assumptions” in ICT Security is not at all helped by the almost entire lack of usable measurands by which sensible practical testing can be carried out. A fault I suspect is not going to get addressed for quite some time as it appears currently “Myth is more profitable than fact”.
Oh, with regards,
I’ll probably be off-line for a while, heading to a place in the countryside without an internet connection
Be carefull, it’s perhaps worst in France where the whole country appears to go on holiday for the same two weeks each summer, but there might be more people heading in the same direction as you than you expect… Apparently there have been fights reported at UK “camping grounds” where “social distancing” has ment less people can be squeezed in.
Not a problem I used to suffer when I was younger in that my tent was a tarp and a bit of para cord and could be put up between a couple of trees almost anywhere, and as long as you pitched late in the day or after dark and were on your way by six the following morning and left no signs behind nobody was usually ever the wiser, and the excuse you got lost in the dark used to get you out of trouble most other times. Private woodland has always been a welcome home to me, especially as you don’t get noisy neighbours 😉
[1] If people look back they will find I’ve mentioned on several occasions the ICT industry in general not just security fails to learn the leasons from it’s history that are easily within living memory. Many failings are almost the same as those less than a decade old. Thus as has been observed in the past “Those that fail to learn from history find themseves condemed to relive it”.
echo • August 13, 2020 5:17 PM
@Tatütata
You’re entirely missing the point for my caution and you will have to figure out yourself why I am being cautious. There is law and policy papers and some experience and real world threat on th issues and type of phenomena which worries me. There’s other things I won’t mention “just to score a gold star” even though Clive talks around the subject. He misses things sometimes and I’m not going to fill in the blanks for the same reasons. For some things democracy is not harmed and nobody loses if it’s kept behind acadamic walls or in the lab.
Please don’t think this is a “freedom of speech” or ego or power struggle thing. It’s not. While I’m happy to provide my reasoning in full in confidence to Bruce on request I’m not prepared to discuss it online. If you disagree take it up with Bruce.
Subscribe to comments on this entry
Leave a comment
Sidebar photo of Bruce Schneier by Joe MacInnis.
Ismar • August 12, 2020 7:41 AM
While the video is very valuable to those interested in cryptography, I think that the main point here is the fact that people tend to forget their passwords and that we need better mechanisms of limiting the access to information than relying on something as unreliable as human memory