Skip to content
Permalink
Branch: master
Find file Copy path
Fetching contributors…
Cannot retrieve contributors at this time
162 lines (130 sloc) 8.93 KB
This repository lists new cryptographic modes of operations ideas.
Below are descriptions for files that currently kept here.
CAUTION!
Please note that here are only modes which were never tested for absense of
logical, physical and other kinds of mistakes and errors! Before use, please
consult your cryptographician, and even after her positive conclusion, take
the conclusion with a good grain of salt.
Author takes absolutely no any responsibility for _any_ damages
this code will cause by improper and mindless use! Damages include not only
loss of data, but also data detection, stealing and uncovering.
Please also read COPYRIGHT AND REUSE section at the end of this document.
APPLIES TO
Please note that the reference code included here is useful only with "tfcipher"
library, which is available at https://github.com/lynxlynx/tfcipher .
You should put the file(s) into a copy of the repository, then run "make tfxpcbc.o"
to produce a compiled object file for XPCBC mode (as an example).
Resulting object file contains compiled functions for that mode, which you can use
by declaring function prototypes taken from source code translation unit.
If you need to adopt the mode to your own cryptographic library, please consult
the modes descriptions below and reconstruct the algorithm yourself.
tfxpcbc.c: implements XPCBC mode.
XPCBC is a storage media mode of operation. It is based on PCBC mode of operation.
XPCBC applies classic PCBC mode sector wide. Each disk sector is encrypted with PCBC,
with an initial vector derived from the current cipher block number.
XPCBC is considered better than currently widespread XTS because it can cover more
cipher blocks into the cloak than XTS, thus, hiding more redundant data and
making analysis of disk image difference much more harder.
XPCBC reference implementation permits specifying an arbitrary sector size with
"bpi" function argument (you should specify 32 for generic 512 byte sector and
16 byte block cipher). The higher this number, the harder to tell the shape of
data in a disk image differences.
OK, how sector wise PCBC is better than XTS?
PCBC is unparallelizable mode of operation, which requires you to decrypt the whole
stream to get the required piece (in case of random media access), which, of course,
is completely unsuitable for a disk mode of operation. The "hack" there is to break
PCBC into small chunks called sectors (just equal to the disk sectors in size), and
produce a unique IV for each such encryption, from, say, sector number or current
cipher block counter number (this does not matter, really). Every such chunk can be
dealt with in an absolutely parallel way, as far as the're small enough.
The benefit over XTS is that PCBC "automatically" provides us an ability to cloak
the tail of sector from the point of change. Say, a single bit was flipped in the
middle of 512 byte sector (in 256th byte), this means that XTS will mangle only
single ciphertext block of 16 bytes at the middle of sector, while PCBC inside
XPCBC mode will mangle this ciphertext block plus all ciphertext blocks from the
one that contains the change, down to the end of sector.
In a image change difference, this will look like that:
Plaintext XTS XPCBC
|................| |................| |................|
|................| |................| |................|
|................| |................| |................|
|................| |................| |................|
|................| |................| |................|
|................| |................| |................|
|................| |................| |................|
|....F...........| |RRRRRRRRRRRRRRRR| |RRRRRRRRRRRRRRRR|
|................| |................| |RRRRRRRRRRRRRRRR|
|................| |................| |RRRRRRRRRRRRRRRR|
|................| |................| |RRRRRRRRRRRRRRRR|
|................| |................| |RRRRRRRRRRRRRRRR|
|................| |................| |RRRRRRRRRRRRRRRR|
|................| |................| |RRRRRRRRRRRRRRRR|
|................| |................| |RRRRRRRRRRRRRRRR|
|................| |................| |RRRRRRRRRRRRRRRR|
Here, 'F' in Plaintext sector shows the byte that had changed ("flipped" bit inside it),
and 'R' in both XTS and XPCBC sectors show the cipherblocks that experienced the
avalanche force due to encryption. As you may see, XPCBC covers more data into
pseudorandom cryptographic noise rather than XTS alone.
Unlike XTS, XPCBC is not restricted to certain ciphertext block size or cipher being used.
Now about XPCBC flaws, disadvantages etc.
XPCBC, surely, will leave data that reside earlier than change within a sector unaltered.
This is obvious. If the change happened just inside the last ciphertext block of sector,
then only this single block will be mangled, but the rest will be left intact. Thus,
for such cases, XPCBC will work just like XTS mode.
XPCBC relies on possibilities when changes will happen to be mostly in beginnings to
middles of most sectors, with fallback to XTS in the very worst cases.
Because XPCBC has no additional overhead (it is same in performance as XTS, and
even faster than XTS due to lack of mandatory GF multiply operation, being purely
"mechanical" mode of operation just like, for example, CBC), it is considered as
improvement over existing XTS mode of operation.
XPCBC shares with PCBC mode the same fate of being vulnerable to exchange of two
adjacent ciphertext blocks. In PCBC, such exchange generate no garbage on decryption
which should normally continue past the exchanged pair of blocks. The exchanged pair of
blocks however turn up into an unpredictable garbage, so their content cannot be controlled.
tfwbm.c: implements WBM mode.
WBM is a storage media mode of operation. It is based on PCBC and CBC modes of operation.
WBM stands for Wide Block Mode or Wide Block Method: a mode which guarantees that single
sector will be mangled as whole on a single change which location cannot be predicted.
WBM "fixes" XPCBC mode by ensuring that data prior the change within the sector will
be also mangled into an unpredictable cryptographic noise. This comes at an unavoidable
cost of encrypting the single sector twice, thus, performance will be as half of original
XPCBC or XTS modes.
To mangle the whole sector again, the critical feature of PCBC is used:
infinite change propagation from the point of modification.
To ensure such a change will be "detected", a hashsum is generated first.
WBM algorithm can be (simply) described as:
* Encrypt sector in CBC mode, then XOR (compress) all resulting ciphertext blocks
into a "header" hashsum, in CBC-MAC mode,
* XOR the hashsum with first plaintext block (steps 1 and 2 can be performed in a single operation),
* Encrypt the CBC encrypted data with changed "header" again with PCBC mode, so
PCBC will catch every change happened due to unique hashed "header" block.
* All CBC/PCBC encryptions are performed with derived IV from current sector/counter number.
As described, WBM achieves full sector modification on a change that occurs everywhere
within the sector (in beginning, middle or even inside last ciphertext block).
Complete analysis of WBM mode was not performed, thus, it may be vulnerable to certain
attacks that may apply to either CBC or PCBC modes, or have it's own unique ones.
It was however proven that no currently known CBC and PCBC mode flaws affect WBM mode in any way.
WBM features:
* Each sector is guaranteed to be unique on every change(s), significant or not,
* Defined for any block cipher with any block size, and sector size can be arbitrary,
* Relatively simple, does not include special math - it is a "mechanical" mode.
WBM flaws:
* Twice as slow than any "general" block cipher mode of operation,
* Number of unique sectors is bound to 2^(cipher_block_size/2). However, to this point,
number of ciphertexts rather than sectors will be long as exhausted already.
* No extensive analysis was performed, maybe vulnerable,
COPYRIGHT AND REUSE
Author guarantees that ideas published here are patent-free, free to reuse worldwide,
and bear absolutely no any copyright status, i.e. these algorithms are public domain.
However, this status comes at the cost of absolutely NO ANY WARRANTY OF ANY KIND.
Author also does not claim the uniqueness of presented algorithms. If it is known
somewhere else, it is only because author did not heard about it. You should report
such case in "issues" here, on github, or send me such report by email
(lookup it in AUTHOR section at the bottom).
If you take these and reuse, then you take the FULL responsibility for any data leakage
that happened, including sensitive data, business data and other valuable materials, as
well as any data loss, including valuable materials.
In other words, these things are knife and axe. If you kill people with these tools,
will anyone claim that smith who made them is guilty? No, this is nonsense.
AUTHOR
Andrey Rys, <rys@lynxlynx.ru>, 04Mar2019.
You can’t perform that action at this time.