Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Encryption Engine for end-to-end encryption with symmetric encryption #48

Open
davidsvarrer opened this issue Mar 18, 2016 · 0 comments

Comments

@davidsvarrer
Copy link

Dear Ladar,

Having followed the Lavabit case and many other cases, I would like to have a private conversation with you, outside of this forum.

My prospect contribution:
I have developed an encryption engine, which works in that upon use, it creates an encryption algorithm from a password, and then that algorithm is using another password to encrypt with. The generator algorithm is pretty swift, and creates algorithms so strong that the outcome is FIPS-140-II conformant.

Ever worked with added redundance, deliberate distortion and Viterbi? Now imagine that you encrypt the Viterbi part, which is used to recover the lost data? You can say that if you distort a signal to the rim of recognition and reconstruction, and then you distort the way back by encryption, then you are establishing the worst possible scenario for brute force attack. Add to it, that the algorithm is arbitrarily deep. When you see it, you will after some analysis agree that it in seconds can establish such rough and tough encryption so it is virtually unbreakable.

Enough about the techie stuff / that we can always discuss.

Similarly the generated algorithm (made by the generator) is pretty swift, yet it can likely be optimized quite a lot, but the principle remains the same / the algorithm is one-way unique to the password like a hash is one-way unique.

The point is this: When the algorithm is determined by the password, and the cipher-code is depending on the algorithm, then it can be a bit of a task to do a brute force attack. Due to the way of encoding, we add redundancy to the plain-code, and the amount of code added, is also determined by the password.

It means, that even at gun-point, it is impossible to break the code, because the author cannot tell anything about which algorithm has been used, without having the password.

Now, I have worked with such encoding technologies through out my 34 years of software career.

**I want to discuss with you, how we can implement such hard encryption and end-to-end security in such a way that it cannot be exploited in any unethical manner.

Therefore: How can we protect law-abiding, or ethically "correctly" working persons against being listened to by big-brother? And how can we protect this code from being used by criminals, terrorists, and unethical use?
**

Finally I would also like to address the issue of security in the end of the computers, that is - the peers. These will be the vulnerable point: I have thought out how we can protect these against for instance a court order to "replace" the code at the client-side which would be similar to the Lavapit order. The way to deal with this is to create the software such that the encryption algorithms and their generation, are dealt with at the end-user level, such that our Dark Matter code will be like an agent-host, and the choice of algorithm will ultimately be the work of the end-user.

We will then create a system where developers all over the world can contribute with their own encryption algorithm, get it numbered, and distributed. This will ensure that it will be virtually impossible to follow such an court order, as the software which is literally key (no pun intended) will not be produced by our Dark Matter team, but rather be produced around the world.

Therefore, a users choice of encryption algorithms will be independent of our Dark Matter, and we can therefore not do a thing ..

We shall then also let the encryption generator remain in the public domain just as you have started it.

Now a court order could render the entire project illegal, however, I guess that would just make the entire security community go underground, and start using steganography etc. etc., which would be detrimental.

But back to the topic. What can we do to ensure that our pretty neutral encryption technology will not fall into the hands of the enemy - being either terrorists, or snoopy governments?

Please email me on ds@dash.yt

Sincerely
David Svarrer

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

1 participant