DBPBE Specifications

Home Specifications Single Byte Example Multi Byte Example Considerations


By Jacob Still January 2020.
Updated January 2021
Code on GitHub
Licensed under GPLv3



Encryption

1. Data to be encrypted is fed into the algorithm as raw binary bytes. These bytes are then converted into data points on a quadrant plane using the Data Point Look Up Table. This data point look up table must be consistent no matter the language (both programming and spoken), version, or implementation of DBPBE.


2. Key Points are created from a password, rng, keyfile, and/or other forms of data known as the key. The key is then hashed using the SHA-256 algorithm. The hashed key is converted to points using the Key Point Look Up Table. Multiple key points are generated from the hash.

Note: The number of keys that are required is defined as k=d+1 where d is the number of dimensions. I am currently working on higher dimensional versions of DBPBE. The current specs are for 2 dimensions.

This look up table must also be consistent no matter the language, version, or implementation of DBPBE.


3. The key points are numbered from largest sum of their coordinates to smallest sum.

Ka(4,5) -> 4+5=9
Kb(-3,2) -> -3+2=-1
Kc(15,-7) -> 15+-7=8

Ka is 1, Kc is 2, and Kb is 3

if two keys have the same sum, the one with the largest x value is numbered first.
if two keys have the same sum and the same x value, the one with the largest y value is numbered first.

Data Points are numbered in the same fashion.


The distance between each key point and data point are then calculated in order: (K1D1, K2D1, K3D1, K1D2, K2D2, K3D2, ...)
These ordered distances are considered the encrypted data. The Number of distances is the product of the data points and the keys.

The encrypted data should be output simply as the distance followed by a delimiter and another distance:
(3.2, 4.2, 3.6, 2.0, 3.4, ...)
There should be no special delimeter between sets belonging to the same data point as this would reveal the number of dimensions used:
(3.2, 4.2, 3.6; 2.0, 3.4, ...)






Decryption

4. First the key points are looked up in the Key Point Look Up Table. This is exactly the same as step #2.

A practical way to think of decrypting is in terms of vectors. The encrypted data consists of distances which can be thought of as the magnitude of a vector. In order to reverse the encryption process, the key points are used as a starting point for this vector.


5. Each distance (K1D1, K2D1, K3D1, K1D2, K2D2, K3D2, ...) is then converted to a circle -> (CK1D1, CK2D1, CK3D1, ...)

Since the direction of the vector is not known, and irrelevant, the distances are considered radii of circles with the respective key point as the center.


6. The intersection point(s) between each related circle is then found.

(CK1D1, CK2D1, CK3D1) then (CK1D2, CK2D2, CK3D2) ...

The point where the most circles intersect is considered the decrypted data point. This point can then be looked up in the Data Point Look Up Table (same as step #1). Points that are not found in the Data Point Look Up Table are considered invalid.

Note: It may be necessary for the point being looked up to be converted to a range to allow for rounding errors in floating point numbers. The percentage of error must be less than 0.05% or the point will be considered invalid.