Talk:Rabin cryptosystem

• Article: de:Rabin-Kryptosystem (merge into our stubby Rabin cryptosystem)
• Corresponding English-language article: merge into our stubby Rabin cryptosystem
• Originally Requested by: — Matt 18:12, 27 Jul 2004 (UTC)
• Status: Mpolo 07:49, Oct 3, 2004 (UTC)
• Other notes: Math should be checked. I have an M.A., but that was long, long ago....

Only the signature, not encryption is as secure as integer factorization

If the message m squared m*m is smaller than n, since m can be calculated as the square root (without remainder) independend of n, p and q. In such a case the encryption is not secure at all. 109.90.224.162 (talk) 15:04, 21 September 2015 (UTC)

How do you compute square roots of very large integers? How do you even decide if it is a square? — Preceding unsigned comment added by 2A02:8109:D3F:E9A4:5928:4A75:2880:DD7E (talk) 19:46, 29 July 2017 (UTC)

This code will find the square root of a perfect power, which the algorithm as described in this article is. Note that Rabin's original paper does not say $m^{2}{\pmod {n}}$.

def perfect_power(n):
    """
                           b                                                    2
    Determine whether n = a using binary search, should require O(lg n (lg lg n) ) time.
    """
    logN = int(lg(n)) + 1
    for b in range(2, logN):
        low  = 2
        high = 1 << logN // b + 1
        while low < high - 1:
            middle = (low + high) // 2
            ab = power(middle, b)
            if ab > n:
                high = middle
            elif ab < n:
                low = middle
            else:
                return (middle, b)
    return (None, None)

Rabin's original paper (https://apps.dtic.mil/sti/pdfs/ADA078415.pdf)

Evaluation , a proposal

As discussed in other sections of this discussion page, it is not exactly clear, why a chosen ciphertext attack should break the Rabin Cryptosystem.
To shed some light on what Michael Rabin wrote in his original paper and what exactly the problem is, I propose to include a subsection under "Evaluation", which explains how finding square roots is connected to factoring the public key. I propose to use an example based on the two prime numbers "p=19","q=23","n=p*q=323". Rough outline:

• Start with "k*k = s mod n", that means that "k" is one of the square roots of "s".
• "n-k" is another square root of "s", because "(-k)*(-k) = s mod n". So "-k = n-k mod n" is the second square root of "s".
• Now from Rabins paper we know, that there has to be another number "h", with "h != k mod n" and "h != -k mod n", so that "h*h = s mod n".
  This "h" is the third square root of "s".
• "-h" is the fourth square root of "s".
• Rabin shows that if you can find two square roots "k" and "h", with "h != k mod n" and "h != -k mod n", then you can very easily calculate "p" and "q", because:
  either "gcd(k-h,n) = p" or "gcd(k-h,n) = q". (gcd here means Greatest common divisor).
• Example: "p=19,q=23,n=p*q=437". "s=233", "k=200, -k=237", "h=85, -h=352". (Simple check: "k*k mod n = 200*200 mod 437 = 233 = s")
  "k-h=200-85=115", "gcd(115,437) = 23 = q", voila we found one of the two prime factors.
• Consequences:
  • Any attacker can create pairs of "k" and "s": Simply randomly generate a "k" and calculate "s = k*k mod n" ("n" is public).
  • If an attacker can additionally find "h" with "h != k mod n" and "h != -k mod n", the attacker is able to find "p" and "q".
    This is exactly what Rabin proves in his paper: Finding square roots "mod n" is as hard as factoring "n", because if you have the square roots you can efficiently calculate the prime factors of "n". Note: This of course applies to any cryptosystem, which relies on the assumption that factoring is hard (like for example this also applies to RSA).
  • What has to be avoided at all costs is, that the owner of the private key ("p" and "q") calculates such a "h" ("h*h = s mod n, h != k mod n, h != -k mod n") and sends it back to the attacker. If this should ever happen, the attacker can easily calculate "p" and "q" as shown before.
  • Possible threat: There exist "h" for which "h*h = s" with "1<=s<n" (important here, no "mod n"!). You can calculate "h" from "s" easily in this case (simple integer square root algorithm). When using Rabins Cryptosystem for signatures the signer should make sure that the signature "k", with "k*k = s mod n" does not produce a "s" which has an integer square root; of course the probability that this ever happens is minuscule and can be easily avoided completely. Again all this applies to any cryptosystem based on prime factors: An attacker can always create a huge amount of random "k*k = s mod n" pairs and check if "s" has an integer square root; this is just a randomized way to factor "n".

In my opinion the last two points are, why some people seem to say that Rabins Cryptosystem is vulnerable. But of course this is only true, if you construct the protocol in such a way, that the owner of the private key does send back the critical "h" square root. This can be easily avoided or at least I really cannot think of any scenario in which it cannot be avoided. Of course in a way this means that Rabins Cryptosystem is more "sensitive" (lack of a better word) in a manner than RSA:

• Rabin: If you have a "ciphertext(s) <-> plaintext(k)" pair, then there exists an alternative "plaintext(h)" which MUST NOT be revealed by the owner of the private key. (Revealing a stand-alone "ciphertext(s) <-> plaintext(k)" pair DOES NOT break anything!).
• RSA: There are only pairs of "ciphertext <-> plaintext" and no alternative "plaintext" exists. Revealing such a "ciphertext <-> plaintext" pair does not break anything.

Note under the "Security" section it says that: "(This assumes that the plaintext was not created with a specific structure to ease decoding.)". If you read what I wrote above, this quote is nonsense: ANY plaintext "k" (regardless of structure) produces a ciphertext "s" with "s = k*k mod n". If an attacker can find the an alternative plaintext "h", so that "h != k mod n" and "h != -k mod n", the cipher has been broken; this is true for ALL plaintexts "k", so why has that anything to do with the structure of the plaintext ? Lundril (talk) 13:26, 14 September 2011 (UTC)

Rabin for signatures, and Blum-Williams modification

Rabin cryptosystem is not a permutation, so there may be issues when used for pubkey encryption, but there should not when used in signature schemes. Can somebody write something about this?

answering to myself... Ok, Rabin is totally insecure as a signature scheme under CCA. —Preceding unsigned comment added by 85.124.63.18 (talk) 23:03, 21 January 2009 (UTC)

Also, Blum and Williams have suggested to use primes p and q which are both equivalent to 3 mod 4, in which case the solution is unique, i.e. the scheme becomes a permutation. Can somebody write something about this as well?

Thanks, 141.201.123.144 (talk) 14:44, 19 January 2009 (UTC)

Security

The security stuff on this page is definitely wrong -- appropriate padding makes Rabin stronger, not less strong. I'll try and fix it when I have time ciphergoth 10:26, 2004 Nov 16 (UTC)

It's been fixed, I think. —Lowellian (reply) 01:50, 15 March 2006 (UTC)

From the page:

By adding redundancies, for example, the repetition of the last 64 bits, the system can be made to produce a single root. This thwarts the chosen-ciphertext attack, since the decoding algorithm then only produces the root that the attacker already knows. If this technique is applied, the proof of the equivalence with the factorization problem fails, so it is uncertain as of 2004 if this system is secure.

This is not followed by a reference and I think it is simply not true ? As far as I understand the proof of the equivalence with the factorization problem (I read the original paper), the equivalence simply means: If someone is able to compute FOUR square-roots from only a single number, then from these FOUR square-roots, you can factorize "n". Now "n" is public; so an attacker ALWAYS will know "n". So how would an attacker break the system by Chosen Ciphertext Attack: He would repeatedly give the decryption oracle a ciphertext which was simply created by choosing a random number X and then calculating "X*X mod n".So the attacker already knows two square roots of "X*X" (X itself and N-X), if the decryption oracle gives him a third square root Y (so that Y*Y=X*X mod n), then the attacker knows all four square-roots and thus can factor "n".

I do not see at all why putting redundancies in "X" (the number from which the cipher text X*X mod n is created) does have anything to do with the equivalence to factorization. It simply means an attacker will always get back X instead of Y. The equivalence to factorization is not touched by that fact. It also means that an attacker cannot chose X arbitrarily any more, so it puts constraints on the attacker. I completely fail to see why this should weaken the cipher.

I also find it strange that people seem to have some bad feelings about putting redundancy in X. If you use RSA with 2048 to encrypt a message, the message (in current crypto systems) usually is a symmetric key comprised of something like 256 bits. For encrypting this key, first a number with 2048 bits is produced by padding the 256 bits with something like Optimal Asymmetric Encryption Padding. So RSA also uses padding, so why does it seems to be a problem for Miller Rabin encryption to use some padding in X to introduce some redundancies ?

A comment about costs: It is claimed that because the decryption algorithm needs to calculate four square roots that decryption introduces additional costs. Well yes, but these "costs" are completely marginal when compared to the costs you need to find the square roots "mod p" and "mod q" or compared to calculating the logarithm "mod n" for RSA: Generating the four square roots takes 4 additions/subtractions "mod n", speaking of "additional costs" gives the impression that these costs are high and this is simply wrong... 92.194.229.8 (talk) 11:14, 6 June 2009 (UTC)

I can only totally agree to that analysis. I really would like to see that paper that says that rabin cryptosystem is insecure against chosen ciphertext attacks. This really only applies if you implement it in a fairly dumb manner (oracle which for a given ciphertext produces the four square roots and then RANDOMLY selects one of the square roots and sends it back to the attacker). For non-signature applications (like exchange of a symmetric key for setup of a secure communcation channel) this really is NO problem at all, because the sender (the one which encrypts by using the public key) simply can be forced to additionally send proof of the secret (like for example a hash key of the secret) and the decrypting entity will simply check which square root was used by checking the proof.
For signature applications the problem is more complicated, because in this case the decrypter needs to proof that it is able to generate square roots by providing one for a cipher text which is generated out of the data which should be signed. But still it is not clear how an attacker could use that: In the signature scenario the decrypter has TONS of freedom how exactly it proofs that it can calculate square roots. The DECRYPTER (and not the attacker) has full control over the signature process, so it is completely unclear how an attacker should be able to lure the decrypter into providing useful information...
You really get the feeling that rabin cryptosystem is dismissed for completely different reasons (marketing; RSA is patented and probably some people pay license fees.) — Preceding unsigned comment added by 92.194.141.107 (talk) 01:01, 14 September 2011 (UTC)

I disagree. Section 7.2.4 of the lecture notes by Goldwasser and Bellare confirms the quote from the article. There Goldwasser and Bellare explain that adding sufficient redundacy to the plaintext before encrypting it, has the consequence that proof of equivalence of the cryptosystem and factoring no longer works. Concretely, the section concludes with

"Therefore, either Rabin's scheme is not equivalent to factoring, which is the case when inverting on a sparse message space, or (when M is not sparse) it is insecure before a chosen ciphertext adversary."

First of all is there any way to point a reader of the article to this section ?
I just read the section and I think it would help if the argument would be repeated in a more readable fashion in the article:
Let me try to explain: Rabin proved that if you can calculate the four square roots of a single arbitrary number "c" (the ciphertext == encrypted message), then you can factorize n (the public key). Now if you limit the message space (by enforcing certain patterns in the message), then it might be that for this particular message space an adversary can decrypt ciphertext, but is still not able to factor the public key; so if you limit the message space, then decrypting might not be as hard as factoring. A trivial example: We have an N (public key) with 1024 bit and we limit the message space to numbers "0 .. 2^400-1" (so numbers with a length of 400 bit maximum). The ciphertext "c = m*m mod n" will have at most 800 bit (since m is at most a 400 bit number) meaning that you never actually did any modulo operation. An adversary has to find the integer square root of your 800 bit ciphertext. Calculating integer square roots is easy, so an adversary can easily reverse the encryption and will still not be able to factorize "N". Conclusion: If you enforce certain patterns on the message to be encrypted, then it is not clear that decrypting is as hard as factoring.
My problem with this whole argument: There is a much better way. Instead of enforcing a pattern on the message, enforce that the encrypter additionally has to send a cryptographic hash of the message along with the ciphertext. With this approach decrypting is as hard as factoring and you defeat chosen ciphertext attacks. Lundril (talk) 18:20, 15 September 2011 (UTC)

Of course, the chosen ciphertext attack can be prevented by chosing an appropriate padding scheme, though like RSA this is not completely trivial. E.g. the proposal above to append a hash of the encrypted message loses semantic security and thus is not appropriate. Claims what constitutes a good padding scheme should therefore come with a citation, this discussion page is not the right place to argue that a certain padding is not susceptible to an attack. 62.202.80.11 (talk) 00:55, 15 September 2011 (UTC)

I did not mean padding. I meant encrypt your message (without padding), and additionally to the ciphertext you must send a cryptographic hash of your unencrypted message (cleartext). This kind of step is not necessary with RSA, because RSA is a 1-to-1 mapping whereas Rabin is a 4-to-1 mapping. The chosen ciphertext attack against Rabin as far as I can tell works like this:

1. You enforce a certain pattern on the message to be encrypted to make sure, that the decrypter can pick the right square root.
2. A lot of messages have to fit that pattern (otherwise it is not clear that decryption is equivalent to factoring).
3. You have an oracle to which you can send ciphertext and it will return the decrypted message (provided there is a decrypted message, which fits the enforced pattern).
4. An attacker randomly produces ciphertext, by picking a message which does NOT fit the pattern and encrypting it (c=m*m mod n).
5. The oracle tries to decrypt the ciphertext.
6. Since there ar many messages which fit the enforced pattern, after a reasonable amount of time the attacker will find a ciphertext for which the oracle produces the decrypted answer.
7. With this decrypted answer (second pair of square roots), the attacker is able to reproduce the private key (p,q).

By enforcing that a sender must additionally send a cryptographic hash of the unencrypted message, this attack is thwarted and you do not need to put any constraints on the message (which would prevent equivalency to factorization). To reproduce the private key, an attacker would have to

1. pick a number "x", generate ciphertext "c = x*x mod n"
2. generate a cryptographic hash "h", which fits to the unknown alternative square root "y".
3. Ask the oracle to decrypt "c"
4. The oracle produces "y" and answers because "h" fits "y".
5. The attacker can now reproduce the public key (p,q)

The question is how should an attacker be able to produce the cryptographic hash "h" ?
The whole chosen ciphertext against Rabin stuff only works under the assumption that an oracle will produce answers to a given ciphertext with high probability. And yes: It is pretty easy to prevent this. BTW: If anybody suddenly suggests this scheme of adding a cryptographic hash of the unencrypted message: I proposed it first :-). Lundril (talk) 18:55, 15 September 2011 (UTC)

Duplicate

It appears that this article is duplicated on the Rabin-Williams encryption page. I suggest that the best parts of each of the explanations be taken to form a single article and a redirect be made from the redundant page. Which page becomes the redundant page depends on which name is most appropriate. Does anyone know how this scheme came to be known under two names?

Worked Example

In the example given on the page, m_q = 9. By my calculations, m_q = 2.

m_q² (congruent to) c mod 11
m_q² (congruent to) 15 mod 11
m_q² = 4
m_q = 2

Apologies for poor formatting.

--Newheroicideal 15:07, 25 March 2007 (UTC)

No-one seems to object, so I changed it myself. --Newheroicideal 15:18, 2 April 2007 (UTC)

In the article square roots are computed using $m_{q}\equiv c^{(q+1)/4}{\pmod {q}}$. Thus $m_{q}\equiv 15^{3}\equiv 9{\pmod {11}}$ is the correct result. But, notice that $2\equiv -9{\pmod {11}}$. Hence 2 is the other square root of $c$ modulo 11, just not the one computed with described method. 85.2.2.33 20:33, 2 April 2007 (UTC)

Legendre Symbol

From $c\equiv m^{2}{\pmod {pq}}$ follows that c is a quadratic residue. Hence $\left({c \over p}\right)=1$

Why is this so? Doesn't seem to be correct to me after reading an article on Jacobi symbol... —Ram3ai (talk) 21:25, 17 January 2008 (UTC)

If $c\equiv m^{2}{\pmod {pq}}$ then $c=m^{2}+npq$ for some integer n. So $c\equiv m^{2}{\pmod {p}}$. reetep (talk) 11:27, 18 January 2008 (UTC)

What is 'r'

In decryption section a variable 'r' appears "out of the blue", then proabably reused by a possible solution. This proabably comes from different editors not keeping consistency. Even knowing what a Rabin scheme is, it introduces much confusion. —Preceding unsigned comment added by Janislaw (talk • contribs) 14:48, 14 January 2009 (UTC)

1 or 6?

From the article:

In our example we get $m_{p}=1$ and $m_{q}=9$.

Since we took p=7, m=20, the first remainder must equal 6 and not 1 (unless any other possible input is considered). Isn't it the case? --Microcell (talk) 19:38, 18 November 2012 (UTC)

The Python script

Python (programming language) version 2.x: http://iaktueller.de/rabin.py — Preceding unsigned comment added by 84.118.82.226 (talk) 21:54, 13 February 2018 (UTC)

That code is not Python, it is JavaScript, and does not do the encryption. It is largely an implementation of BigInt and a primality test. Miller-Rabin in particular, and not the Rabin algorithm.

As hard as factorization - I don't believe it!

Assume $m^{2}$ is smaller than $n$, then decryption is trivial. We must just calculate the ordinary square root without modulo, since the ${\bmod {n}}$ operation has no effect.

But we may add a large hash function to the message $m$ so that $m^{2}$ is much larger than $n$. The Clou -

decryption becomes unique.

The density of squares as compared to primes

The Prime Number Theorem says that the density of primes smaller or equal $n$ is $1/ln(n)$. The density of square numbers is $1/n$ which is much smaller for large numbers.

As consequence a random number $r>=2^{512}$ has only a probability smaller than ${\frac {1}{2^{256}}}$ of being a square number. We can conclude, that the rabin signature is secure for hash function values larger or equal than $2^{512}$ provided that integer factorization is hard.

Hmmmm - yes the signature of a random message can not be forged, since it very likely that with n larger than $2^{1024}$ a random message is much larger than $2^{512}$. Ok, so we can add for example a 1024 bit random value to the message and sign this sum instead of the original message. If we include the random value in the signature, it is perfect.

--84.118.82.226 (talk) 17:49, 16 February 2018 (UTC)

Expected value of 4 vs 4 tries

The following sentence in the article

>It has the disadvantage that each output of the Rabin function can be generated by any of four possible inputs;

seems unsupported by the Rabin paper - four is the expected number of attempts, but it could be much higher - am I missing something? TD-Linux (talk) 16:36, 19 September 2019 (UTC)

Yes I think you're missing something but I'm not sure exactly what the misunderstanding is. The point is that given any number k which is the encryption of a number p1, there are also exactly three other numbers p2, p3 and p4 which also encrypt to k. What part of the Rabin paper do you think contradicts this? Are you by chance looking at section 4 (Inversion is Equivalent to Factorization)? This demonstrates a probabilistic technique for factoring in which the algorithm is repeated an arbitrary number of times until it succeeds, but this is completely unrelated to decryption; it is part of the proof that decryption is as hard as factorization. Someone wishing to decrypt a message wouldn't use the algorithm in section 4, they would use the deterministic algorithm presented in section 2, which produces exactly 4 answers. CodeTalker (talk) 16:57, 19 September 2019 (UTC)

I'm actually looking at the signing section (section 3). I guess that sentence in the intro was referring to the decryption process, not signing process. TD-Linux (talk) 17:29, 19 September 2019 (UTC)

Ah I see. Yes, the mention of 4 tries in the signature algorithm is unrelated to the fact that each encrypted message has 4 possible decryptions. This article discusses only encryption and decryption. There should probably be a section mentioning Rabin's signature scheme as well. CodeTalker (talk) 17:56, 19 September 2019 (UTC)

Adolf Kunerth's modular square root algorithm challenges Rabin's assertion that his cryptosystem is as hard as factoring

The Rabin cryptosystem was the first asymmetric cryptosystem where recovering the plaintext from the ciphertext could be proven to :be as hard as factoring.

See Kunerth's_algorithm where a modular square root can be taken without factoring the modulus. Thus Rabin's assertion that his m^2 mod p*q is equivalent to integer factorisation since Kunerth's method does not need to factor the modulus and can do composite modula Endo999 (talk) 04:22, 6 June 2022 (UTC)

See the talk page on Kunerth's algorithm where the modular square root of 5 mod x^4+18*x^2+1 is easily taken. If the modulus, p*q, happens to be this formula and the ciphertext is 5 then the cipher can be broken within seconds, and Rabin's cryptosystem has flaws in it. Endo999 (talk) 04:31, 6 June 2022 (UTC)

I've been working with Kunerth's algorithm for 9 months now and I have not been able to get two modular square roots of the same ciphertext. The algorithm doesn't seem to do this well, so therefore, it is good at getting one modular square root of a p*q modulus, but not two (which is necessary for factorisation). There Kunerth's method can sometimes (when the associated quadratic is squared) break Rabin, without being able to factor the modulus. Endo999 (talk) 04:39, 6 June 2022 (UTC)

See Talk:Kunerth's_algorithm#Taking_the_root_of_5_mod_p*q_which_is_(x^4+18_x^2+1) for a modulus that is x^4+18x^2+1 that is a P*Q semiprime and which can have the root of 5 taken without factoring the modulus Endo999 (talk) 06:27, 6 June 2022 (UTC)

The Blum-Goldwasser cryptosystem, also a system where the modular square root is featured, may also be subject to the Kunerth challenge. See Blum–Goldwasser_cryptosystem Endo999 (talk) 14:26, 6 June 2022 (UTC)

"inverting has been mathematically proven to be as hard as factoring"

Following this edit, the introduction states:

"The Rabin trapdoor function has the advantage that inverting it has been mathematically proven to be as hard as factoring integers".

It's left untold what "inverting" exactly means. The original source MIT-LCS-TR-212 Theorem 1) makes that: "finding one of the solutions of y² ≡ m (mod n) whenever a solution exits". In the context of textbook Rabin signature (resp. encryption), m is the message (resp. ciphertext), and one of the solutions y is the signature (resp. plaintext). The "whenever a solution exits" can be loosened to: "with non-vanishing probability for random m", but not to "for some exponentially large class of m" (counterexample to the later: it's easy to invert the function for m := y² and 0≤y<√n )

One option is to change the statement "The Rabin trapdoor function has the advantage that inverting it whenever possible has been mathematically proven to be as hard as factoring integers". That's directly supported by the original article, and "whenever" points to a critical and easily overlooked limitation of the proof. Fgrieu (talk) 14:52, 23 August 2022 (UTC)

I don't think the formal details of the definition of inverting are important to expound upon in the article summary. The point is that there is some primitive mechanism that is easy to compute one way and hard the other, without secret knowledge, which is what being a trapdoor function is about, and without a factoring algorithm, which is what the security reduction is about and what makes it noteworthy compared to RSA.

Obviously if you're given a quadratic nonresidue you won't find a preimage even if you can compute square roots of quadratic residues, and obviously a function to return a square root is limited to choosing one of up to four possibilities even if restricted to quadratic residues. Same with squaring negative real numbers: colloquially it is perfectly natural to say that the square root function inverts the square function on real numbers, even if it gives only one output and doesn't work on negatives.

But this is all very detailed jargon that doesn't belong in a summary. If you want all the details, you can find them in the literature or somewhere deeper inside an article.

I'm also not citing Rabin's original articles as a source for the summary because the original articles by Rabin aren't even about encryption at all! The sources I gave (Bellare & Goldwasser's lecture notes, Galbraith's book) go into more formal detail about trapdoor function security (Theorem 2.38 of B&G) or one-way encryption security (Secs. 1.3.1 and 2.1.3 of Galbraith for definition, Sec 24.2.3 for theorems about Rabin encryption) if you really want that. Taylor Riastradh Campbell (talk) 15:35, 23 August 2022 (UTC)

On second taught, I agree to the "that doesn't belong in a summary" argument. And I'm happy with the current state of that section, and the additional details given in the security section. Fgrieu (talk) 05:39, 30 August 2022 (UTC)

Signature is not encryption with private key

@49.236.16.238 This revert reintroduced a conceptual error about encryption and signature schemes that the reverted change had fixed.

Creating a signature is not encrypting with a private key, despite pop science or lazy textbook expositions that give this misconception. Sometimes there are signature schemes and encryption schemes that use a common underlying mathematical primitive, like RSA-FDH and RSA-KEM which can both use cubing modulo a product of large secret primes but are otherwise different in just about every respect. Other signature schemes, like the hash-based SPHINCS, have no corresponding encryption scheme (in the case of hash-based schemes, they can't: Merkle puzzles are optimal).

Rabin's original paper described a signature scheme, not an encryption scheme; variants of it for encryption came later, generally with security problems rendering them useless for real-world applications and fit only for textbook examples of how not to design encryption schemes. Secure encryption schemes based on the Rabin trapdoor function (none of which appear in this article, but here's an example secure Rabin-based public-key encryption scheme) take a KEM approach that doesn't feed any plaintexts for encryption into the squaring function at all. Even the insecure textbook variants often involve padding plaintexts with redundancy, so it's ambiguous what 'encrypting' or 'decrypting' mean here even in context. For more detail, references, and history about the signature scheme, see the full article on Rabin signatures.

Describing parts of the signature scheme as 'encrypting' numbers is wrong, and saying the actual standard mathematical operation is unambiguous, so I've restored the edits which correctly describe them as squaring or finding square roots. If you still want the changes reverted, can you please discuss your reasons here? Taylor Riastradh Campbell (talk) 17:56, 7 October 2022 (UTC)