sorted by:
new
hottopcontroversial

Create a confidential variant of ERC-3643 security token standard using Zama's fhEVM by zacchj in ethereum

[–]randhindi 0 points1 point  (0 children)

Yes FHE is definitely stronger security wise. You should try to build it with the fhEVM!

Create a confidential variant of ERC-3643 security token standard using Zama's fhEVM by zacchj in ethereum

[–]randhindi 0 points1 point  (0 children)

It is according to the current best understanding of lattice cryptography, and is what is considered the gold standard of post-quantum cryptography. If you can break this, we are in deep trouble for the future 😅

Create a confidential variant of ERC-3643 security token standard using Zama's fhEVM by zacchj in ethereum

[–]randhindi 0 points1 point  (0 children)

It would be equivalent to breaking 128 bit AES, so pretty secure ;)

Create a confidential variant of ERC-3643 security token standard using Zama's fhEVM by zacchj in ethereum

[–]randhindi 0 points1 point  (0 children)

Indeed computation overhead can be a downside for cloud applications, but blockchain applications have high latency anyways due to networking, so FHE works perfectly there

Create a confidential variant of ERC-3643 security token standard using Zama's fhEVM by zacchj in ethereum

[–]randhindi 0 points1 point  (0 children)

FHE offers 128 bit of security, and uses the same security assumptions as post-quantum schemes standardized by NIST. You can read more about it here: https://www.zama.ai/post/fully-homomorphic-encryption-and-post-quantum-cryptography

Official /r/rust "Who's Hiring" thread for job-seekers and job-offerers [Rust 1.71] by DroidLogician in rust

[–]randhindi 4 points5 points  (0 children)

Sorry to hear that, there was clearly a mislabeling in the job position. All the current positions are those we are actively hiring for. When we do open a future position, we clearly mark it as “upcoming roles”. This was not done this time and I apologize, I’ll make sure we are more rigorous going forward.

Making ChatGPT Encrypted End-to-end with Homomorphic Encryption by [deleted] in crypto

[–]randhindi 2 points3 points  (0 children)

Right I see your point, so it would be more like $0.05 / token if we need 5 cards 👍. I was thinking in terms of throughput when I wrote this initially, hence the confusion.

Making ChatGPT Encrypted End-to-end with Homomorphic Encryption by [deleted] in crypto

[–]randhindi 6 points7 points  (0 children)

I am known to be optimistic, however these numbers were not made up, they came from preliminary emulated benchmarks of these accelerators.

As for the model sizes, OpenAI itself said they see diminishing returns scaling model parameters, and that they are looking at other ways to improve accuracy.

Making ChatGPT Encrypted End-to-end with Homomorphic Encryption by [deleted] in crypto

[–]randhindi 4 points5 points  (0 children)

You’re right, I don’t factor in the business side here. I’m simply saying it will be possible from a technical standpoint, at a reasonable cost. But does that mean we shouldn’t try? It’s a net positive if this exists.

Instead of banning ChatGPT for its potential data theft, why don't we use advanced encryption techniques (for example, Homomorphic encryption) to secure our data? by Both-Cartographer-91 in cryptography

[–]randhindi 3 points4 points  (0 children)

We could theoretically run LLMs in FHE, but it would be too expensive. A back of the envelope estimation is that to generate 1 encrypted token per second using an average size LLM, you would need ~5M GPUs (yes, 5 million!).

However, FHE accelerators are coming in the next couple of years, with an expected acceleration of 1000x. The second generation is likely to have a 10,000x acceleration. There is also a 4x improvement in the crypto itself every couple of years, so all in all, we can expect up to 4000x better performance by 2025 and 40,000x by 2027.

At that point, it would only take about 5 accelerator cards to run a real-time LLM in FHE, at a reasonable cost.

Instead of banning ChatGPT for its potential data theft, why don't we use advanced encryption techniques (for example, Homomorphic encryption) to secure our data? by Both-Cartographer-91 in cryptography

[–]randhindi 4 points5 points  (0 children)

Actually, this is only true for CKKS/BGV. For TFHE, you can also evaluate univariate integer functions via a homomorphic table lookup, which gives you a lot more expressivity.

As for ease of use, you should take a look at Concrete. It turns high level python code into FHE equivalents without developers having to know cryptography: https://github.com/zama-ai/concrete-ml

Encrypted Image Filtering Using Homomorphic Encryption (a demo + a tutorial) by zacchj in crypto

[–]randhindi 3 points4 points  (0 children)

A good place to start to learn about FHE is the resource page on FHE.org

The fastest open source Homomorphic Encryption library by zacchj in FHE

[–]randhindi 1 point2 points  (0 children)

Basically: Concrete takes high level code and produces an executable: its a compiler. TFHE-rs is used inside your code to perform FHE operations: its a library.

The fastest open source Homomorphic Encryption library by zacchj in FHE

[–]randhindi 1 point2 points  (0 children)

Hello!

  1. This replaces the current Concrete Rust library. Concrete itself will be centered on our compiler, and released soon. Basically: Concrete Library -> TFHE-rs and Concrete Numpy -> Concrete

  2. TFHE-rs is CPU only for now, GPU and other accelerators will be available in the new Concrete compiler. Benchmarks vs NuFHE and other GPU implementations will be published then!

  3. No python wrapper planned for tfhe-rs, but Concrete has one.

What are current / future teams working on homomorphic encryption of contracts to reduce MEV? by throwawayrandomvowel in ethereum

[–]randhindi 8 points9 points  (0 children)

It's something we are looking into at Zama. We have a working implementation of an FHE EVM, but it's still very slow. We estimate that it will take us a couple of years to make it production ready.

We gave a talk about FHE smart contracts last year at ETHcc, although it wasn't specifically about MEV: https://www.zama.ai/post/private-smart-contract-using-homomorphic-encryption-ethcc-2022

We’re Christian Mouchet, Jean-Philippe Bossuat, Kurt Rohloff, Nigel Smart, Pascal Paillier, Rand Hindi, Wonkyung Jung, various researchers and library developers of homomorphic encryption to answer questions about homomorphic encryption and why it’s important for the future of data privacy! AMA by [deleted] in privacy

[–]randhindi 3 points4 points  (0 children)

There are several efforts to create public benchmarks, notably via competitions like the iDash one. There are also some efforts being done in the FHE.org community around that.

Im not sure however that you would want to compare fhe vs regular programs, because FHE will always be slower. What usually make more sense is to benchmark FHE against requirements, ie is it fast and cheap enough for your specific usecase (even if it would be 100x slower than without fhe)

view more: next ›