
Cryp.sr - the next step - alexandros
http://corte.si/posts/security/crypsr-evolution.html
======
cturner
Impressive idea and implementation. I love that you're going for vi
keybindings.

Lots of possibilities. You could add a popup that comes in when user presses
':' to allow macros.

I'd prefer it if you went with 'a' being to edit the current line, and puts
the cursor at the end; 'i' to edit line with cursor at beginning, and to use
'o' for add-new-line-after-current line; 'O' to add the line before.

If you could turn this into a powerful text editor that would be really neat.

Another thing that might be useful is an authentication mechanism that tries
to proof against the most obvious internet-cafe afflications (keyboard
grabbers, that sort of thing).

~~~
mitjak
+1 for the macros, -1 for a powerful text editor. Keep it simple.

------
ErrantX
Unless I have read this wrong cryp.sr uses Javascript to encrypt/decrypt data
right?

In which case "host proof" is really only a marketing term. This has been
discussed a couple of times here in the past week or so (mostly by tpatcek)
and, really, there is no way to effectively secure data _just_ with
Javascript.

These sorts of apps have some use - so long as users understand the flaws
involved and trust the server owner (and their browser).

~~~
cortesi
This is not correct, on a few fronts. It _is_ possible to secure data with
just Javascript (with care), and "host proof" describes a design philosophy
that has real meaning - Google the term, and look at excellent commercial
projects like Clipperz (who use "zero knowledge" as a synonym for "host
proof"). You can also read this post I wrote when I took my first skeptical
look at the idea. It discusses how and why the host-proof idea could work, and
finds some flaws in Clipperz and PassPack, the two most prominent "host-proof"
commercial apps:

<http://corte.si/posts/security/hostproof.html>

I should note that Clipperz has now addressed all the points I raised in my
post.

The "host-proof" idea has been around for a while, but is really just in its
infancy. There's a lot of work to be done, but the idea is both important and
promising.

~~~
ErrantX
Yes I understand your point; but it still comes down to trusting to server
(which is fine, but it is something "host proof" doesn't really encourage
IMO).

The verification is all very well and good; but you have to either verify the
code each time (a pain) or trust the server between the times you do review
the code.

For most people reviewing the code is impractical.

We discussed all this before in great detail; I'll try to dig out the threads.
But from a security perspective this sort of stuff has a use, but not for
things you really must keep secure.

As a start: because the code of the app is sent "over the wire" with some
regularity it is trivial to intercept and modify it.

~~~
cortesi
Again, you should read more on this issue before you criticize the idea in
absolute terms. Yes, verification is necessary, which is why I wrote a browser
addon that can do hash-based verification of the application every time the
page is loaded (described here: <http://corte.si/posts/security/crypsr.html>,
with links to the github project), and which is why cryp.sr has application
hashes published with every modification. Yes if you send your traffic
unsecured over the wire, it's trivial to modify it. Which is why cryp.sr, and
any other good host-proof app, uses SSL, which is designed to counter exactly
that type of threat.

The techniques are still clunky - but that's because it's very early days, and
we're still developing the tools and techniques to make things seamless. The
basic idea, however, is entirely sound, and increasingly important.

~~~
tptacek
There is no less hospitable environment to try to run crypto code in than
browser Javascript.

Start with content-controlled code, which you somehow have to memorize and
reverify before you run.

Now load that code through the HTML DOM, which allows Javascript to be run
based on tags and attributes littered throughout markup.

Now consider that you're working in a language that allows virtually any
operation to be transparently overridden.

"Clunky" and "very early days" are not words that harmonize well with "basic
idea is entirely sound". The basic idea simply isn't sound.

~~~
cortesi
I'm as wary of Javascript as anyone - in fact, your first sentence is
practically a verbatim quote from my first post on the host-proof idea.
However, I don't think that there needs to be a superstitious dread about this
- it just means we have to think harder, work more carefully, and perhaps
encourage some changes by browser creators in the longer term.

~~~
tptacek
You're as wary of JS as anyone. Browsers themselves may need to change to
admit to your solution. But you'll advertise it as secure today.

~~~
cortesi
Browser changes can make things more convenient, but we have all the tools to
create secure though somewhat cumbersome host-proof applications today. Yes,
the Javascript environment sucks, but it's what we have - dismissing the
possibility that we can do secure crypto with strictly controlled input, where
all components are verified, is not reasonable and not backed up by evidence.

------
roryokane
The idea is cool, and I like your additional list features. But the interface
needs more alternate, intuitive ways of navigation compared to the vim
keybindings (I don't use a terminal text editor). You can already click on an
item to select it, but it would be nice if you could drag and drop the items,
both up and down and left and right.

Actually, I think all the interface features I suggest would just be in
OmniOutliner (<http://www.omnigroup.com/products/omnioutliner/>) – just try
out OmniOutliner if you can and note the interface. The most relevant keyboard
shortcuts: Command-Shift-{ and } for creating a new parent-sibling or child,
Esc for toggling between selecting the list item and editing it, left and
right for collapsing and expanding items. There might be features in its menus
and inspectors that would be useful, too.

Also, a toggle-able help toolbar might be nice. It would display the key
bindings in the ? help box along with their descriptions, and they would be
clickable links. This would make it easier for new users to learn the key
bindings.

------
mileszs
Nice. I love the vim keybindings and markdown support.

I was unable to bring up the help modal box when pressing '?'. The only way to
get to it was to use my mouse to press the question mark link at the top
right.

This seems an odd place for this sort of feedback, but I saw no other avenue.

~~~
cortesi
Odd. What browser did you use? The other keybindings worked, I take it?

I just noticed that cryp.sr had made it to HN - I'll check here for bug
reports, or you can just email me at aldo@corte.si.

~~~
ihumanable
I'm having the same problem.

Firefox 3.6.3 on Mac OSX 10.5.8

All the other keybindings worked fine.

------
samdk
This is really cool. I've thought about how a host-proof app might be built,
but not very seriously. I actually have a pretty simple project coming up
that'd benefit from it, too. Maybe this'll motivate me to experiment. Any
resources/reading you'd suggest, or have you mostly been figuring this out on
your own?

 _edit_ Ah, I see you've written a bit on it yourself
(<http://corte.si/posts/security/hostproof.html>). Time to go exploring!

As far as the actual app goes, I have only one real gripe. Being used to Vim,
I expect i to add before and a to add after (with I adding at the beginning,
and A at the end). Not having i/I do anything confused me for a moment.

~~~
cortesi
I agree. I might add "i" as an add-before keybinding in the next release.

~~~
jessor
heh, confused me for a second, too.

anyways, it's super cool to see this expand into a really useful webapp. keep
going!

