How do the TV program codes for VCR Plus+ work?
Is this algorithm supposed to be real? It looks a lot more like disinformation spread by someone who doesn’t want someone to try to find the formula.
A second possibility is that the person providing it honestly thought they saw the pattern but then a new data point didn’t fit, so they kept adding steps hoping to solve the latest flaw they found. Each patch covering more of the known data points but still unable to predict all the next ones. In other words, not solved yet.
The main thing is that the printed codes have to map to a discrete day, time and duration.
Most likely they are unique in this, but that’s not strictly a requirement.
What is required is that every day, time and duration can be given a code.
Some of the steps outlined in this column tend to leave big gaps the target schedule population.
Since the column is over a dozen years old, has a better algorithm been reported?
Have you seen Rijndael lately? The VCR Plus+ algorithm not only doesn’t look that complicated, it looks like the sort of complications a good amateur might introduce.
I was going to say that, based upon my recent lesson in the history of cryptography, that didn’t seem so far-fetched, and obviously, it wasn’t as unbreakable as perhaps the manufacturer intended.
I don’t think anyone bothered with VCR+ much after the late-90’s because there were better options available, as VCR’s got smarter and had better programmability. The original ones were pretty much just turn on and turn off at the scheduled time, which left you pretty unhappy when you wanted to do multiple things while gone. Today’s VCR damn near makes the toast and pours the coffee for you.
A lot of poorly informed programmers write cryptography algorithms like this (or even more absurd) in the mistaken belief that “it’s complicated” means it’s hard to break. In fact, certain complications often end up magnifying the very patterns you’re trying to hide.
Schneier, Knuth, and others therefore always recommend that one design secure systems with the assumption that your enemy always knows the algorithm. Because really, it’s often not that hard to deduce, especially if you have both sides of the equation (in this case, the VCR Plus code and the time, channel and duration of the program it refers to.)
As an aside, cryptography is simply fascinating. When we were learning about it last semester, our teacher was a guy who had worked on numerous projects involving cryptography, brought in as a guest lecturer by our professor. Man, was that a fun time; he could make anything in the field sound sexy!
My hunch exactly. I think the people making it would have been working it from a different angle.
Instead of trying to hide they method they would be more concerned with just trying to fit the most possible program time combinations into the available numbering scheme.
Do the math and you see that the original 5 digits would not last a month for shows starting and stopping times and the then-available 99 channels. Of course once the channels soared the codes got longer.
But in the beginning 5 digits was already a lot to sell people on.
So my guess is that the algorithm probably referred to a few tables in memory that held common combinations. A couple of table references would combine for a code. And these tables would begin and end at relatively random points for random lengths, just lying where they fell when the assembler was called upon to assign them an address.
This sort of thing looks like tricky math if you don’t know there are tables involved.
That’s like trying to “solve a cipher” when actually the other guy is using word substitution. There may be algorithms that end up with the answer, but they won’t be needed by the devisors of the word list.
This is a good idea and tables would be a really convienent way to really obscure the mapping. But if tables were used, say a set of bits are used to lookup the day, then the algorithm would have a lot more exceptions. Four or five days might map to some weird function, but then the remaining days would have exceptions. Unless, of course, the table was generated directly with an algorithm, but in that case you wouldn’t need the table.
The Wikipedia article on VCR+ has links to source code for 6, 7, and 8 digits VCR+ codes. I took a look at the source code to the 6-digit codes here. It is based on the work published in the Cryptologia article, but with further refinements from several others. As a result, the algorithm looks a bit simpler than what Cecil mentions. Roughly, the time factors are packed together and then the result is scrambled. The scrambling is done using a magic number and a bunch of for-loops. I don’t know if the scrambling is a good algorithm or not (I don’t know much about cryptography), but the overall design is clean – the encoding is seperate from the encryption.
It doesn’t seem correct to assume that there encryption strategy was based on just being complicated. You couldn’t have a really strong encryption algorithm that maps start date, start time, duration, and channel into 6 digits (1 million combinations). Especially considering, as friedo points out, you publish thousands of input/output pairs a day.
Did anyone else think it was awkward when Cecil described the zip file as a program?
I did think the .zip as a program was strange, but then I remembered it was from 1993, so I cut a little slack. I didn’t know what a .zip back then. Granted, I was 7 years old, but, you know. . .
I bought one of the most recent mass-marketed VCRs (those suckers are becoming as hard to find as record players!), and it handles VCR+ and VCR+Gold, which may be a later algorithm.
I bought it after I gave up broadcast for satellite, and now I have TiVo, so I’ve never used either system to try and record.
