Re: [cryptography] Introducing SC4 -- feedback appreciated

[Ben Laurie]

On 18 April 2015 at 00:51, Tony Arcieri  wrote:
> On Fri, Apr 17, 2015 at 11:56 AM, Ron Garret  wrote:
>>
>> The fact that to use PGP you have to install an application.  (This is
>> true for Peerio as well.)  That turns out to be too much friction for most
>> people.  Whenever you have to install an application you have to decide
>> whether or not you trust the application, and most people have no basis for
>> making that assessment.
>
>
> Why should anyone trust your web page? Do you expect people to audit the
> source code every time they use it? If they don't, perhaps you made a change
> which exfiltrates the plaintext to your personal server. Perhaps you
> targeted a single person, and everyone else sees the "real version"
>
> This is why web pages aren't trustworthy for cryptographic purposes.
>
> I wrote a blog post on this topic:
>
> http://tonyarcieri.com/whats-wrong-with-webcrypto

This is why we need Binary Transparency (for web pages, in this case).

The same problem exists for all executables, of course.
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] Introducing SC4 -- feedback appreciated

[Ron Garret]

On Apr 17, 2015, at 6:59 PM, Tony Arcieri  wrote:

> On Fri, Apr 17, 2015 at 4:25 PM, Ron Garret  wrote:
> Why should anyone trust anyone’s web page?  When was the last time you 
> obtained a software application that was *not* delivered via the web?
> 
> There's a big difference between a web page with JavaScript loaded in a 
> browser and a static artifact delivered over the HTTP protocol. Static 
> artifacts downloaded over HTTP by tools like apt-get or yum for example can 
> carry cryptographic signatures that are checked before the artifact is used. 
> In fact this same thing applies to browser extensions like Minilock or 
> Peerio. This means there's a transparent history of these artifacts, and you 
> can verify you got the same version as everyone else.
> 
> The same thing applies to every Smartphone app.
> 
> Short of a line-by-line source code audit each time you load a web page, this 
> isn't possible with the web today.

It’s not quite that bad.  You only have to audit the code once, and then verify 
that what you’re running is the same as what you audited.  It’s true that there 
is a real problem here, but it’s not quite as bad as you describe.  (And, it is 
worth noting, it is a political problem, not a technical one.  There is no 
technical obstacle to defining and implementing a signature verification 
protocol for web pages.  In fact, you could even implement a secure script 
loader using SC4.  Hm, there’s an idea :-)

> No.  SC4 was designed to support a wide variety of risk postures.  If you 
> don’t trust my server, you can run SC4 from a standalone file on your own 
> file system
> 
> How is this materially any different than "installing an app”?

It isn’t any different.  That’s the whole point.  If you want the security of a 
local app you can have that.  If you want the convenience of a web app at the 
cost of having to trust the server, you can have that too.

rg

___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] Introducing SC4 -- feedback appreciated

[Tony Arcieri]

On Fri, Apr 17, 2015 at 4:25 PM, Ron Garret  wrote:

> Why should anyone trust anyone’s web page?  When was the last time you
> obtained a software application that was *not* delivered via the web?
>

There's a big difference between a web page with JavaScript loaded in a
browser and a static artifact delivered over the HTTP protocol. Static
artifacts downloaded over HTTP by tools like apt-get or yum for example can
carry cryptographic signatures that are checked before the artifact is
used. In fact this same thing applies to browser extensions like Minilock
or Peerio. This means there's a transparent history of these artifacts, and
you can verify you got the same version as everyone else.

The same thing applies to every Smartphone app.

Short of a line-by-line source code audit each time you load a web page,
this isn't possible with the web today.

No.  SC4 was designed to support a wide variety of risk postures.  If you
> don’t trust my server, you can run SC4 from a standalone file on your own
> file system
>

How is this materially any different than "installing an app"? Especially a
Chrome App like Peerio. That's effectively what Chrome lets you do, except
such apps carry cryptographic signatures from their publishers, so you have
end-to-end security.

-- 
Tony Arcieri
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] Introducing SC4 -- feedback appreciated

[Ron Garret]

On Apr 17, 2015, at 3:51 PM, Tony Arcieri  wrote:

> On Fri, Apr 17, 2015 at 11:56 AM, Ron Garret  wrote:
> The fact that to use PGP you have to install an application.  (This is true 
> for Peerio as well.)  That turns out to be too much friction for most people. 
>  Whenever you have to install an application you have to decide whether or 
> not you trust the application, and most people have no basis for making that 
> assessment. 
> 
> Why should anyone trust your web page?

Why should anyone trust anyone’s web page?  When was the last time you obtained 
a software application that was *not* delivered via the web?

I’m not saying this isn’t a problem, just that it is not a problem unique to 
SC4.  *Every* application has this problem.  Do you use PGP?  Did you build it 
from source?  Are you sure you can trust your compiler?  Did you verify the 
signatures?  Are you really confident in the root of your chain of trust?

> Do you expect people to audit the source code every time they use it?

No.  SC4 was designed to support a wide variety of risk postures.  If you don’t 
trust my server, you can run SC4 from a standalone file on your own file 
system.  The code to generate that standalone file is part of the current SC4 
distribution.  If you don’t trust that, then it’s pretty easy to write an SC4 
implementation in C.  If you don’t trust that then I confess that I am at a 
loss.

> If they don't, perhaps you made a change which exfiltrates the plaintext to 
> your personal server. Perhaps you targeted a single person, and everyone else 
> sees the "real version”

Yes, all these things are possible, but they are also possible for PGP.

> This is why web pages aren't trustworthy for cryptographic purposes.

Then what do you propose?  If I want to run secure crypto software, how should 
I do it under the attack model that you’ve implied by your questions?

> I wrote a blog post on this topic:
> 
> http://tonyarcieri.com/whats-wrong-with-webcrypto

Yes, and I am very sympathetic to this argument.  But the problem is that it 
applies to anything you download from the web, not just webapps.

My claim is not that SC4 is secure.  My claim is that SC4 is at least 
potentially as secure as anything else in today’s world.

rg

___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] Introducing SC4 -- feedback appreciated

[Tony Arcieri]

On Fri, Apr 17, 2015 at 11:56 AM, Ron Garret  wrote:

> The fact that to use PGP you have to install an application.  (This is
> true for Peerio as well.)  That turns out to be too much friction for most
> people.  Whenever you have to install an application you have to decide
> whether or not you trust the application, and most people have no basis for
> making that assessment.


Why should anyone trust your web page? Do you expect people to audit the
source code every time they use it? If they don't, perhaps you made a
change which exfiltrates the plaintext to your personal server. Perhaps you
targeted a single person, and everyone else sees the "real version"

This is why web pages aren't trustworthy for cryptographic purposes.

I wrote a blog post on this topic:

http://tonyarcieri.com/whats-wrong-with-webcrypto

-- 
Tony Arcieri
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] Introducing SC4 -- feedback appreciated

[Ron Garret]

On Apr 17, 2015, at 12:32 PM, z...@manian.org wrote:

> I don't think this really solves any actual crypto problems.

Just to be clear, I’m not claiming to solve any actual crypto problems.  I’m 
claiming (or maybe “aiming” is a better word) to solve a UI/UX problem.

> I also suspect it's pretty hard to solve any of the big problems while 
> retaining this level of simplicity. But I'm sure you'll learn stuff along the 
> way.

Yep, that’s also one of my goals.  :-)

> You should take a look at reop as well which is an even older nacl PGP clone.
> 
> https://github.com/tedu/reop

Thanks.  Just FYI, this was my first attempt at a PGP clone:

https://github.com/rongarret/clmm

That code implemented passphrase protection on the keys.  But someone here 
(Robert Ransom) pointed out to me that if you really care about file security 
then you should be using a secure file system instead of trying to implement a 
“half-assed” password protection scheme.  That led me to thinking deeply about 
attack models and the conclusion that a browser based solution could be 
reasonably secure, where “reasonably secure” means “as secure as the current 
state of the art in the hands of a non-technical user”.

> > Minilock uses a compressed curve25519 point without any metadata as public 
> > key. This is more compact than your format. It'sBase58 encoded it is 
> > tweetable which is very nice.
> 
> SC4 and Minilock use the same underlying crypto.  The reason SC4 keys look 
> longer is that it gives you separate keys for signing and encryption.  But 
> SC4 keys could be easily made tweetable if people cared about that.
> 
> NACL encryption is authenticated. The shared secret is used in the MAC as 
> well encryption steps. If all you want is an encryption app, you don't need a 
> ed25519 signing key as well.

Yes, I know.  Signing is a separate feature.  (SC4 lets you sign without 
encrypting and vice versa.)  The main reason for separate keys is that I didn’t 
know if it was possible to securely convert back and forth between them (but I 
know now!  Thanks for the pointer.)

Another reason to keep the keys separate is so that you can revoke them 
independently.  But I’m not sure that’s a good enough reason.

rg

___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] Introducing SC4 -- feedback appreciated

[z...@manian.org]

I don't think this really solves any actual crypto problems. I also suspect
it's pretty hard to solve any of the big problems while retaining this
level of simplicity. But I'm sure you'll learn stuff along the way. More
inline.

On Fri, Apr 17, 2015 at 12:04 PM, Ron Garret  wrote:

>
> On Apr 17, 2015, at 11:26 AM, z...@manian.org wrote:
>
> > At some level, this is in the same conceptual space as Peerio / Minilock.
>
> That’s right.
>

You should take a look at reop as well which is an even older nacl PGP
clone.

https://github.com/tedu/reop


>
> > The primary notable difference I see is you have used a binary format
> for keys and messages.
>
> That’s not the main difference that I claim.  The message format is almost
> irrelevant (except insofar as SC4 messages are fairly compact and easy to
> parse).  The main advantage I claim for SC4 is the combination of
> reasonable security and low friction.
>
> > Minilock uses a compressed curve25519 point without any metadata as
> public key. This is more compact than your format. It'sBase58 encoded it is
> tweetable which is very nice.
>
> SC4 and Minilock use the same underlying crypto.  The reason SC4 keys look
> longer is that it gives you separate keys for signing and encryption.  But
> SC4 keys could be easily made tweetable if people cared about that.
>

NACL encryption is authenticated. The shared secret is used in the MAC as
well encryption steps. If all you want is an encryption app, you don't need
a ed25519 signing key as well.

If you want signing as well as encryption in your set of capabilities, you
could use the system for converting curve25519 keys to ed25519 keys that
TextSecure uses but you need a full curve implementation rather than just
the NACL apis.



>
> > Minilock uses JSON for the message format rather than a binary format. I
> also really like using a protocol buffers for message formats which is what
> TextSecure does.
>
> These are things that only technical people tend to care about.  I’m
> trying to optimize for low friction to encourage non-technical people to
> use it.
>
>
This is mostly minutiae but because JSON doesn't specify ordering of
fields, it's somewhat annoying to implement signed objects is JSON though
there is http://jwt.io/. Protocol buffers free users from writing their own
binary parsers. I think it lowers the barrier to implementation for others.



> > It looks like your key portability strategy is for users to manage their
> keys directly as file they provide to instances. Peerio has switched to
> providing users with a wordlist from which the private key can be derived
> through a KDF for portability.
>
> My intent is to build a key server that will make the key sharing process
> seamless.  But I wanted to start with a completely standalone version to
> make sure I didn’t have any obvious problems with the crypto first.
>
> rg
>
>
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] Introducing SC4 -- feedback appreciated

[Ron Garret]

On Apr 17, 2015, at 12:04 PM, stef  wrote:

> On Fri, Apr 17, 2015 at 11:56:48AM -0700, Ron Garret wrote:
>> On Apr 17, 2015, at 11:27 AM, Dominik Schuermann
>>  wrote:
>>> what problem of traditional PGP implementations did you solve?
>> 
>> The fact that to use PGP you have to install an application.  (This is true
>> for Peerio as well.)  That turns out to be too much friction for most
>> people.  
> 
> that is actually true and sad, instead of new webapps, maybe the focus should
> be on multi-platform installers.
> 
>> Whenever you have to install an application you have to decide
>> whether or not you trust the application,
> 
> i don't see how this decision is not made in the sc4 case

It’s not that you don’t have to make the decision, it’s that the decision is 
easier (I claim) to make for SC4 than any alternative.  Because SC4 is a web 
app it is necessarily delivered as source code.  And the code is really, really 
small (have you looked at it?) so there just aren’t many places for shenanigans 
to hide.

With regards to your earlier comment about putting keys in browsers, I don’t 
disagree with you that browsers are not the ideal venue for security 
applications.  However, I claim they’re not as bad as the conventional wisdom 
would have you believe.  LocalStorage for HTTPS URLs is reasonably secure, and 
SC4’s strategy of embedding keys in local copies of itself is also not 
horrible.  I claim that any attack that can compromise SC4’s keys will also 
compromise a whole slew of other things that people generally rely on to be 
secure.  I’m not making any claims about whether people are wise to rely on 
these things, only that SC4 is no worse that what people are already using for 
things like on-line banking.

rg

___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] Introducing SC4 -- feedback appreciated

[stef]

On Fri, Apr 17, 2015 at 11:56:48AM -0700, Ron Garret wrote:
> On Apr 17, 2015, at 11:27 AM, Dominik Schuermann
>  wrote:
> > what problem of traditional PGP implementations did you solve?
> 
> The fact that to use PGP you have to install an application.  (This is true
> for Peerio as well.)  That turns out to be too much friction for most
> people.  

that is actually true and sad, instead of new webapps, maybe the focus should
be on multi-platform installers.

> Whenever you have to install an application you have to decide
> whether or not you trust the application,

i don't see how this decision is not made in the sc4 case

-- 
otr fp: https://www.ctrlc.hu/~stef/otr.txt
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] Introducing SC4 -- feedback appreciated

[Ron Garret]

On Apr 17, 2015, at 11:26 AM, z...@manian.org wrote:

> At some level, this is in the same conceptual space as Peerio / Minilock.

That’s right.

> The primary notable difference I see is you have used a binary format for 
> keys and messages.

That’s not the main difference that I claim.  The message format is almost 
irrelevant (except insofar as SC4 messages are fairly compact and easy to 
parse).  The main advantage I claim for SC4 is the combination of reasonable 
security and low friction.

> Minilock uses a compressed curve25519 point without any metadata as public 
> key. This is more compact than your format. It'sBase58 encoded it is 
> tweetable which is very nice.

SC4 and Minilock use the same underlying crypto.  The reason SC4 keys look 
longer is that it gives you separate keys for signing and encryption.  But SC4 
keys could be easily made tweetable if people cared about that.

> Minilock uses JSON for the message format rather than a binary format. I also 
> really like using a protocol buffers for message formats which is what 
> TextSecure does.

These are things that only technical people tend to care about.  I’m trying to 
optimize for low friction to encourage non-technical people to use it.

> It looks like your key portability strategy is for users to manage their keys 
> directly as file they provide to instances. Peerio has switched to providing 
> users with a wordlist from which the private key can be derived through a KDF 
> for portability.

My intent is to build a key server that will make the key sharing process 
seamless.  But I wanted to start with a completely standalone version to make 
sure I didn’t have any obvious problems with the crypto first.

rg

___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] Introducing SC4 -- feedback appreciated

[Ron Garret]

On Apr 17, 2015, at 11:27 AM, Dominik Schuermann  
wrote:

> what problem of traditional PGP implementations did you solve?

The fact that to use PGP you have to install an application.  (This is true for 
Peerio as well.)  That turns out to be too much friction for most people.  
Whenever you have to install an application you have to decide whether or not 
you trust the application, and most people have no basis for making that 
assessment.  That leads to potential disasters like NQ Mobile Vault [1].  There 
are a couple of other advantages too [2] but that’s the main one.

> * Looks like key exchange problem is still present (sent by mail)

At the moment that’s true.  I’m planning to build a key server, but I wanted to 
make sure I had the crypto working first.

> * Any key authentication? I don't see any verification or
> certification model.

Not yet.  The key server will do automatic email verification, but key 
authentication in general is a very hard problem that I’m not really 
addressing.  The goal here is to make something with very low friction to 
encourage non-technical people to use it and get them accustomed to having and 
using a key.

rg

---
[1] 
http://www.slate.com/articles/technology/bitwise/2015/04/nq_mobile_vault_the_popular_encryption_app_has_laughably_crackable_encryption.html

[2] A secondary advantage (I claim) for SC4 over PGP is that PGP uses RSA keys 
by default, which are big and cumbersome, and difficult to generate securely 
because you need a trustworthy prime number generator.  ECC keys are much 
easier to generate from any source of entropy because you don’t need to 
generate primes.



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] Introducing SC4 -- feedback appreciated

[Dominik Schuermann]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi,

what problem of traditional PGP implementations did you solve?

* Looks like key exchange problem is still present (sent by mail)
* Any key authentication? I don't see any verification or
certification model.

Regards
Dominik

On 04/17/2015 08:21 PM, stef wrote:
> ohio,
> 
> On Fri, Apr 17, 2015 at 10:56:01AM -0700, Ron Garret wrote:
>> 1.  It is a standalone web application.
> 
> putting keys in the browser is like putting keys in front of a dmz.
> browsers are not designed for this, they are designed for
> delivering impressions and services to you. the security features
> you find in any browser are there to secure the revenue-stream of
> some companies, not for the protection of the interests of its
> users. (same goes for phones), the tool might be good (haven't
> checked), but the foundation it's built on is sand. you want to 
> isolate your keys, current end-host security does not provide much
> protection against some malware in case recovery of your keys
> becomes a priority. you also want to make sure the code running is
> authentic, with js delivered over the net this is quite hard to do
> verifiably (again, not your protection, industry revenues are the
> thing to protect).
> 
> cheers,s ___ 
> cryptography mailing list cryptography@randombit.net 
> http://lists.randombit.net/mailman/listinfo/cryptography
> 
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)

iQEcBAEBAgAGBQJVMVCNAAoJEHGMBwEAASKCdd0IAIP0zgu/GcT8V3RqjPGDqJ+K
aoX2dneLwuPtYmCvoRRkv3iiCoc/XdefktJsF7bMKo4k1cnpq3+Y1mUa4kHG6PjK
sBL5o0Jj9xKH3hTol18ownZB1oCZuKIsJB83+RdndjZdvdPqTl3mHldUkRWtyS6n
sC7RM9THBHNRvBCWntYyolY0wsdpO61Aagq60joEeoQWM4Yb2l4hmLp10CTm6EJU
66SJoJkDR/VGCJHbFKUSHfJEsOPTyltbxUXR5hpvR+DpPPHO0l/e2uHzdQ3xLiKC
jSi+GfQbCYoZIBc5Hzl0rmJjECP7Mg+LEts4aV66s3zpRjaDfe4Won1sUvFxU9M=
=nwNR
-END PGP SIGNATURE-
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] Introducing SC4 -- feedback appreciated

[z...@manian.org]

At some level, this is in the same conceptual space as Peerio / Minilock.

The primary notable difference I see is you have used a binary format for
keys and messages.

Minilock uses a compressed curve25519 point without any metadata as public
key. This is more compact than your format. It'sBase58 encoded it is
tweetable which is very nice.

Minilock uses JSON for the message format rather than a binary format. I
also really like using a protocol buffers for message formats which is what
TextSecure does.

It looks like your key portability strategy is for users to manage their
keys directly as file they provide to instances. Peerio has switched to
providing users with a wordlist from which the private key can be derived
through a KDF for portability.





Text Secure
:
+1650-862-5992
Public Key


On Fri, Apr 17, 2015 at 10:56 AM, Ron Garret  wrote:

> TL;DR: I took tweet-NaCl-JS and wrapped a little PGP-like webapp around
> it.  I would like to solicit feedback and code review from this community
> before I submit it for a formal audit and release it to the general public.
>
> Links:
>
> Source code: https://github.com/Spark-Innovations/SC4
>
> Live demo: https://sc4.us/sc4.html
>
> FAQ for experts: http://sc4.us/expert_faq.html
>
> FAQ for non-experts: http://sc4.us/regular_faq.html
>
> Note that the FAQ links are not secure.  This will be fixed eventually.
> The production push process is a work-in-progress.
>
> Unique features of SC4:
>
> 1.  It is a standalone web application.  The server only serves static
> files.  You can even run SC4 from a FILE: URL, though this requires the
> keys to be embedded in the code.  SC4 includes code to automatically
> generate a standalone version.  This is mainly intended to be a
> proof-of-concept, but it does work.
>
> 2.  It’s tiny, and therefore easy to audit.  It consists of three standard
> libraries (tweet-NaCl, jQuery, and purify) plus <1000 lines of additional
> code, and that includes the HTML and CSS.
>
> 3.  It runs in FF, Chrome and Safari.  It might even run in IE but I
> haven’t tried it.
>
> SC4 aims for a point in the design space that balances security against
> ease of use.  PGP is bullet-proof, but not widely deployed because there is
> a lot of friction in getting it up and running.  SC4 aims to eliminate this
> friction while remaining reasonably secure.  It is also based on open
> standards so that more secure implementations can be easily produced in the
> future.  (Part of my long-term plan is to build an HSM dongle using a
> Teensy 3 board.)
>
> Feedback and constructive criticism much appreciated.  Also, I’m seeking
> someone to serve as a paid consultant on this project.  If you’re
> interested please contact me off-line.  My SC4 key is:
>
> ---START KEY---
> X-sc4-content-type: public-key
> From: r...@spark-innovations.com
> Timestamp: Fri, 17 Apr 2015 17:40:56 GMT
> AocfySUwQXhMGFezXFEJKPL77AoMLupwREpCeOZgRB4=
> RBDrBehSHbm1x/o+yPFrpdD6kWwSV3QQI8S/y8MdeEg=
> JaP8eUTkBh2OKRPJYSti9uTuB/vd8a+HV9rCCknw7l95
> a9C8lRa1PfP7/rcR8qwUM3BvXkBvT8kaZMJhcCoPCw==
> ---END KEY---
>
> Thanks,
> Ron Garret
>
> ___
> cryptography mailing list
> cryptography@randombit.net
> http://lists.randombit.net/mailman/listinfo/cryptography
>
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] Introducing SC4 -- feedback appreciated

[stef]

ohio,

On Fri, Apr 17, 2015 at 10:56:01AM -0700, Ron Garret wrote:
> 1.  It is a standalone web application.

putting keys in the browser is like putting keys in front of a dmz. browsers
are not designed for this, they are designed for delivering impressions and
services to you. the security features you find in any browser are there to
secure the revenue-stream of some companies, not for the protection of the
interests of its users. (same goes for phones), the tool might be good
(haven't checked), but the foundation it's built on is sand. you want to
isolate your keys, current end-host security does not provide much protection
against some malware in case recovery of your keys becomes a priority. you
also want to make sure the code running is authentic, with js delivered over
the net this is quite hard to do verifiably (again, not your protection,
industry revenues are the thing to protect).

cheers,s
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

[cryptography] Introducing SC4 -- feedback appreciated

[Ron Garret]

TL;DR: I took tweet-NaCl-JS and wrapped a little PGP-like webapp around it.  I 
would like to solicit feedback and code review from this community before I 
submit it for a formal audit and release it to the general public.

Links:

Source code: https://github.com/Spark-Innovations/SC4

Live demo: https://sc4.us/sc4.html

FAQ for experts: http://sc4.us/expert_faq.html

FAQ for non-experts: http://sc4.us/regular_faq.html

Note that the FAQ links are not secure.  This will be fixed eventually.  The 
production push process is a work-in-progress.

Unique features of SC4:

1.  It is a standalone web application.  The server only serves static files.  
You can even run SC4 from a FILE: URL, though this requires the keys to be 
embedded in the code.  SC4 includes code to automatically generate a standalone 
version.  This is mainly intended to be a proof-of-concept, but it does work.

2.  It’s tiny, and therefore easy to audit.  It consists of three standard 
libraries (tweet-NaCl, jQuery, and purify) plus <1000 lines of additional code, 
and that includes the HTML and CSS.

3.  It runs in FF, Chrome and Safari.  It might even run in IE but I haven’t 
tried it.

SC4 aims for a point in the design space that balances security against ease of 
use.  PGP is bullet-proof, but not widely deployed because there is a lot of 
friction in getting it up and running.  SC4 aims to eliminate this friction 
while remaining reasonably secure.  It is also based on open standards so that 
more secure implementations can be easily produced in the future.  (Part of my 
long-term plan is to build an HSM dongle using a Teensy 3 board.)

Feedback and constructive criticism much appreciated.  Also, I’m seeking 
someone to serve as a paid consultant on this project.  If you’re interested 
please contact me off-line.  My SC4 key is:

---START KEY---
X-sc4-content-type: public-key
From: r...@spark-innovations.com
Timestamp: Fri, 17 Apr 2015 17:40:56 GMT
AocfySUwQXhMGFezXFEJKPL77AoMLupwREpCeOZgRB4=
RBDrBehSHbm1x/o+yPFrpdD6kWwSV3QQI8S/y8MdeEg=
JaP8eUTkBh2OKRPJYSti9uTuB/vd8a+HV9rCCknw7l95
a9C8lRa1PfP7/rcR8qwUM3BvXkBvT8kaZMJhcCoPCw==
---END KEY---

Thanks,
Ron Garret

___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography