0bin: A Client-Side Encrypted Pastebin
1–10 of 12 posts
Re: 0bin: A Client-Side Encrypted Pastebin
#2"Error
Paste could not be saved. Please try again later."
Damn.
Re: 0bin: A Client-Side Encrypted Pastebin
#3The problem with these is that even if the code is set to be cached forever, there's no easy way for the user to verify that this is the case. How do you defend against an attacker (say, the FBI) taking control of the servers and causing them to serve javascript which sends the messages to themselves unencrypted?
Re: 0bin: A Client-Side Encrypted Pastebin
#4nice idea though.
Re: 0bin: A Client-Side Encrypted Pastebin
#5The problem with these is that even if the code is set to be cached forever, there's no easy way for the user to verify that this is the case. How do you defend against an attacker (say, the FBI) taking control of the servers and causing them to serve javascript which sends the messages to themselves unencrypted?
At the moment an attacker doesn't even need to take control of the servers since all the code is sent without SSL so a MITM attack would be enough.
Edit: though of course if the javascript is never requested again it limits the window of opportunity to man-in-the-middle.
Re: 0bin: A Client-Side Encrypted Pastebin
#6The problem with these is that even if the code is set to be cached forever, there's no easy way for the user to verify that this is the case. How do you defend against an attacker (say, the FBI) taking control of the servers and causing them to serve javascript which sends the messages to themselves unencrypted?
At the moment an attacker doesn't even need to take control of the servers since all the code is sent without SSL so a MITM attack would be enough. Edit: though of course if the javascript is never requested again it limits the window of opportunity to man-in-the-middle.
Though of course if the HTML is requested again you could just add another script tag.
Re: 0bin: A Client-Side Encrypted Pastebin
#7The problem with these is that even if the code is set to be cached forever, there's no easy way for the user to verify that this is the case. How do you defend against an attacker (say, the FBI) taking control of the servers and causing them to serve javascript which sends the messages to themselves unencrypted?
At the moment an attacker doesn't even need to take control of the servers since all the code is sent without SSL so a MITM attack would be enough. Edit: though of course if the javascript is never requested again it limits the window of opportunity to man-in-the-middle.
This was on HN previously, but not at this domain, they said the key generation and link formation was performed client-side, at no point does the key get sent to the server.
You send the encrypted message to the server and the javascript serves the url that combines the client side key and the servers uid for the paste.
Re: 0bin: A Client-Side Encrypted Pastebin
#8Earlier quoted context omitted.
At the moment an attacker doesn't even need to take control of the servers since all the code is sent without SSL so a MITM attack would be enough. Edit: though of course if the javascript is never requested again it limits the window of opportunity to man-in-the-middle.
This was on HN previously, but not at this domain, they said the key generation and link formation was performed client-side, at no point does the key get sent to the server. You send the encrypted message to the server and the javascript serves the url that combines the client side key and the servers uid for the paste. See: http://sebsauvage.net/paste/
This should be a top-level comment.
Re: 0bin: A Client-Side Encrypted Pastebin
#9"Error Paste could not be saved. Please try again later." Damn.
Just fixed that. First day out, first bug out :-)
Re: 0bin: A Client-Side Encrypted Pastebin
#10The problem with these is that even if the code is set to be cached forever, there's no easy way for the user to verify that this is the case. How do you defend against an attacker (say, the FBI) taking control of the servers and causing them to serve javascript which sends the messages to themselves unencrypted?
You don't. That's not the purpose.
0bin is not made to prevent the user from being buster. 0bin is made so that it's difficult to sue the host for hosting hot content since he can claim he can't moderate it.