Comments

billswift • November 24, 2009 7:08 AM

I went to their web site and they look to be just a simple to use way to post encrypted material to the Web. Is there some problem with their cryptography or algorithms?

Here’s what they claim:
“Cryptography used on a norbt

Let’s assume that the hacker gets access to the server and obtains the data stored there.

The data stored on the server for a norbt is:

answer: SHA1(answer + salt1) , salt1
text: AES128(SHA1(answer + salt2), IV, Mode.CFB, text), salt2, IV

For the hacker to crack the text she will have to break either SHA1(answer + salt1) or AES128 directly.
Listening to traffic won’t work to break a norbt because all encryption and decryption operations are performed in the browser. If the hacker breaks SSL to look at the traffic she won’t get any more data than what is stored on the server.”

bob • November 24, 2009 7:20 AM

Getting the password/passphrase/keymat to the other party securely is always the problem.

If all you want is to send info to people who already share a common passphrase, use Encryption Wizard (black helicopter/tinfoil hat alert: USG provided software link) http://spi.dod.mil/ewizard.htm and just post the encrypted file for download on your webpage.

dmc • November 24, 2009 7:45 AM

I don’t see this technology as useful for the applications they mention (e.g. emailing around passwords, bank account info, etc.) It looks too easy to break for information that you actually care about.

On the other hand, I see it as useful for things that aren’t terribly dangerous to disclose, but that you’d rather keep among friends and family. Say I’d like to be able to post pictures of my family, but I don’t really want those pictures randomly floating around the internet, used in god knows what way. So I post them with a norbt, and let my friends and family know how to access it. There’s a small chance that someone would break my norbt and use my photos anyway, but really, why bother? There’s easier targets.

Anil Kurmus • November 24, 2009 7:57 AM

@Bruce, billswift: This could work, one advantage over a classical .htaccess (or other authentication) being that a server compromise won’t give the users data directly, although the implementation here is cryptographically broken, assuming ‘+’ stands for concatenation. SHA1 is vulnerable to extension attacks; basically one can compute SHA1(answer) from SHA1(answer+salt1), salt1 and then SHA1(answer+salt2) from SHA1(answer), salt2 (to see this, assume answer is of the size of a SHA1 input block). They should either have used a proper HMAC scheme, or simply just an authenticated encryption mode, such as GCM/CCM in my opinion.

The other, more obvious problem, is that an attacker compromising the server (or being able to perform an active SSL MITM) could either just replace the javascript to send the answer back to the server. But this means that the attacker has to wait, so it’s not entirely useless.

AppSec • November 24, 2009 8:19 AM

You guys are missing the point of the name.. No robot… robots.txt files..

It’s to prevent getting cached in search engines.

paul • November 24, 2009 8:22 AM

It moves your problems from the server to the browser. Depending on the kinds of attacks you anticipate, this can be useful or not.

jgreco • November 24, 2009 9:04 AM

@AppSec

If that really is its purpose, then it really is useless. All of the major webbrowsers respect robots.txt

Matteo • November 24, 2009 9:14 AM

A very similar project is the italy based encryption engine (online since 2007-07-11) named http://ncrypt.it

(DISCLOSURE: I’m a CO-Creator)

NCrypt.it starts from the assumption you should NOT trust even the platform, thus it encodes a single message in AES256 CLIENT SIDE and only after that the message is stored. The server cannot (and will not) store neither the plaintext not the password and decoding is based too on client side encryption too.

The user is then given a tiny-urlesque url to send. What passes on the wire is only the cypher.

Part of the magic is performed by a javascript AES256 implementation and the real commandment behind the project is “trust no one”.

The javascript itself is commented and everything is in plain view. Messages are stored for a week and then deleted.

For more info:

The Website: http://ncrypt.it
The TOS: http://ncrypt.it/tos.php
A FAQ: http://ncrypt.it/faq.php

…and you should know something about AES, don’t you? 🙂

JohnJS • November 24, 2009 9:32 AM

@jgreco

I guess if you wanted to block all indexers (including shady non-robot.txt conforming ones) this might be valuable. Of course, I’d suggest that if you don’t want something indexed and cached at all, don’t post it in the first place…

Team America • November 24, 2009 9:38 AM

Twitter offers to display you 140-character low-tech e-mail for free, so people are pretty good at finding problems, even for a dominated solution.

Paul Crowley • November 24, 2009 9:41 AM

billswift: I can’t see how to prove anything good about that method without invoking the random oracle model. A good method is one amenable to good proofs.

Ed • November 24, 2009 9:44 AM

The stuff about encryption is a red herring, or at best an implementation detail. This is nothing more than hiding information behind a captcha, and not a particularly good captcha at that (plain-text question, only one question/answer pair).

uk visa • November 24, 2009 10:07 AM

Bruce and all,
Please, forgive me asking a dumb question: you say it’s a ‘low-security’ solution but how secure is it compared to a ‘no-security’ solution like email?
It strikes me that ‘low’ might be 50 times safer than ‘no’…

Dom De Vitto • November 24, 2009 10:10 AM

Uhhh, isn’t everyone missing a point here – it’s basically a CAPTCHA for a web-page, with a (static) question. e.g. Keeps programs from pulling the pages, at least a human needs to be involved every time the question is changed. Also unlike a CAPTCHA, it doesn’t trust the web server administrators, only the content developers, who already have the content.

Sounds pretty reasonable for that – I don’t think it’s for keeping the NSA out 🙂

It’s still vulnerable to Rectothermal cryptoanalysis attacks….

pj • November 24, 2009 10:39 AM

I can see uses for this. Think of clubs and organisations that may want to be accessable to members, but not the public. Perhaps a magicians website would ask the question “What is the prop used in this famous trick..”. Fellow magicians would enter, say, “thumb tip” and have access to the magicians only section. Obviously it’s not very secure, but will keep out most of the non-members most of the time.

bob • November 24, 2009 11:16 AM

Oh, I get it – its like GIs in WWII asking “How many home runs were hit in the world series last year” to see if you are a German bot (well, spy back then).

John Thurston • November 24, 2009 11:21 AM

I think I accomplish this same thing with apache basic-authentication function in .htaccess I have web pages I want people to see, but I don’t want indexed by google. The text I put on the prompt includes the username the user should enter.
“Type ‘friend’ with no password to enter”
Of course, even that is too complicated for some people 😛

David Donahue • November 24, 2009 12:22 PM

It seams to me that if the website hosting the Norbt was compromised then it would be trivial to change the decryption applet to record the password from the next user to come by and view the page (in a kind of website version of an evil maid/admin attack).

The hosting server being compromised to unfriendlies is what you’re trying to protect against here. That very fact is what breaks the secrecy of the encryption key. It’s a fundamental flaw in the design.

So, I’m with Bruce here, I don’t think this solution has any value.

Petréa Mitchell • November 24, 2009 2:14 PM

I could see some use for this in fannish circles as a sort of coolness filter. E.g. answer this trivia question about an obscure character, or you’re not a big enough Twilight fan to see this page…

I think this is the first time something on the Web has informed me I need to turn JavaScript on for “security reasons”.

Jacob • November 24, 2009 3:04 PM

Dom…”It’s still vulnerable to Rectothermal cryptoanalysis attacks….”
I’m obviously too tired. I read that as rectothermometer crypto attack. My first thought was what is that? 🙂
time for a nap.. take my expresso away.
What do you want to bet someone sees this a threat that shields the bad guys from surveillance?

Brian • November 24, 2009 4:01 PM

If its on a website, and relies on javascript (or similar), nothing prevents the attacker from injecting some code that phones home with the password (yay, ajax). Or the attacker can send a similar document in an email and phish the password. There are too many problems with this for me…

Nostromo • November 25, 2009 1:54 AM

There are lots of websites which require a password and use https. What is the niche not covered by this that Norbt is addressing?

David VG • November 25, 2009 2:28 AM

IMHO, this is a solution against robots and indexers. Only a human could reveal the content (good solution to protect emails, and other key items). I wouldn’t recommend other uses.

Marcus • November 25, 2009 2:39 AM

“It strikes me that ‘low’ might be 50 times safer than ‘no’…”
imho bad security is worse than no security at all. If everyone knows that Bebo requires no registration to view profiles then the girls don’t post their bikini photos, but if they think it’s secure they share details of their hot date last night, only to find themselves the town gossip.

Norbt is a captcha variant, however you cut it.

Bruce Clement • November 26, 2009 4:15 PM

@Nostromo: The difference is that the server (website) does not have the decrypted data, that never left the client PC. This means that compromising the server does not immediately reveal everyone’s secrets.

Others have already pointed out that compromising the server could be used over time to harvest keys and eventually reveal the secrets.

Anonymous Anonymous • November 26, 2009 7:59 PM

@licence, @answer: That is Javascript, not Java. Furthermore, at the link provided in the source, you’ll find this: “You are welcome to re-use these scripts [under a LGPL license, without any warranty express or implied] provided solely that you retain my copyright notice and a link to this page.”

Norbt, on the other hand, uses this: http://code.google.com/p/slowaes/

Roger • November 27, 2009 8:27 PM

@Anil Kurmus :

SHA1 is vulnerable to extension attacks; basically

SHA1(answer+salt2) from SHA1(answer), salt2 (to see this, assume answer is of the size of a SHA1 input block).

This is true.

one can compute SHA1(answer) from SHA1(answer+salt1), salt1 and then

Que? I don’t believe this is true at all. This part is not an extension attack, it’s a pre-image attack. No-one has yet published a pre-image attack on the full SHA-1; they have done so for reduced round variants only, and even then the attack is theoretical because even for reduced rounds the work factor is > 2^128.

In short, your proposed attack doesn’t work.

Roger • November 28, 2009 3:08 AM

I replied to Anil Kurmus :

SHA1 is vulnerable to extension attacks; basically

SHA1(answer+salt2) from SHA1(answer), salt2 (to see this, assume answer is of the size of a SHA1 input block).

This is true.

But I now think that actually, that isn’t true. To do this by the extension attack, the attacker has to be able to choose salt2 so that answer+salt2 has a special form. Specifically, salt2 has to start with the length-indicating block that was appended to the original message by MD-strengthening before it was hashed; note that if you “assume answer is of the size of a SHA1 input block” then the indicator is still added, but is a full block in length.

In this case salt2 was generated by the server ahead of time and cannot be adjusted, so unless you are very lucky its header will not match and the second part of the attack will not work.

Having said that, I also amend my comment:

one can compute SHA1(answer) from SHA1(answer+salt1), salt1 and then
… This part is not an extension attack, it’s a pre-image attack.

Sorry, my error, actually it’s not a pre-image attack, although neither is it an extension attack. This part may well be feasible, but it’s not trivial and I don’t know of any results for it (be very interested if you have any refs.) Consider the following (and note that in this application we will mostly have just one block, since 512 – 128 – 72 = 39 bytes which is a fairly long “answer.”) Now if f is the compression function, c_0 the IV, M the original message, and s the suffix that was appended, then you are saying that if we know:
SHA1( M || s) = f( c_0, M || s || pad( M || s) )
then we can find
SHA1(M) = f( c_0, M || pad(M) ).
This isn’t at all the same as a pre-image attack. In particular, f() is invertible in c — that is, given the message block and output, it is readily possible to find the previous chaining value. (In effect, f() works very much like a block cipher in OFB mode, in which the c_i are the inputs and outputs, and the message blocks are used as keys. If you know the key for a block, you can run it backward.) So we may think that we could guess, by brute force, the value of pad(M || s), then unwind the rounds of f() as far back as the last time we applied M, then reapply pad(M). We will get a small number of results depending on our guesses for the length of M, and we can test them against the server.

If the words of the message block were simply used as “subkeys” in consecutive order, this would work. For the SHA family it isn’t quite so easy, because of the mungifying step which occurs to the message block before it is used as the “key” to f(). It has the effect that the final few “subkeys” depend on every input bit. Thus we cannot reverse the rounds unless we know all the message block bits, or at least we have missed so few we can guess the rest. The alternative is to find some analytic attack that enables us to find all the subkeys, given the input and output; but then, that is the pre-image attack and the best current version has an infeasible work factor.

haber24 • December 2, 2009 4:41 AM

If the words of the message block were simply used as “subkeys” in consecutive order, this would work. For the SHA family it isn’t quite so easy, because of the mungifying step which occurs to the message block before it is used as the “key” to f(). It has the effect that the final few “subkeys” depend on every input bit. Thus we cannot reverse the rounds unless we know all the message block bits, or at least we have missed so few we can guess the rest. The alternative is to find some analytic attack that enables us to find all the subkeys, given the input and output; but then, that is the pre-image attack and the best current version has an infeasible work factor.

Raku • January 3, 2010 4:24 PM

This seems to create more problems than solutions. If I want to share with a friend I just use Mashed Life instead creating problems for myself and others. Especially many answers, keep changing over time.

Leave a comment

Login

Allowed HTML <a href="URL"> • <em> <cite> <i> • <strong> <b> • <sub> <sup> • <ul> <ol> <li> • <blockquote> <pre> Markdown Extra syntax via https://michelf.ca/projects/php-markdown/extra/

Sidebar photo of Bruce Schneier by Joe MacInnis.