OpenSeed Base Line Encryption - or - Nothing says I love you like "1kd893ld03kd83ld034"

Encryption is a dry subject. So dry in fact that If I were you I would stop reading now, go get myself a drink, and come back to read this summary and then pretend I read the rest. Unfortunately I'm not you, so not only do I have to write the rest of this document, I have to proof read as well. But enough about my hardships; here is a brief summary of the rest of the document so that you can get back to your day.

• Encryption is important whether or not you have something to "hide." You wouldn't want people to go through your mail, so why would you be okay with people going though your online communications.

• Encryption is not without issue. e.g. The stronger the encryption the longer it takes to process a message. Balance must be maintained between security and responsiveness

• Encryption is not perfect.

• Base Line Encryption (BLE) is meant to serve, as the name suggests, as a base line so that the data can be read by the intended recipients and work though any SDK connected to or using OpenSeed.

• The BLE in simplest terms works like this: User data is encrypted using the user's key becoming an UED (User Encrypted Data). The UED is passed up to the application layer and encrypted using the application key becoming an AED (Application Encryped Data). Then the AED is passed to the developer layer which is then encrypted using the developer key which becomes a DED. This object is then sent over the preferred communication protocol used by the application. Once on the server it reverses the process down to the user data where it does not decrypt the message to ensure the users privacy is maintained.

That's it, the whole of the document in 4 bullet points. If you want to know more you can continue reading, otherwise check out our SPS found here. The SBD we recieve from the proposal system will be used to fund community developers, and projects that us OpenSeed. So help us help others by voting today!

---

** More Below **

---

So you've decided to stay huh? Well I'll try to keep this high level enough to appeal to a greater audience so if you expecting math it may be disappointing.

Lets start by giving background and then move forward using the above points as guidelines. OpenSeed's BLE was developed in part because the tools I was using at the time (and still use) lacked a common encryption system between them and keeping with the core of the OpenSeed project, to break down silos and create a more unified back-end, it became apparent that a simple, but secure method would need to be created and distributed to ensure cross platform use cases.

Now I know what some of you are thinking. Who does this guy think he is! Coming up with his own encryption! He's not that smart! Only through standards are we truly safe! All valid, except maybe that last one, but how do you know how smart I am? Have we ever had a intimate conversation over the infinite? The finite? The meaning of a single drop of rain on a clear day? How perception is unique but everyone knows that purple has a taste but no one can describe it? If the answer is no, then you should follow my blog here on steem where its not always about programming and OpenSeed, but more importantly I didn't come up with my own encryption I based it on several methods after researching the subject, come on guys I'm not that smart.

So beyond the bit shifting, substitutions, and other things the BLE uses what I call "Encapsulated Security" where in any attacker would need to know at least two security keys (Or derive them through brute force) before being able to read the contents within. In the example above the user data is also encrypted but there are times where this isn't necessary or desired. Below are several albeit cryptic examples using the UED,AED,DED naming structure.

Public user data (Profiles,history,etc.): Upload UD-->AED-->DED :: Download DED-->AED--UD
Private user data: Upload UAD-->AED-->DED :: Download DED-->AED-->UAD
Private App data (app dependent): Upload AED-->DED :: Download DED-->AED
Chat messages (CED* [Chat Encrypted Data]): Upload CED-->AED-->DED :: Download DED-->AED-->CED

*The chat key would be sent as private user data.

Security Note

I have some concerns over how well this will work in web applications, but I am currently working on a solution for that implementation as well. It is worth noting that all the above information may change depending on the outcome of that solution. The above is meant to serve non-web based applications or webapps that use WASM instead of javascript as a means to serve the application.

You've made it to the end, congratulations! If you would like to know more you can always follow @openseed or myself @bflanagin. We also have a community where the team members share their work on the project. If you would like to support our work and more importantly the work of others check out and vote on our SPS found here

The image above was created by @midlet and used with implied consent (He made it for the @openseed project). If you like his work you should give him a follow and check out his post about the project and the image.

Until next time,