Tops-10 Fortran-10 v11, TSU keys?
Al Kossow
It wasn't in very good shape (4 bad blocks) but what was recoverable
is up under http://bitsavers.org/bits/DEC/pdp10/magtape/dec_distribs/layered
Al Kossow
I found an alpha version of V11, which is now on line along with some
older versions. I was thinking about why the V11 tape was truncated and
I remembered today that the reason I never re-read it was that it was
very sticky and actually broke while reading it.
retro98
I'm wondering whether broken tapes can be spliced, and re-read
attempted? There would no doubt be bad blocks, but maybe the data after
the break is still recoverable?
The encryption keys are the last save set of the product release tape.
If those can be recovered, they're useful for decrypting the fortran v11
updates on the TSU tapes.
I'll have an update re: TSU keys in my next reply. Thx, retro98
retro98
The decryption keys needed to decrypt Fortran-10 v11 updates on the TSU
tapes are files:
FORLIB.KEY, FORO11.KEY, SINGLE.KEY, on tape "BB-D480G-SB FORTRAN V11"
The TSU scripts rename these files to:
FTNOTS:FTNOTS.KEY, FTNSYS:FTNSYS.KEY, FTNCMP:FTNCMP.KEY, respectively.
The APUTIL utility on the TSU tapes perform the decryption and checksum
verification. There's also a DCRYPT utility.
Here are the results so far from crypto analyzing the TSU
encryption/decryption methods.
Encrypted files and the key files both contain 18 word (36-bit word)
headers. Nothing special found with the header. The file format is:
header:
"777777777777
"000000000020
copyright string
zero padding
data:
encrypted data or decrypt key data
The encryption and decryption is a straight forward bit for bit XOR. The
XOR key is very long, and the key length is greater than the lengths of
the encrypted files.
XOR encryption is not intended to be super secure, thus it's possible to
determine the key with samples of encrypted and decrypted text. For
Fortran-10 v11, close enough samples are available, particularly those
containing ascii text.
I have recovered enough of the keys to decrypt the text files (and some
of the binaries that use the same keys) for Fortran on the TSU tapes.
The partially recovered keys are available at
http://www.asun.net/pdp10/downloads/for10v11-tsu-partial-keys-20090614.tap
Unfortunately, these don't cover the updated Fortran compiler
executables, since I don't know enough about binary file formats, and
don't have matching samples.
TO DO:
It's possible that the lengthly XOR keys were generated using a pseudo
random number generator (PRNG). I have not yet evaluated this
possibility. If a PRNG was used, then it may be possible to generate the
large key file from knowing just a small portion of the key.
Best solution overall is to recover a good copy of Fortran-10 v11 on
original product release tape "BB-D480G-SB FORTRAN V11"
jmfbahciv
>
>> Al Kossow wrote:
>>> I'm still looking for the V11 tape, but did find one for V10.
>>> It wasn't in very good shape (4 bad blocks) but what was recoverable
>>> is up under
>>> http://bitsavers.org/bits/DEC/pdp10/magtape/dec_distribs/layered
>>
>> I found an alpha version of V11, which is now on line along with some
>> older versions. I was thinking about why the V11 tape was truncated and
>> I remembered today that the reason I never re-read it was that it was
>> very sticky and actually broke while reading it.
>
> I'm wondering whether broken tapes can be spliced, and re-read
> attempted? There would no doubt be bad blocks, but maybe the data after
> the break is still recoverable?
You shouldn't have to splice them if written with BACKUP or FAILSA
or DUMPER.
>
> The encryption keys are the last save set of the product release tape.
> If those can be recovered, they're useful for decrypting the fortran v11
> updates on the TSU tapes.
>
> I'll have an update re: TSU keys in my next reply. Thx, retro98
that encryption idea was the worst one that LCG ever made.
Were those keys the same from one release to another? If so,
you could hack the code to read from one data set to decrypt
the other.
/BAH
>
retro98
On Sep 22, 8:03 am, jmfbahciv wrote:
>
> You shouldn't have to splice them if written with BACKUP or FAILSA
> or DUMPER.
>
That would be a neat trick. I think the OP referred to a
physically broken tape.
>
> that encryption idea was the worst one that LCG ever made.
> Were those keys the same from one release to another? If so,
> you could hack the code to read from one data set to decrypt
> the other.
>
I checked for that possibility. The keys are not the same between
releases (eg Fortran v10 and v11) nor between platforms (Tops-10 verses
Tops-20).
Al Kossow
> I checked for that possibility. The keys are not the same between
> releases (eg Fortran v10 and v11) nor between platforms (Tops-10 verses
> Tops-20).
>
Tim Shoppa should be posting the keys in the near future.
jmfbahciv
>
> On Sep 22, 8:03 am, jmfbahciv wrote:
>>
>> You shouldn't have to splice them if written with BACKUP or FAILSA
>> or DUMPER.
>>
>
> That would be a neat trick. I think the OP referred to a
> physically broken tape.
Put the reflective tape at the beginning of the second piece and
then do a restore. BACKUP will restore; I don't know enough
about DUMPER's format to know if it would work. If it doesn't,
use BACKUP to read the DUMPER tape in /INTERCHANGE mode. You'll
get the files but not the directory information.
If you are dealing with a broken tape, I'd use /INTERCHANGE for
the BACKUP restore, too.
>
>>
>> that encryption idea was the worst one that LCG ever made.
>> Were those keys the same from one release to another? If so,
>> you could hack the code to read from one data set to decrypt
>> the other.
>>
>
> I checked for that possibility. The keys are not the same between
> releases (eg Fortran v10 and v11) nor between platforms (Tops-10 verses
> Tops-20).
>
Perhaps not releases, but what about between updates?
/BAH