# The DBPBE Encryption Algorithm

By Jacob Still
January 2020 Updated August 2020

Code on GitHub

The Distance Between Points Based Encryption algorithm uses fundamental 2D algebraic equations to encrypt data. While this method is mathematically more complicated than say AES, DBPBE offers a more secure synchronous cryptographic cipher.

Examples at the end

## Encryption

1. Input data is read as bytes and converted into data points on a quadrant plane. The process of converting each byte into a data point should be consistent no matter the password/keys, version, or implementation of DBPBE.

Note that the data point conversion is still being developed.

2. "Key points" are then generated. These can be derived from a user input, random number generator, or other forms of random data. The generation of these key points is not strict like the data points, but has to be consistent between versions and implementations.

Restrictions on keys are the following:

• One password should always result in the same key points on every version and implementation of DBPBE
• The number of key points to be generated is still under consideration, but at least three are required
• No key point can have the same coordinates as any data points
• Key points should be numbered from "top to bottom" (the key point with the largest y value would be first and the key point with the smallest y value would be last)
If keys are generated from a rng, they should be saved and fed to the algorithm in the same manner (top to bottom numbered).

3. The distance between each key point and data point are then calculated. The encrypted data are these distances between key points and data points. This results in an output consisting purely of distances. This will result in `K*D` number of distances depending on the number of data points `D` multiplied by the number of key points `K`.

## Encrypted Data

The encrypted data should be stored in a consistent manner as well. The data should be at least stored in the order it was given to the algorithm. For example, the word "hello" should be stored as the encrypted version of itself (as opposed to "olleh"). As for the individual bytes, the distances should be in the order of the keys.

## Decryption

4. A practical way of thinking of this 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. Since the direction of this vector is not known (and irrelevant), the distances can be thought of as radii of circles with the respective key point as the center.

5. The intersecting point(s) between each circle is found. This is done on a "per data point" basis where only the distances relating to the given data point are calculated.

6. The point where the most circles intersect is looked up in a table with all data points and their respective bytes and the point that matches is considered the decrypted byte of data. Depending on how the data is converted to points, this could be mathematically converted to the byte.

## Considerations

In order to decrypt the data, one MUST have the password or key-file used to encrypt the data. This is because the decryption process requires vectors. The encrypted data, on the other hand is simply the magnitude portion of a vector. You would still need the starting point and direction.

One may think that a way to brute force this is to take all distances and apply them to all data points possible. Then the intersection points of those circles are used to find the key points. While this may be possible, I believe (based on the extremely small number of tests I have performed) that this is not possible. If the number of keys is assumed to be three, applying the distances to each point would result in a unpredictable number of intersection points. In the tests that I have performed, the key point was on only one of these circles and not remotely close to the nearest intersection point.

## Examples

These examples will follow the same step numbers for both encryption and decryption.

Interactive source of the graphs I used in these examples

### Example 1:

1. Ok, lets say we want to encrypt the byte `0b01001000` (capital letter "H"). First we will convert it to a point. In this example, we convert H to `(2,-1)`. 2. At least three points are needed to act as key points. Here, we have generated the points `K1=(-4,3)`, `K2=(-6,-2)`, and `K3=(5,1)`. (Please ignore the fact that these keys are out of order in terms of top to bottom, I don't feel like remaking the images) 3. The process of encrypting the data is simply calculating the distance between each key point and data point. In our example, we calculate: `K1H=7.21`, `K2H=8.06`, and `K3H=3.61`. Therefore the "encrypted" letter H is: `7.21, 8.06, 3.61`. (Again ignoring the "top to bottom" rule) In our example, the data is stored as `7.21, 8.06, 3.61`.

4. First the key points are set (could be from password or "key file" that was generated and used to encrypt). The encrypted data is then applied to each key point in the form of a radius: `RK1=7.21`, `RK2=8.06`, `RK3=3.61` 5. The intersecting point(s) between each circle is found: `IK1K2=(2,-1)`, `I'K1K2=(-11.103,4.241)`, `IK2K3=(2,-1)`, `I'K2K3=(1.4,1.2)`, `IK3K1=(2,-1)`, `I'K3K1=(3.129,4.082)` 6. In our example, the point that occurs the most is `(2,1)`. Looking the point up in a table, the original byte is `0b01001000`. ### Example 2:

I am currently working on a second example that would en/decrypt the word "Hello". This is time consuming as I am generating the graphs with mathematical functions. I should have it done soon though.

### Considerations:

I am currently working on an example showing the considerations. This is time consuming as I am generating the graphs with mathematical functions. I should have it done soon though.

Note: This site is not finished. I will be constantly updating with more research. I am also trying to make it easier to understand.