Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Programmable Cryptography (2024)

0xparc.org

Post reply on HN
Print view View original

31–40 of 47 posts

Re: Programmable Cryptography (2024)

#31

Post by tern »

tripplyons wrote: post #17

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."

I know I'm just adding to the noise here, but it seems like half the time I look at comments on posts (anywhere) I see a claim like this. I think you're probably just trying to warn people so they don't waste their time, but for me this type of comment is not helpful at all.

Re: Programmable Cryptography (2024)

#32

Post by tern »

Uptrenda wrote: post #23

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.

0xparc is a research lab. They may be wrong or mislead, but they work on this stuff every day—it's not some guy stumbling across something.

Re: Programmable Cryptography (2024)

#33

Post by j2kun »

cyberax wrote: post #12

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 p…

How would you prove to the government in step 2 that you are the person whose age they're certifying?

This also seems like a lot of effort to maintain uptime and security of a service like this as scale, when errors would potentially keep people locked out of essential services. A system that requires a one-time download of a user-specific secret key, which can then be used to interact with the service provider directly, would be much more scalable...

Re: Programmable Cryptography (2024)

#34

Post by cyberax »

j2kun wrote: post #33
cyberax wrote: post #12

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 p…

How would you prove to the government in step 2 that you are the person whose age they're certifying? This also seems like a lot of effort to maintain uptime and security of a service like this as scale, when errors would potentially keep people locked out of essential services. A system that requires a one-time download of a user-specific secret key, which can then be used to interact with the service provider direc…

> How would you prove to the government in step 2 that you are the person whose age they're certifying?

How would you prove to the black box ZKP that you are the phone owner? Same problem. An interpretive dance before the camera, singing the national anthem, scanning the passport, etc. Doesn't really change anything.

> This also seems like a lot of effort to maintain uptime and security of a service like this as scale, when errors would potentially keep people locked out of essential services.

This is also trivially solveable with classic crypto. Just pre-generate a few (hundred) tokens for each user. The user just needs to generate a bunch of one-time private/public keys and get the "user is at least 18" certificates for each of the public keys. Then the user can just use them one by one as needed.

Apple Pay works this way, btw. That's why you can make payments with an Apple Watch while it's completely offline.

Re: Programmable Cryptography (2024)

#35

Post by Uptrenda »

sali0 wrote: post #30
Uptrenda wrote: post #23

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.

This was true 3 years ago but not generally the case anymore. There's been significant advancements to move away from trusted setups and the speedups with current methods are quickly approaching viability.

List some

Re: Programmable Cryptography (2024)

#36

Post by Uptrenda »

tern wrote: post #32
Uptrenda wrote: post #23

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.

0xparc is a research lab. They may be wrong or mislead, but they work on this stuff every day—it's not some guy stumbling across something.

Where are their novel papers?

Re: Programmable Cryptography (2024)

#37

Post by wmf »

tripplyons wrote: post #16
miohtama wrote: post #2

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.

One problem with private age verification is that because each verification cannot be traced back to a user, it is hard to prevent abuse like credential sharing. Imagine how a single stolen credential can be used by any number of users because the verification step kept the credential private.

I assume they are solving this with secure enclaves creating one-time signatures.

Re: Programmable Cryptography (2024)

#38

Post by ulrikrasmussen »

miki123211 wrote: post #18
miohtama wrote: post #2

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.

Europe is rolling out ZKP afaik. The actual problem with ZKP is that you need a way to prevent generating thousands or millions of assertions from one ID and distributing them to whoever wants one, in a way which is undetectable and unstoppable by the government, and the only way to do that is with Google Play Integrity Protection and such.

Sort of, but not really. They have a design document for how ZKP-based age verification would be implemented in the white-label prototype app, but it is my understanding that the first implementation to be rolled out in the early adopter countries like mine (Denmark) will be based on "trust me, bro" central verifiers who promise not to do logging, with ZKP mentioned as a possible future alternative. Until I see the requirement of ZKP or equivalent provable zero-trust privacy guarantees in the law, I consider the promise of ZKP as a distraction (lie) to shut down the harshest criticism.

Google Play Integrity is not a requirement, but governments think it is. All you need to avoid trivial duplication of certificates is that keys are bound to a device which is also able to perform the primitive cryptographic operations needed to construct a ZKP proof. This could be achieved using a USB dongle. Still proprietary technology, but the scope of what needs to be locked down is much, much smaller than with a solution like Play Integrity.

Re: Programmable Cryptography (2024)

#39

Post by 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.

Re: Programmable Cryptography (2024)

#40

Post by ozim »

adrian_b wrote: post #39

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/me…

The article reads exactly like written by a person who is much into the topic imagining use cases that are not there.

It also reads like a junior dev or a student with „universal” having too much value in their own words.

Post reply on HN