Re: encrypted SPSS .sav files

[Ben Pfaff]

On Fri, Oct 25, 2013 at 01:36:44PM -0700, Basti?n D?az wrote:
> Ben, I've modified the encrypted files in the repository PSPP-dev-utils. I 
> updated the folders "BDI-II", "demo" and "PSPP-examples".
> 
> Inside, you will find a folder called "encrypted" with 3 sets of files (SAZ 
> and ZSAV files).
> 
> The series keys are the following (without quotes):
> A series: "pspp"
> B series: "abc123"
> C series: "Abc123Dfg456"

Thanks!

I learned quite a bit on a first look here.  I'll say what I know, and
then I have a couple further requests for assistance at the end.

All of the files begin with the same 36 bytes:

00000000  1c 00 00 00 00 00 00 00  45 4e 43 52 59 50 54 45  |........ENCRYPTE|
00000010  44 53 41 56 15 00 00 00  00 00 00 00 00 00 00 00  |DSAV............|
00000020  00 00 00 00

All of the files that contain the same data are exactly the same size.
That tells me that there is (so far) no such thing as an encrypted
compressed file.  That might slightly simplify the implementation if I
can figure out the format.

All of the files' sizes, in bytes, are 4 greater than a multiple of 16.
That probably means that the files are compressed with a cipher that has
a block size of 16 bytes, which suggests AES.

It appears that the files that contain the same data, with the same
password, differ in either exactly 16 contiguous bytes (starting at
offset 132) or exactly 32 contiguous bytes (starting at offset 116) and
are otherwise byte-for-byte identical.  I guess that this means a few
things:

        - It supports my guess of a 16-byte block size.

        - 116 and 133 are both 4 more than a multiple of 16, suggesting
          (as do the fixed-length 36-byte header and the file sizes)
          that each ciphertext block starts 4 bytes past a multiple of
          16 in the file.

        - Either ECB or CTR mode is likely in use.  This indicates weak
          cryptographic design, no decent cryptographer would have
          designed the file that way.  (That's good for me, it may make
          the work easier.)

          Actually it's very likely to be ECB mode, because I can see a
          number of ciphertext blocks repeated many times in the BDI II
          files.  (That's a terrible cryptographic design.  Whoever
          designed this flunked Crypto 101.)

Taking all this together, it suggests that the bytes that differ in the
encrypted files correspond to bytes found 36 bytes earlier in a
corresponding plaintext .sav file.  Looking at what appears at those
offsets in an ordinary .sav file, it includes the time at which the file
was saved:

00000050  28 00 00 00 00 00 00 00  00 00 59 40 30 34 20 4d  |(address@hidden M|
00000060  61 79 20 30 39 31 31 3a  30 30 3a 33 35 20 20 20  |ay 0911:00:35   |

which makes some sense: you obviously didn't save all those files within
a single second, so the time is different in each file.  But there's
still a little mystery, since that only accounts for 16 bytes changing,
not 32 bytes.  Maybe there's an additional offset so that the minute and
the second are in different ciphertext blocks.

So, here are some further requests:

    - Can you tell me the creation times as specifically as possible
      (down to the second, if you can), for each file, as recorded by
      the operating system?  If it's too much trouble to do that for all
      the files, then just for all the BDI files would give me almost as
      much information.

    - I see that there is some documentation for an ENCRYPTEDPW keyword
      on SAVE.  The documentation suggests that if you use a dialog box
      to save an encrypted file, but request pasting syntax instead of
      executing it, you get an encrypted password in the syntax.  Could
      you use this to generate the encrypted password for each password
      that you used, and show us the encrypted passwords?  If you paste
      syntax for the same password twice, is the encrypted password the
      same each time?