geekbeast · HackerTrans

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 [email protected] to apply.

geekbeast

11 anni fadiscuss

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

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

geekbeast

11 anni fadiscuss

We agree. RC4 must die.

Will post back once we have resolved the issue.

geekbeast

11 anni fadiscuss

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

geekbeast

11 anni fadiscuss

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.

geekbeast

11 anni fadiscuss

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.

geekbeast

11 anni fadiscuss

This.

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

geekbeast

11 anni fadiscuss

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

geekbeast

11 anni fadiscuss

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.

geekbeast

11 anni fadiscuss

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?

geekbeast

12 anni fadiscuss

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.

geekbeast

12 anni fadiscuss

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.

geekbeast

12 anni fadiscuss

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.

Doing the above will make it very difficult to prove the security of malleable cryptosystem, something that Boneh, Sahai, and Waters have written multiple papers on. The approach of finding a minimum number of cycles to complete the computation seems much more effective, if restrictive in the number of operations that can be evaluated.

I'll e-mail you guys offline.

geekbeast

12 anni fadiscuss

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}

Does this imply that hcrypt VM is not necessarily equal to a Turing machine? The program counter seems like it could definitely cover finite automata, but it doesn't seem expressive enough to simulate a stack. If PC is always encrypted then it ends up having to encode both current state and the information necessary to evaluate the branch implicitly as a state change, which again seems more like finite automata.

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

geekbeast

12 anni fadiscuss

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}

Keep going for all the powers of two expressible in the system and you can quickly check if every bit is set. This makes proving security for functional schemes that allow malleability very difficult, since you have to prove that the reachable set of states with the built in malleability does not reveal sufficient information for the attacker to compromise the security of the system.

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.

geekbeast

13 anni fadiscuss

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.

comments