geekbeast

Redwood City has a lot of nice houses near the downtown for under $2M

Like this? http://www.abc10.com/news/local/sacramento/modular-apartment...

Kryptnostic | Redwood City, CA | ONSITE

We're helping individuals and organization safely leverage their data in the cloud by building products & services that make it possible to search encrypted data server side without access to plaintext or keys.

We're looking for an experienced front-end engineer with deep knowledge of HTML5/CSS and React.js. No crypto knowledge required and mobile experience a plus.

Submit a resume to jobs@kryptnostic.com to apply.

Registration is a request to https://api.kryptnostic.com, which gets an A:

https://www.ssllabs.com/ssltest/analyze.html?d=api.kryptnost...

We agree. RC4 must die.

Will post back once we have resolved the issue.

We'll have a more readable write up available on ePrint, soon.

Yes, but there are some limitations when doing server side sharing of documents without a central trusted authority.

It's dangerous to accept shares from untrusted sources as it exposes you to attacks by malicious servers colluding or impersonating a user.

Without using Oblivious RAM you risk losing query privacy, when indexing documents that consist of one word repeated many times.

This is definitely an issue and has been for a few years now: http://community.embarcadero.com/index.php/blogs/entry/the-h...

One thing in our favor is that we're not using a lattice or ring-learning with errors approach, which is where the majority of the patents lie.

Our general IP strategy is to only use patents defensively, and make that technology available under open source licenses that allow unrestricted non-commercial use.

We're also making all of our SDKs Apache v2 so that its easy to integrate into other software stacks.

This.

If you aren't doing client-side encryption and keeping the keys private, the server has access one way or another.

From a practical perspective, yes. From a threat model perspective not really.

There's a third risk here.

3) Exploit programmatic access or side-channel attacks on the data.

If the server can decrypt the data and this is driven by code on the box, then you're in a DRM-like situation trying to hide data from a program that has legitimate access.

As you alluded to earlier protecting data at rest doesn't protecting during use.

Amazon and other tech companies can design systems where the keys are held entirely by the end-users. How far is the US willing and able to go to get at that data?

Agreed.

Without a trust the only thing that comes close is an in person P2P pairing ceremony.

Key management might work in an enterprise setting with a central authority, but making sure your friend's public key isn't swapped with the government's is pretty hard if you don't trust the cloud provider, telecom, or intermediate infrastructure.

Open source client libraries providing end-to-end encryption and zero knowledge search, would enable a functional e-mail system that operates without any server held keys.

You could still NSL a backdoor, but if the service is open source at least there's a chance of the code being audited.

Just went and read your paper.

  VII. OPEN ISSUES AND FUTURE WORK
  ...
  One of the main issues of our concept is the termination problem. To solve this problem, a crypto-system that can selectively decrypt information is required.

I'll e-mail you guys offline.

Curious about a detail here. If this machine can evaluate AND and XOR, then how do you prevent a malicious attacker with the public key from performing encrypted each power of two, performing an AND and comparing with zero?

  {x&0x2} = {0x2}

If you guys figured out how to securely implement control ( halting, loops, etc ), without functional encryption, that would be a huge breakthrough in FHE.

tl;dr here be dragons.

The ability to evaluate statements such as x == 5 falls under the realm of functional encryption ( see Boneh, Sahai, and Waters for a good intro http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.383... ).

You have to be very careful when mixing functional schemes with FHE schemes as it is very easy to create a completely insecure system.

For example, if you could evaluate arbitrary circuits consider what happens if you can evaluate equals and bitwise AND, two simple circuits.

  ({x}&{0x1}) == {0x1}
  ({x}&{0x2}) == {0x2}
  ({x}&{0x4}) == {0x4}

One more thing worth mentioning is that a direct comparison of ciphertexts doesn't work for semantically secure schemes. Anything that is IND-CPA, for example RSA-OAEP, will have the same plaintext encrypt to two different ciphertexts. Giving the untrusted server the ability to determine whether two ciphertexts will destroy the semantic security of the scheme, by definition.

The ability of an entity or entities to cause damage beyond their ability to compensate people for their aggression is not addressed either. For example the Bhopal gas tragedy or Anaconda Mining Corporation's superfund site ( luckily their purchaser agreed to assume majority of clean up costs, but there are things that cannot be cleaned up ). Other examples include Chernobyl and Fukushima, which were not aggressive acts until accidents rendered hundreds of sq miles unlivable.

A potential solution is to force actors to pay a risk premium, but humans are notoriously bad at accurately pricing risk for rare events with outsized negative costs. Administering any solution requires such high levels of coordination and enforcement that ( as the author says ) you end reinventing government.