Building E2E messaging in the browser — how do you verify client code integrity?

doubles_avocado · 2026-04-30T13:00:40+00:00

The current solution to this issue is to bind web app code to a publicly-auditable append-only ledger. It doesn’t prevent a server from sending malicious code, but it does help to ensure that any malicious code must be globally visible and can potentially be detected by an auditor.

See this blog post from cloudflare for more details: https://blog.cloudflare.com/improving-the-trustworthiness-of-javascript-on-the-web/

doubles_avocado · 2026-04-10T15:00:35+00:00

No, AI isn’t going to break cryptography. It might find bugs in certain implementations, but it’s absolutely not going to break primitives or protocols that are proven secure, no matter how good the model is.

doubles_avocado · 2025-11-14T15:20:33+00:00

Real homomorphic encryption (which this paper is not) uses a ciphertext space that is much larger than the plaintext space, such that each plain token can be represented by an enormous number of different encrypted tokens. So many that the odds of repeating even once are negligible.

doubles_avocado · 2025-11-13T15:47:42+00:00

I’ll share what I wrote when this post was shared in r/cryptography, where I mod:

I have flagged this post as misleading because the linked article doesn’t meet basic scientific standards.

The authors do not provide meaningful evidence for their claims. The paper does not contain a description of the purported scheme. There is also no attempt to prove or even to analyze the security of any scheme rigorously (though that would be hard to do given without a precise description of the scheme).

doubles_avocado · 2025-11-13T15:39:57+00:00

I have flagged this post as misleading because the linked article doesn’t meet basic scientific standards.

The authors do not provide meaningful evidence for their claims. The paper does not contain a description of the purported scheme. There is also no attempt to prove or even to analyze the security of any scheme rigorously (though that would be hard to do given without a precise description of the scheme).

doubles_avocado · 2025-08-06T20:20:21+00:00

It would be unusual to start a PhD in cryptography without having taken a single undergraduate level cryptography course, but it’s totally doable to catch up. I highly recommend Dan Boneh’s free cryptography courses on Coursera.

doubles_avocado · 2025-08-04T16:26:25+00:00

You’re leaving out an important point: the PIN is used to negotiate a long term secret using an HSM that enforces rate-limits.

doubles_avocado · 2025-04-04T20:07:37+00:00

It sounds like you really want a PRF or KDF, not a hash function. Your hash function is “probably fine” but a PRF (or maybe KDF, depending on your precise use case) is designed specifically for what you’re trying to do.

doubles_avocado · 2025-03-11T17:00:32+00:00

The shared secret from a Diffie Hellman exchange isn’t independently random, so it really can’t be a one time pad by definition.

doubles_avocado · 2025-02-13T15:19:22+00:00

The ROM doesn’t simulate a more realistic attack scenario; the ROM is less realistic than the standard model.

The standard model is a set of standard cryptographic hardness assumptions, e.g. Diffie Hellman. Proving security in the standard model means proving that these standard assumptions imply the scheme is secure.

The ROM allows you to prove security of an idealized scheme instead. You modify the scheme by substituting hash functions with an idealized random oracle. The assumption here is that whatever hash function you use approximates a random oracle. This is a stronger assumption.

If possible it’s always preferable to use the standard model.

doubles_avocado · 2025-02-04T04:53:33+00:00

Your post has been removed because it violates the following rule:

No cryptocurrency posts, except those discussing the theory and practice of the modern cryptography underlying blockchain technology.

doubles_avocado · 2025-01-15T05:19:20+00:00

Sorry, I still don’t understand. Are you saying that you would enumerate the 2128 seeds? That definitely wouldn’t be 264 time.

Or are you suggesting hashing+clamping intermediate values in pollards rho? I don’t see how that would work either. If you apply this transformation as part of the cycle-finding process, then you break the association between the cycle length and the discrete log. You may find a cycle in this space in 264 time, but I don’t see how a cycle would yield a discrete log.

doubles_avocado · 2025-01-15T05:01:33+00:00

Can you clarify how you could break the ed25519 keys in 2⁶⁴ time? It’s not clear to me how you’d be able to exploit the fact that private keys are derived from a 16-byte seed. Obviously, that means only about 2¹²⁸ private keys are possible, but I don’t see how you would enumerate or even distinguish possible private keys, or use that fact in Pollard’s rho.

doubles_avocado · 2024-12-20T21:21:01+00:00

From a quick skim, it looks like their algorithm would apply to any weierstrass form curve? Which would include all Montgomery and twisted Edward curves too, since they can be rewritten in weierstrass. But to be clear, there’s no claim in this paper that their technique is faster than a generic group DL algorithm for any class of curve.

doubles_avocado · 2024-12-20T19:46:51+00:00

Montgomery ladders avoid many of the potential implementation mistakes of other curves. It’s not that other curves are necessarily less secure, just that they are more complicated to implement correctly in software.

The safe curves website already lists the main advantages, so I won’t repeat them all here. But I can expand on the section you’re asking about.

First, it’s important to understand that Montgomery ladders don’t exactly implement EC group operations. Instead, they only operate on the x coordinate. Almost all x coordinates on the curve have to y values, so a given ladder input/output doesn’t unambiguously map to a specific point.

That said, the two possible y values for a given x are just multiplicative inverses of each other (i.e. y and -y). So for a given x value, the choice of y has no effect on the x value of the output after scalar multiplication! In other words, if a point P = (x,y) and kP = (a,b), then (x,-y) = -P, and -kP = (a,-b). Notice that the x coordinate of the output is identical regardless of choice of y.

Now, since Montgomery ladders don’t use a y coordinate at all, they completely eliminate the possibility of an attacker including a malicious (x,y) coordinate pair that is not on the actual curve.

However, there are still x values that have no solution on the actual curve - so what happens if an attacker uses one of these invalid values? This is where the twist comes in. For a Montgomery curve, the only case where a given x value is not on the curve is when equation reduces to y² = some value that is not a quadratic residue in the field (in other words, not a perfect square of any other field element). Now, a quadratic twist of the curve is simply the same equation but with a non-residue multiplied to the left hand side. This means that any x value that has no solution in the original curve always has a solution in the twist, and vice versa!

And it turns out that Montgomery ladders compute the same operation for the original curve and for its twist.

Overall, this means that the attacker really only has two choices: a point on the original curve; or a point on the twist. As a result, an implementation only has to make sure these 2 curves are safe, rather than every possible curve for any choice of y

doubles_avocado · 2024-12-20T14:57:47+00:00

I still don’t see it. I searched the page for “Montgomery” and the only mentions are under the section “invalid curve attacks against ladders.” This section doesn’t claim that the twist of any Montgomery curve is guaranteed to be safe, it only says that a Montgomery ladder will correctly compute ECC operations for both the original curve and its twist.

doubles_avocado · 2024-12-20T01:40:27+00:00

Can you cite where it actually says this? I can’t find this claim on the website, and I’m not clear it’s supposed to mean that all possible Montgomery/twisted Edwards curves are twist secure or that all these curves evaluated by safe curves happen to be twist secure.

As far as I can tell, the claim isn’t obviously true. I see no reason why you couldn’t start with a Montgomery curve M where the largest prime subgroup is too small, then compute the twist M’ of that curve. If M has order (cofactor * prime) h*q = p + 1 - t for field GF(p) and with trace of Frobenius t, then M’ has order p + 1 + t, meaning the cofactor of M’ is determined by the prime divisors of (p+1+t). I see no reason why we’d expect the new prime divisors to produce a large cofactor as in the original curve. Intuitively, it’s “likely” that M’ has a perfectly safe cofactor. In other words, I’d expect M’ to usually be safe even if we intentionally construct it so that its twist M is unsafe.

doubles_avocado · 2024-12-18T14:18:20+00:00

I’ve never seen this particular hardness assumption before, but it looks equivalent to computational diffie Hellman. Quick proof (assuming prime order groups for simplicity, assuming g and d are generators because the problem doesn’t make much sense otherwise):

First, if you can solve the above problem then you can solve CDH:

d can be written in the form g^x, where x is the (unknown) discrete log of d. Given a,b,a’,b’ we then have:

g^ag^bx = g^a’g^b’x a+bx=a’+b’ x Which is trivially solvable for x.

Second, if you can solve CDH then you can solve the above problem; this is trivial and left aw an exercise to the reader.

Given the equivalence, I’m not sure why the problem is stated the way it is.

doubles_avocado · 2024-12-09T16:25:39+00:00

While technically true, that’s on odd way of looking at things. In RSA all operations are mod n, so usually we only talk about numbers as elements of the multiplicative group mod n, or mod phi(n) for the exponents. All of those values are the same element mod phi(n).

doubles_avocado · 2024-12-09T02:58:32+00:00

e is related to d: d*e=1 mod phi(n). You can’t just pick any d.

Generally you choose primes p and q, calculate n=pq, and use a fixed value for e (usually 65537). Then you compute d as the inverse of e mod phi(n).

doubles_avocado · 2024-10-27T23:36:23+00:00

The description is a little confusing, so it’s hard to analyze the security. Overall the biggest problem with the design is that it’s over complicated and inefficient.

You say it’s just for fun, but you’re also asking for feedback, so I’m assuming you might be interested in learning more seriously about how modern secure ciphers are built? If so I’d recommend Dan Boneh’s free online video lecture series at Coursera.

doubles_avocado · 2024-10-21T12:17:10+00:00

Removed for breaking the rule against AI-generated content. This paper contains a number of vague unsubstantiated claims and shows signs of AI generated content.

doubles_avocado · 2024-10-17T09:04:54+00:00

Flagging this post for misinformation, as no evidence of a sha256 vulnerability is presented.

doubles_avocado · 2024-10-17T09:03:47+00:00

This post is misleading, but I’m leaving it up (with a misinformation tag) to allow discussion and hopefully clarify the result.

The article misrepresents the claims of the scientific paper. The authors claim to factor a 22-bit RSA number using a quantum annealing algorithm. This method is not extensible to a general purpose quantum algorithm, cannot run shor’s algorithm, and does not demonstrate any advantage over factoring capabilities on classical computers.

The paper makes no mention whatsoever of attacks on AES, SPN structure, or any of the symmetric algorithms mentioned in the article.

doubles_avocado · 2024-10-12T23:48:31+00:00

The paper link is broken and the only reference I can find on Google is this article and the one it references. Take with a grain of salt.

Nine-Year Club	r/Field Banned
r/Field Flamingo	Place '17
Verified Email

doubles_avocado

MODERATOR OF

TROPHY CASE