ZeroBin
81 views
Skip to first unread message
Sean McGregor
Jul 5, 2012, 7:51:49 PM7/5/12
to pri...@googlegroups.com
Hello All,
While at an open source conference, Jan-Christoph of unhosted.org
pointed me to ZeroBin (http://sebsauvage.net/paste/) as an
implementation of extension-free client side content encryption and
decryption. ZeroBin's implementation is worth note because it never
provides the content server with the decryption key. Basically,
ZeroBin implemented many requirements of Privly's first round of
encryption functionality.
I am concentrating on rolling out the current version for testing at
the moment, but I know there are a few people out there who are
experimenting with this functionality and this is a good proof of
concept to look at.
Drop into IRC if you want to talk about it: #privly on irc.freenode.net
-Sean
While at an open source conference, Jan-Christoph of unhosted.org
pointed me to ZeroBin (http://sebsauvage.net/paste/) as an
implementation of extension-free client side content encryption and
decryption. ZeroBin's implementation is worth note because it never
provides the content server with the decryption key. Basically,
ZeroBin implemented many requirements of Privly's first round of
encryption functionality.
I am concentrating on rolling out the current version for testing at
the moment, but I know there are a few people out there who are
experimenting with this functionality and this is a good proof of
concept to look at.
Drop into IRC if you want to talk about it: #privly on irc.freenode.net
-Sean
Sean McGregor
Jul 20, 2012, 5:12:55 PM7/20/12
to pri...@googlegroups.com
Hello All,
I made a more detailed ZeroBin implementation plan (see below). Please
comment, question, etc.
-Sean
__________
ZeroBin Implementation Plan
The ZeroBin implementation is a great proof of concept for the first
round of encryption in Privly. Since integrating existing projects
speeds development and saves resources, I drew up this plan to
generalize the ZeroBin application to Privly's needs. I have not
showed these changes to the ZeroBin dev yet because I wanted to float
the plan with you all first.
How ZeroBin Works
Basically, ZeroBin is an extension-less web application for generating
and posting encrypted content to a server, as well as fetching it and
decrypting content for viewing. ZeroBin uses the Stanford Web Crypto
Library (based in Javascript*) to encrypt content before sending it to
the remote server. The remote server saves the encrypted text and
sends back a URL for the saved content. When the client-side
application receives the URL, it appends the decryption key as an
anchor. Since the decryption key is never sent to the remote server
(anchors are not sent to remote servers in accordance with browser
standards), the remote server never has access to the key.
How We Have to Change ZeroBin
ZeroBin is nearly backend agnostic. It is currently integrated with a
PHP templating system, but the site only uses templating for adding
the cipher text to the page before it renders. We can easily remove
this PHP requirement by making the application request the cipher text
with a JSON request. This will make the web application completely
static (we could serve it out of GitHub if we wanted to).
How We Will Use ZeroBin: Content Viewing
ZeroBin will become the web application we are injecting into the host
pages. After injection, it will fetch the content with a JSONP
request, and place it onto the page. For this use, we will have to
strip it of most templating. Initially this application will be an
injected iframe whose source is on the remote server, but in time we
will move it into the extensions to run locally. Running the
application locally will ensure it can't be changed surreptitiously,
and increases performance.
How We Will Use ZeroBin: Content Creation
Users will create content using these steps:
1. The user selects a form element they want to post to Privly
2. A new protected form pops up (the ZeroBin application)
3. The user submits the ZeroBin form, which encrypts the content
before sending it our for storage
4. The user receives back a URL for the new content, which the
extension places into the host page with the decryption key appended
5. The user submits the host page's form
To speed implementation and iteration, we should implement this
functionality with an extension-level iframe whose source is the
remote content server. The specifics of this implementation is likely
platform dependent.
Will We Always Use ZeroBin?
As we add more functionality to creating posts, we will begin to
diverge significantly from ZeroBin's original use case, and we will
either need to maintain our own fork, or create our own similar
application tailored to our use case. However, ZeroBin is a good place
to start.
* (note) Since our key is shared openly on the link, using a
Javascript crypto library is not a problem. The more advanced sharing
models will also require the compiled encryption library.
--
Sean McGregor
Graduate Research Assistant in Machine Learning
Oregon State University, Department of Computer Science
Twitter: seanmcgregor
Facebook: facebook.com/SeanBMcGregor
I made a more detailed ZeroBin implementation plan (see below). Please
comment, question, etc.
-Sean
__________
ZeroBin Implementation Plan
The ZeroBin implementation is a great proof of concept for the first
round of encryption in Privly. Since integrating existing projects
speeds development and saves resources, I drew up this plan to
generalize the ZeroBin application to Privly's needs. I have not
showed these changes to the ZeroBin dev yet because I wanted to float
the plan with you all first.
How ZeroBin Works
Basically, ZeroBin is an extension-less web application for generating
and posting encrypted content to a server, as well as fetching it and
decrypting content for viewing. ZeroBin uses the Stanford Web Crypto
Library (based in Javascript*) to encrypt content before sending it to
the remote server. The remote server saves the encrypted text and
sends back a URL for the saved content. When the client-side
application receives the URL, it appends the decryption key as an
anchor. Since the decryption key is never sent to the remote server
(anchors are not sent to remote servers in accordance with browser
standards), the remote server never has access to the key.
How We Have to Change ZeroBin
ZeroBin is nearly backend agnostic. It is currently integrated with a
PHP templating system, but the site only uses templating for adding
the cipher text to the page before it renders. We can easily remove
this PHP requirement by making the application request the cipher text
with a JSON request. This will make the web application completely
static (we could serve it out of GitHub if we wanted to).
How We Will Use ZeroBin: Content Viewing
ZeroBin will become the web application we are injecting into the host
pages. After injection, it will fetch the content with a JSONP
request, and place it onto the page. For this use, we will have to
strip it of most templating. Initially this application will be an
injected iframe whose source is on the remote server, but in time we
will move it into the extensions to run locally. Running the
application locally will ensure it can't be changed surreptitiously,
and increases performance.
How We Will Use ZeroBin: Content Creation
Users will create content using these steps:
1. The user selects a form element they want to post to Privly
2. A new protected form pops up (the ZeroBin application)
3. The user submits the ZeroBin form, which encrypts the content
before sending it our for storage
4. The user receives back a URL for the new content, which the
extension places into the host page with the decryption key appended
5. The user submits the host page's form
To speed implementation and iteration, we should implement this
functionality with an extension-level iframe whose source is the
remote content server. The specifics of this implementation is likely
platform dependent.
Will We Always Use ZeroBin?
As we add more functionality to creating posts, we will begin to
diverge significantly from ZeroBin's original use case, and we will
either need to maintain our own fork, or create our own similar
application tailored to our use case. However, ZeroBin is a good place
to start.
* (note) Since our key is shared openly on the link, using a
Javascript crypto library is not a problem. The more advanced sharing
models will also require the compiled encryption library.
Sean McGregor
Graduate Research Assistant in Machine Learning
Oregon State University, Department of Computer Science
Twitter: seanmcgregor
Facebook: facebook.com/SeanBMcGregor
Rohan Durve
Jul 20, 2012, 11:05:50 PM7/20/12
to pri...@googlegroups.com
I have a small dilemma with this "plan". Although ensuring that we're giving individuals privacy, I believe it would not be possible for us to distinguish between legal and illegal encrypted content. How would the server hosting company handle this?
Secondly, if a decryption key is used to decode data at the client-side would it not be possible for someone to "Steal" the key, or what if the key gets compromised. What if the document has to be shared, will the key have to be sent out to all those that need access? (rhetorical one)
I'm assuming some of that is in the future scope of the project, but a blind suggestion would be that,why not do the following:
Advantages:1. Give all users documents a private and public hash key (not the user's password, it would be a pseudo-randomly generated string's hash for eg).2. Give the private decryption key back to him and store an encrypted version on the server. (encrypted via say the user's own password + unique salt).3. This hash can then be decrypted and shared with other users and can also be similar stored by them on the server, attached to their accounts.4. If users put posts into say categories in the future, all posts within can have the same hash and thus the server can automatically decypt them for the users.
- It would be possible to sync-keys. Eg. If user A sent users B,C and D a key for a collection of encrypted text files and believes that the key may be compromised, he can not only easily re-encrypt the data without having to change URLs but after his consent, the new key can directly be sync'ed with all those he had shared the key with earlier, etc.
- It would be possible for manual decryption of user data for legal issues or for violations of your TOS.
- This system would go perfectly with other security mechanisms such as Two-Step verification or One time passwords or restrictions on which IPs can access a user's account. Eg. Since the encrypted decryption key is stored on the server, the user can put any security mechanism on his account login as he wishes. People could use SMS texts to their phone each time the account has to be accessed with a code or restrict it only to their own IP. Hell people could even bind it to a static IP they use to tunnel SSH proxies from! Complete privacy for their data.
Regards,
Rohan Durve (Ðecode141),
deco...@JediCorp.com
--
You received this message because you are subscribed to the Privly development mailing list. To post to this list, send email to pri...@googlegroups.com. To unsubscribe from this group, send email to privly+un...@googlegroups.com. For more options, visit this group at https://groups.google.com/d/forum/privly?hl=en
Privly testers should also sign up for this list: https://groups.google.com/forum/#!forum/privly-test
Sean McGregor
Jul 21, 2012, 2:25:48 AM7/21/12
to pri...@googlegroups.com
Rohan,
Welcome!
I responded inline below on several points.
Do you have a "nightmare scenario" for the legality of a Privly host,
which is registered under the DMCA? This might be a question better
directed to the legal contributors. I am operating under the
assumption that we need to make a good faith effort to manage the
community within the capabilities of the technology we setup. Beyond
that, we only need to respond to subpoena and take-down notices.
A major goal of the development effort is to make it functionally
impossible for the content host to decrypt the content without
information stored elsewhere, whether that be the link pointing to the
data, or the private key stored on the extension. Otherwise we will be
consolidating private data from across the web...this is less than
desirable security wise.
We are starting with the link-based encryption because it affords
several benefits at this stage of development, not the least of which
are the ability to use existing sharing rule (share the link with
people you trust), and the ability to read the content without an
extension installed. It is also considerably easier to implement and
validate.
The plan is to propose and explore more advanced encryption strategies
once we have the base infrastructure in place (see: Pygmy
http://www.privly.org/content/development-roadmap). The larger our
encryption tool set is at that time the better, so you can start a
document for Pygmy encryption proposals if you like. I have been
meaning to write up one of the proposals from this video:
http://vimeo.com/39095681
-Sean
On Fri, Jul 20, 2012 at 8:05 PM, Rohan Durve <deco...@gmail.com> wrote:
> I have a small dilemma with this "plan". Although ensuring that we're giving
> individuals privacy, I believe it would not be possible for us to
> distinguish between legal and illegal encrypted content. How would the
> server hosting company handle this?
>
The hosts will have to register with the DMCA and comply with all
valid legal requests. Hosts don't have to police the content users
post so long as they aren't "turning a blind eye" to legal issues in
their community. I am more worried about these concerns when it comes
to audio and video content, which is targeted for "Spotted Owl."
> Secondly, if a decryption key is used to decode data at the client-side
> would it not be possible for someone to "Steal" the key, or what if the key
> gets compromised.
By separating the key and the ciphertext, no one can compromise the
content without compromising two different storage locations.
Welcome!
I responded inline below on several points.
Do you have a "nightmare scenario" for the legality of a Privly host,
which is registered under the DMCA? This might be a question better
directed to the legal contributors. I am operating under the
assumption that we need to make a good faith effort to manage the
community within the capabilities of the technology we setup. Beyond
that, we only need to respond to subpoena and take-down notices.
A major goal of the development effort is to make it functionally
impossible for the content host to decrypt the content without
information stored elsewhere, whether that be the link pointing to the
data, or the private key stored on the extension. Otherwise we will be
consolidating private data from across the web...this is less than
desirable security wise.
We are starting with the link-based encryption because it affords
several benefits at this stage of development, not the least of which
are the ability to use existing sharing rule (share the link with
people you trust), and the ability to read the content without an
extension installed. It is also considerably easier to implement and
validate.
The plan is to propose and explore more advanced encryption strategies
once we have the base infrastructure in place (see: Pygmy
http://www.privly.org/content/development-roadmap). The larger our
encryption tool set is at that time the better, so you can start a
document for Pygmy encryption proposals if you like. I have been
meaning to write up one of the proposals from this video:
http://vimeo.com/39095681
-Sean
On Fri, Jul 20, 2012 at 8:05 PM, Rohan Durve <deco...@gmail.com> wrote:
> I have a small dilemma with this "plan". Although ensuring that we're giving
> individuals privacy, I believe it would not be possible for us to
> distinguish between legal and illegal encrypted content. How would the
> server hosting company handle this?
>
valid legal requests. Hosts don't have to police the content users
post so long as they aren't "turning a blind eye" to legal issues in
their community. I am more worried about these concerns when it comes
to audio and video content, which is targeted for "Spotted Owl."
> Secondly, if a decryption key is used to decode data at the client-side
> would it not be possible for someone to "Steal" the key, or what if the key
> gets compromised.
content without compromising two different storage locations.
Reply all
Reply to author
Forward
0 new messages