[{"content":"","permalink":"https://raghavendranest.github.io/topics/basic-cryptography/","summary":"","title":"Basic Cryptography"},{"content":"","permalink":"https://raghavendranest.github.io/topics/basic-mpc/","summary":"","title":"Basic MPC"},{"content":"Suppose Raghavendra wants Pratik to compute a function $f(x)$ on his secret input $x$. The obvious naive method could be to send $x$ to Pratik who can then compute $f(x)$. What Raghavendra really wants is something slightly strange: Pratik should learn the result of the computation without necessarily learning the input to the computation.\nCan we somehow transform $x$ into another object that contains enough information to recover $f(x)$, but not enough information to recover $x$? This is the idea behind a randomized encoding.\nWhat if Raghavendra could instead send a randomized encoding of $x$ that Pratik can evaluate, while learning essentially nothing about $x$ beyond the answer $f(x)$? That is the basic idea behind a \\textbf{randomized encoding}.\nEncoding a Function Let\n$$ f : \\mathcal{X} \\to \\mathcal{Y} $$be the function Raghavendra wants to compute.\nInstead of sending $x$ directly, Raghavendra samples some fresh randomness $r$ and computes\n$$ \\widehat{x} \\gets \\mathsf{RE}(f,x;r), $$where $\\mathsf{RE}$ is a randomized encoding algorithm.\nHe sends only $\\widehat{x}$ to Pratik.\nThe encoding is constructed so that there is a decoder $\\mathsf{Dec}$ satisfying\n$$ \\mathsf{Dec}(\\widehat{x}) = f(x). $$So the picture is\n$$ x \\quad\\xrightarrow[\\text{randomness }r]{\\mathsf{RE}(f,\\cdot)} \\quad \\widehat{x} \\quad\\xrightarrow{\\mathsf{Dec}}\\quad f(x). $$Raghavendra knows $x$.\nPratik receives only $\\widehat{x}$.\nPratik can recover the answer $f(x)$, but the encoding is supposed to conceal the input $x$. But what does \u0026ldquo;conceal\u0026rdquo; actually mean?\nThat is where the interesting part begins.\nFirst, the encoding must preserve the computation.\nCorrectness A randomized encoding is correct if $$ \\Pr\\left[\\mathsf{Dec}(\\mathsf{RE}(f,x;r)) = f(x)\\right] \\geq 1-\\negl(\\lambda). $$ But correctness alone says nothing about privacy.\nFor example, Raghavendra could simply send\n$$ \\widehat{x}=x. $$Pratik could then compute $f(x)$ perfectly. But he also learns everything about $x$. So we need another property that is privacy.\nPrivacy The encoding should reveal no useful information about $x$ beyond what is already revealed by $f(x)$.\nThis is captured using a simulator. Imagine a simulator that does not know $x$. It only knows the output $f(x)$.\nIf the simulator can produce something that looks indistinguishable from a real randomized encoding, then the encoding cannot be revealing useful additional information about $x$.\nThe idea is:\n$$ \\boxed{ \\mathsf{RE}(f,x) \\quad\\approx_c\\quad \\mathsf{Sim}(f(x)) } $$The left-hand side is the real encoding. The right-hand side is something generated using only the output.\nPrivacy A randomized encoding is private if there exists an efficient simulator $\\mathsf{Sim}$ such that\n$$ \\mathsf{RE}(f,x) \\approx_c \\mathsf{Sim}(f(x)), $$where $\\approx_c$ denotes computational indistinguishability.\nThe simulator receives $f(x)$ but does not receive $x$.\nThis is the familiar simulation paradigm from cryptography. Instead of proving directly that the adversary cannot learn something from the encoding, we show that whatever the adversary sees could have been generated using only the information it is supposed to learn.\nWhat does the encoding actually hide? It is important to phrase the privacy guarantee carefully. A randomized encoding does not necessarily hide $x$ completely. It cannot hide information that $f(x)$ itself reveals. This also gives an equivalent way to view the guarantee.\nSuppose two inputs $x$ and $x'$ produce the same output:\n$$ f(x)=f(x'). $$Then both real encodings must be indistinguishable from the same simulated distribution. Consequently,\n$$ \\mathsf{RE}(f,x) \\approx_c \\mathsf{RE}(f,x'). $$In other words, from the encoding alone, an efficient observer should not be able to tell apart two inputs that the function itself treats identically.\nWe can now put the pieces together.\nDefinition — Randomized Encoding Let\n$$ f:\\mathcal{X}\\to\\mathcal{Y} $$be a function.\nA randomized encoding of $f$ consists of a randomized encoding algorithm $\\mathsf{RE}$ and a decoding algorithm $\\mathsf{Dec}$.\nFor an input $x$, the encoder produces\n$$ \\widehat{x} \\gets \\mathsf{RE}(f,x;r). $$It satisfies:\nCorrectness. $$ f(x) \\geq 1-\\negl(\\lambda). $$Privacy.\nThere exists an efficient simulator $\\mathsf{Sim}$ such that\n$$ \\mathsf{RE}(f,x) \\approx_c \\mathsf{Sim}(f(x)). $$ The two properties capture the entire philosophy:\n$$ \\boxed{ \\text{Correctness: recover }f(x) } $$and\n$$ \\boxed{ \\text{Privacy: reveal nothing beyond }f(x). } $$The first says that the encoding preserves the computation. The second says that the encoding does not expose the input unnecessarily.\nMultiple Parties with Inputs From one secret input to many. So far, there is only one secret input: $x$.\nNow imagine that the input itself is distributed among several parties. Suppose Raghavendra, Pratik, and Sita hold\n$$ x_1,\\qquad x_2,\\qquad x_3 $$respectively.\nThey want to compute\n$$ f(x_1,x_2,x_3) $$without simply revealing their individual inputs to one another. This is the setting of secure multiparty computation (MPC). At a high level, the goal is now:\n$$ \\boxed{ \\text{private inputs} \\quad\\longrightarrow\\quad \\text{compute }f \\quad\\longrightarrow\\quad \\text{learn the permitted output} } $$Randomized encodings provide one useful way of thinking about how a computation can be represented while hiding private inputs that the computation does not need to reveal.\nBut moving from\n$$ \\mathsf{RE}(f,x) $$to a setting where\n$$ x=(x_1,\\ldots,x_n) $$is distributed across different parties is where the real cryptographic questions begin. Who constructs the encoding? What does each party send? Who evaluates it? What does each party learn? How many rounds of communication are necessary? And what happens if one of the parties is malicious?\nThose are questions for another post.\nSummary The main idea to take away is simple:\nA randomized encoding lets you reveal the result of a computation without revealing the input itself. After this post, the key picture to remember is\n$$ x \\quad\\longrightarrow\\quad \\widehat{f(x)} \\quad\\longrightarrow\\quad f(x), $$where the encoding reveals no useful information about $x$ beyond what is already revealed by $f(x)$.\n","permalink":"https://raghavendranest.github.io/posts/randomized-encoding/","summary":"\u003cp\u003eSuppose Raghavendra wants Pratik to compute a function $f(x)$ on his secret input $x$. The obvious naive method could be to send $x$ to Pratik who can then compute $f(x)$. What Raghavendra really wants is something slightly strange: Pratik should learn the result of the computation without necessarily learning the input to the computation.\u003c/p\u003e","title":"Randomized Encoding"},{"content":"Everyone learns Diffie–Hellman as a party trick with paint colours. The trick is fine. What it hides is that the security of the protocol does not rest on the discrete logarithm problem, and the gap between the two matters in practice.\nThe protocol Fix a cyclic group $G$ of prime order $q$ with generator $g$. Alice draws $a \\gets \\Z_q$ and sends $g^a$; Bob draws $b \\gets \\Z_q$ and sends $g^b$. Each computes\n$$ K = (g^b)^a = (g^a)^b = g^{ab}. $$That is the whole protocol. An eavesdropper sees $(g, g^a, g^b)$ and wants $g^{ab}$.\nThree assumptions, not one It is tempting to say \u0026ldquo;this is secure because discrete log is hard.\u0026rdquo; That is the weakest of the three relevant statements, and it is not the one we need.\nDefinition 1 — Discrete Log (DL) Given $(g, g^a)$ for $a \\gets \\Z_q$, output $a$. The problem is hard if for every efficient $\\mathcal{A}$, $$\\Pr\\!\\left[\\mathcal{A}(g, g^a) = a\\right] \\le \\negl(\\lambda).$$ Definition 2 — Computational Diffie–Hellman (CDH) Given $(g, g^a, g^b)$, output $g^{ab}$. Hard if $$\\Pr\\!\\left[\\mathcal{A}(g, g^a, g^b) = g^{ab}\\right] \\le \\negl(\\lambda).$$ Definition 3 — Decisional Diffie–Hellman (DDH) Distinguish $(g, g^a, g^b, g^{ab})$ from $(g, g^a, g^b, g^c)$ for $a, b, c \\gets \\Z_q$. Hard if $$ \\begin{aligned} \\Adv^{\\mathsf{ddh}}_{G}(\\mathcal{A}) = \\Bigl|\\; \u0026\\Pr\\!\\left[\\mathcal{A}(g, g^a, g^b, g^{ab}) = 1\\right] \\\\ \u0026\\;-\\; \\Pr\\!\\left[\\mathcal{A}(g, g^a, g^b, g^{c}) = 1\\right] \\;\\Bigr| \\;\\le\\; \\negl(\\lambda). \\end{aligned} $$ The implications run one way only:\n$$ \\text{DDH hard} \\;\\Longrightarrow\\; \\text{CDH hard} \\;\\Longrightarrow\\; \\text{DL hard}. $$Each arrow is easy — solve the harder-to-break problem and you break the easier one. Neither converse is known to hold in general, and the first one provably fails in some groups. That failure is the practical point of this post.\nWhere DDH breaks and CDH survives Take an elliptic curve group equipped with an efficiently computable bilinear pairing $e : G \\times G \\to G_T$ satisfying\n$$ e(g^x, g^y) = e(g, g)^{xy}. $$Now DDH is trivial. Given a candidate tuple $(g, g^a, g^b, g^c)$, just check whether\n$$ e(g^a,\\, g^b) \\overset{?}{=} e(g,\\, g^c), $$which holds exactly when $c \\equiv ab \\pmod q$. No hardness assumption survives that. CDH, meanwhile, is still believed hard in these groups — the pairing lets you verify a Diffie–Hellman tuple without letting you produce one.\nGroups like this have a name: gap Diffie–Hellman groups, where the decisional problem is easy and the computational one is hard. Far from being a defect, this gap is exactly what BLS signatures are built on.\nSo which one does the protocol need? If you want the shared secret $g^{ab}$ to be unguessable, CDH suffices. If you want to feed $K$ straight into a stream cipher and claim the keystream is indistinguishable from random, you need DDH — because you are asserting that $g^{ab}$ looks like a uniform group element, which is precisely the decisional statement.\nReal protocols dodge the question. Rather than using $g^{ab}$ as a key directly, they hash it:\n$$ K = \\mathsf{KDF}(g^{ab}). $$In the random oracle model this drops the requirement back to CDH, since an adversary learns nothing about $\\mathsf{KDF}(g^{ab})$ without querying the oracle on $g^{ab}$ itself. This is one of the honest, load-bearing uses of the random oracle model, and it is why every deployed key exchange runs its shared secret through a KDF.\nConcrete parameters Index calculus attacks the multiplicative group of $\\F_p$ in subexponential time $L_p[1/3, 1.923]$, while the best generic attack on a well-chosen elliptic curve group of order $q$ is Pollard rho at $O(\\sqrt{q})$. Hence the size gap:\nSecurity level Finite field $\\F_p^\\times$ Elliptic curve 112-bit 2048-bit $p$ 224-bit $q$ 128-bit 3072-bit $p$ 256-bit $q$ 192-bit 7680-bit $p$ 384-bit $q$ 256-bit 15360-bit $p$ 512-bit $q$ A sanity check on the elliptic curve column — Pollard rho on a 256-bit group needs roughly $\\sqrt{2^{256}} = 2^{128}$ operations:\nfrom math import log2 def rho_cost(bits: int) -\u0026gt; float: \u0026#34;\u0026#34;\u0026#34;log2 of expected Pollard rho operations for a group of given bit size.\u0026#34;\u0026#34;\u0026#34; return bits / 2 for b in (224, 256, 384, 512): print(f\u0026#34;{b}-bit group -\u0026gt; 2^{rho_cost(b):.0f} operations\u0026#34;) What to take away Writing \u0026ldquo;secure under the Diffie–Hellman assumption\u0026rdquo; is not a complete sentence. There are at least three assumptions wearing that name, they are not equivalent, and in pairing-friendly groups the strongest of them is simply false. Say which one you mean.\nNext: why the small-subgroup check you skipped is not optional.\n","permalink":"https://raghavendranest.github.io/posts/diffie-hellman-and-what-it-actually-assumes/","summary":"\u003cp\u003eEveryone learns Diffie–Hellman as a party trick with paint colours. The trick is\nfine. What it hides is that the security of the protocol does not rest on the\ndiscrete logarithm problem, and the gap between the two matters in practice.\u003c/p\u003e","title":"Diffie–Hellman and What It Actually Assumes"},{"content":"","permalink":"https://raghavendranest.github.io/activities/","summary":"","title":"Activities"},{"content":"About I work on cryptography at the CrIS Lab, Department of Computer Science and Automation, IISc Bengaluru. Most of what I write here is the long version of something I had to work out slowly — the notes I wish had existed when I was first reading the material.\nMost posts assume comfort with undergraduate algebra and probability. Where a proof matters I write it out rather than gesture at it, and where I am unsure, I say so. Corrections are always welcome.\nGet in touch Happy to hear from you — about the writing here, research, collaboration, or photography.\nRnsvernekar@gmail.com \u0026#43;91 80801 10967 LinkedIn Google Sites page Send a message The form is not connected yet. Add your Web3Forms access key under [params.contact] in hugo.toml to switch it on. ","permalink":"https://raghavendranest.github.io/contact/","summary":"\u003ch2 id=\"about\"\u003eAbout\u003c/h2\u003e\n\u003cp\u003eI work on cryptography at the CrIS Lab, Department of Computer Science and\nAutomation, IISc Bengaluru. Most of what I write here is the long version of\nsomething I had to work out slowly — the notes I wish had existed when I was\nfirst reading the material.\u003c/p\u003e","title":"Contact"},{"content":"A collection of moments, places, and random things that seemed worth pointing a camera at.\n","permalink":"https://raghavendranest.github.io/gallery/","summary":"\u003cp\u003eA collection of moments, places, and random things that seemed worth pointing a camera at.\u003c/p\u003e","title":"Photographs"},{"content":"Preprints are linked wherever the venue permits it.\n","permalink":"https://raghavendranest.github.io/publications/","summary":"\u003cp\u003ePreprints are linked wherever the venue permits it.\u003c/p\u003e","title":"Publications"}]