HN

Comments (39)

• Menu

  adrian_b
  I do not give a * about programmable cryptography, because it is not something useful for individual users or for small/medium businesses.It is something that big companies hope to be able to use for providing services to customers that will move all their computing needs to clouds owned by others, instead of owning their computers.The cryptographic applications that are useful for individual users and for small/medium businesses remain the traditional ones, e.g. data encryption, data authentication, random number generation, strong one-way hash functions, password hashing schemes.None of the algorithms suitable for programmable cryptography can ever approach the efficiency of the classic cryptographic algorithms, simply because the requirements for the classic algorithms are much weaker.Thus, no matter how universal an algorithm for programmable cryptography might be, it will not be an acceptable substitute for any of the classic algorithms, whenever the additional requirements for programmable cryptography are not necessary.
• Menu

  Retr0id
  I agree that we have more capable+flexible cryptographic primitives than ever before, but I don't really buy the "Universal Protocol" thing.For non-cryptographic uses we have "universal protocols" already, JSON being an example. You can adapt just about any format to and from JSON, if you want. But the fact that this is possible has not solved the interop problem, in the general case.Similarly for "Hallucinated Servers". Even if you trust all nodes (and don't need cryptography), distributed computing is still kinda hard, and we have to write programs in particular ways to make them efficiently distributable. I'm sure this can work really well for some problem domains, but it's a subset.
• DonsDiscountGas
  I really liked reading this but I imagine the impact will be a lot less than the author is imagining. Current encryption methods are pretty good to the point where privacy beaches are always social engineering or stolen laptop or something dumb like that
• hunterpayne
  Homomorphic encryption and similar techniques in this paper are just getting going. They are impressive technologies. However, they often take 100x the compute of "regular" systems with encrypted networking. This is probably the main blocker for these types of technologies. Until and unless insurance companies mandate these technologies because they are tired of paying out for their customers getting hacked, they probably won't be deployed. Probably for the best. Most devs can barely make code without advanced math and encrypted data work, let alone these types of advanced platforms.
• Menu

  tripplyons
  As much as I like the ideas, this article looks AI generated. This line with the bullet point, bolded label and colon, em-dash, and the second clause "it's about" all point to AI writing."Fiber-optic cables: Fiber-optic cables enable higher bandwidth phone lines and television—it’s about getting more television channels to more people."
• Menu

  miohtama
  Zk would perfect for online age verification, but governments do not want to implement it like this. Instead they want id and face collection for mass surveillance, using age verification as an excuse.
• IAmLiterallyAB
  Citation needed. We don't even know if indistinguishability obfuscation is possible.
• anon
  undefined
• pullthatupjamie
  But won't this make the Palantir AI Overlord angery?
• Menu

  Uptrenda
  Most of the crypto in the OP requires trusted setup phases and is too slow to use for any kind of general-purpose computation. It's the reason why most cryptographic protocols consist of simpler schemes and don't try to do everything. This article is click bait though. Feel like OP just stumbled upon what people have been doing for the past 5 years and wrote this half-baked article on it.
• Menu

  cyberax
  I've been looking at the field, and I can't really see how most of this is useful. ZKPs and FHE add a lot of complexity to a pretty simple task: verifying the age and/or identity.These tasks are so simple that you can _almost_ use the existing TLS client certificates for that. Their only drawback is that they're trackable. A simple asymmetric challenge-response system with a nonce easily fixes this:1. The service provider generates a 128-bit nonce and sends it to me.2. I use a verification system provided by my government, and it returns a document saying: "The owner is more than 18 years old, the nonce for the request was ......, and this proof is valid for this service name hash". This document is signed by the trusted government certificate.3. I send this signed document to the service provider.No need for range proofs and other stuff. I think this flow can even be expressed using OIDC and JWTs!What am I missing that requires full-blown ZKPs?