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 |(.........Y@04 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?
_______________________________________________
Pspp-users mailing list
Pspp-users@gnu.org
https://lists.gnu.org/mailman/listinfo/pspp-users
