The idea begins with two partitions or extents of data. The first part (Part A) contains the authentication/decryption code, Part B contains code or mere data, whatever. When the code is run, it passes itself - the whole of Part A - through a secure hash algorithm (maybe SHA256). The result of this hash is the Primary Key. This is used to decrypt Part B. Should Part A be tampered with, the Primary Key will be wrong and Part B will be unreachable. This system as it stands is not secure, hence the additional ideas.

Additional idea 1 is to add authentication data, such as a passphrase. The authentication data is passed through the hash algorithm with Part A. Any method of combining the authentication data with Part A should be adequate, but I prefer to concatenate the authentication data to both the head and tail of Part A. Using the wrong authentication data has the same effect as tampering with Part A: Part B is unreachable. If the authentication data is correct, then Part B can be decrypted and you have access to the contents (such as an operating system).

Additional idea 2 is to add authentication and fast verification of the Primary Key by adding a new extent of data, Part C. Also, new data values are required to populate it. First, a new encryption key - the Session Key - is used to encrypt Part B instead of the Primary Key. Second, a pair of random numbers - Salt1 and Salt2 - is used to hamper cryptanalytic attacks. Thirdly, the secure hash of Part B - Hash B - in needed. Part C consists of the following data: Salt1 encrypted with the Primary Key; the Session Key encrypted with Salt1 and then the Primary Key; Salt2 encrypted with the Session Key; the Session Key encrypted with Salt2; and Hash B encrypted with the Salt2 and then the Session Key. If you have the Primary Key, you can decode Salt1, then the Session Key, then Salt2 and then the Session Key again. If the Primary Key is wrong, then the decryptions will yield garbage and the two Session Keys will differ. Then you decode Hash B and compare it with a fresh hash to detect tampering with Part B. Finally, if all is well, you can decrypt Part B.

Additional idea 3 is to use many pairs of Parts B and C, with corresponding authentication data. For instance, authentication data 1 would give access to Part B1, but not B2 (unless authentication data 1 = authentication data 2).

Additional idea 4 is to add more data to Part C. The Session Key no longer encrypts Part B. Instead, 2 new keys Data Key A and Data Key B encrypt the head end and tail end of Part B respectively. A new value, the Break Point, records the place within Part B the change-over is made. All 3 of the new values are encrypted with the Session Key and stored in Part C. In use, a (probably low priority) background process/service/daemon decrypts data just after the breakpoint with Data Key B, then re-encrypts it with Data Key A, then moves the Break Point forwards. This frequently turns the data over in the background, defeating analysis based on regular disk imaging.

Additional idea 5 is to extend 4 to add a moving journal. It requires a direction flag, and the Break point alternately moves from one end of Part B to the other, changes the key of the empty end (head or tail), then moves back. For instance, when moving up, data is read from above the Break Point, re-encrypted and written into the empty space below the Break Point, the data is committed, the Break Point is moved up and committed, and the next step begins. At the top, Data Key B is randomised, the direction flag in changed, and the journal moves back down toward the bottom.

Additional idea 6 is to use my idea of Ductile disk encryption when encrypting Part B.

One application of this would be to secure a laptop in a situation where an attacker may be able to image and/or alter the disk from time to time, e.g. in diplomatic use.

What do you think of this idea or comment?
(You can change your vote at any time)

I agree

No opinion

I disagree