Gophemeral
-
@Obsolesce said in Gophemeral:
Awesome project!
Question, is the secret encrypted withing the DB which uses the pw to decrypt? Additionally, is the DB encrypted at rest?
Thanks!
I'm not sure I understand the first question. The password isn't stored in the database. It's generated randomly and used to encrypt the message and then given to you. That encrypted string is then stored in the database. If you lose the password, your message is not recoverable.
As for the database, Fauna does encryption at rest. They're a serverless database offering so there isn't much control over that. The boltdb database would be if you set up disk encryption.
-
@stacksofplates said in Gophemeral:
I'm not sure I understand the first question. The password isn't stored in the database. It's generated randomly and used to encrypt the message and then given to you. That encrypted string is then stored in the database. If you lose the password, your message is not recoverable.
Yes, that answers my first question exactly... I meant it as in the secret is encrypted within the database, such that if the DB is compromised, the secrets are fully encrypted using the password that is given to you (aka the decryption key), with no record or log containing the key.
It also plays in to Q2, which is answered
I also see that the data from the web form is sent to the server via https (https://api.gophemeral.com/api/message), which was going to be my next question but seen for myself, and obviously from the server back to me.
-
If I go to this site and your mascot isn't an adorable gopher I'm going to be serious disappointed.
-
@scottalanmiller said in Gophemeral:
If I go to this site and your mascot isn't an adorable gopher I'm going to be serious disappointed.
It's on the GitLab page lol.
-
@stacksofplates said in Gophemeral:
@scottalanmiller said in Gophemeral:
If I go to this site and your mascot isn't an adorable gopher I'm going to be serious disappointed.
It's on the GitLab page lol.
Nice
-
@scottalanmiller said in Gophemeral:
Nice
ID: 290080036515480068
Password: sbMo9N7ojt-wdChJ8lVqAsgs18PUjz_n -
@stacksofplates said in Gophemeral:
I wrote this utility. It's for sharing secrets or any sensitive data. Instead of just emailing or texting the data, you can create a message with this service and it will encrypt the data and store it. It will only allow the message to be viewed whatever number of times you specify. It gives you back a message ID and password that you pass on to your recipient and they can retrieve the message.
You can use the hosted version, which is limited to 50 characters, and 5 days of retention. Or you can run the server on your own.
By default the server will use Fauna as a backend, but you can specify to use a local BoltDB database. The utility can be downloaded from GitLab here and the same cli tool that runs the server also interacts with the server.
It sounds cool but I can't see how it will be more secure than just mailing the data?
I mean you are mailing the message ID and password needed to decrypt.
That's what I believe is called the key exchange problem and the reason for asymmetric encryption and public/private keys.
-
@Pete-S said in Gophemeral:
I mean you are mailing the message ID and password needed to decrypt.
You could mail one, and speak the other.
Many institutions send usernames and passwords through separate mediums.
-
@JasGot said in Gophemeral:
@Pete-S said in Gophemeral:
I mean you are mailing the message ID and password needed to decrypt.
You could mail one, and speak the other.
Many institutions send usernames and passwords through separate mediums.
OK, but a 150 character message is really pretty short... so you could do the same there, send half, speak half.
-
@Pete-S said in Gophemeral:
@stacksofplates said in Gophemeral:
I wrote this utility. It's for sharing secrets or any sensitive data. Instead of just emailing or texting the data, you can create a message with this service and it will encrypt the data and store it. It will only allow the message to be viewed whatever number of times you specify. It gives you back a message ID and password that you pass on to your recipient and they can retrieve the message.
You can use the hosted version, which is limited to 50 characters, and 5 days of retention. Or you can run the server on your own.
By default the server will use Fauna as a backend, but you can specify to use a local BoltDB database. The utility can be downloaded from GitLab here and the same cli tool that runs the server also interacts with the server.
It sounds cool but I can't see how it will be more secure than just mailing the data?
I mean you are mailing the message ID and password needed to decrypt.
That's what I believe is called the key exchange problem and the reason for asymmetric encryption and public/private keys.
And guess what happens if anyone other than you gets in your mail? Versus, what happens if anyone other than you gets ahold of the secret ID and password after you seen it. Huge huge difference, way more secure. These things are used all the time. Yes, email could be as secure, or even more... But in practice, it never is across the board.
-
@Pete-S said in Gophemeral:
@stacksofplates said in Gophemeral:
I wrote this utility. It's for sharing secrets or any sensitive data. Instead of just emailing or texting the data, you can create a message with this service and it will encrypt the data and store it. It will only allow the message to be viewed whatever number of times you specify. It gives you back a message ID and password that you pass on to your recipient and they can retrieve the message.
You can use the hosted version, which is limited to 50 characters, and 5 days of retention. Or you can run the server on your own.
By default the server will use Fauna as a backend, but you can specify to use a local BoltDB database. The utility can be downloaded from GitLab here and the same cli tool that runs the server also interacts with the server.
It sounds cool but I can't see how it will be more secure than just mailing the data?
I mean you are mailing the message ID and password needed to decrypt.
That's what I believe is called the key exchange problem and the reason for asymmetric encryption and public/private keys.
because there's still and abstraction and a view limit. If I send you a password over email and someone nabs it, you have no idea and they don't have to be watching real time. With this, if I send you a message ID and pass, you'd have to be watching real time and get the data before the recipient. And at that point, they'd know something is wrong because the message has either ran out of view, or is not the correct number of views.
-
@JasGot said in Gophemeral:
@Pete-S said in Gophemeral:
I mean you are mailing the message ID and password needed to decrypt.
You could mail one, and speak the other.
Many institutions send usernames and passwords through separate mediums.
This is anther way. If you really want to be secure, text the ID and email the password. Or call and give one of them.
