summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorChristian Grothoff <christian@grothoff.org>2021-10-06 13:29:46 +0200
committerChristian Grothoff <christian@grothoff.org>2021-10-06 13:29:46 +0200
commitbaf8df40d10ebe5748e6a909c2985fbfcf202038 (patch)
tree2b64d36678017ecc1b36760733b6458ee68440fd
parente16892070216840d1cc9b2295288a3f0d8f8e65b (diff)
downloadexchange-baf8df40d10ebe5748e6a909c2985fbfcf202038.tar.gz
exchange-baf8df40d10ebe5748e6a909c2985fbfcf202038.tar.bz2
exchange-baf8df40d10ebe5748e6a909c2985fbfcf202038.zip
-merge Stefan last-minute changes
-rw-r--r--doc/cbdc-es/cbdc-es.tex28
1 files changed, 14 insertions, 14 deletions
diff --git a/doc/cbdc-es/cbdc-es.tex b/doc/cbdc-es/cbdc-es.tex
index ee6341fa2..24a78b1ee 100644
--- a/doc/cbdc-es/cbdc-es.tex
+++ b/doc/cbdc-es/cbdc-es.tex
@@ -745,7 +745,7 @@ contratos usando firmas digitales. Para lograrlo, cuando una billetera
digital retira una moneda, primero crea una clave privada aleatoria
$c$ y calcula la correspondiente clave publica $C$ de esta moneda
para crear firmas digitales con esquemas de firma criptográfica
-regulares (como DSA, ECDSA, EdDSA, and RSA). Entonces, se deriva $f$
+regulares (como DSA, ECDSA, EdDSA y RSA). Entonces, se deriva $f$
usando una hash criptográfica de la clave pública $C$, que luego es
firmada en modalidad ciega por el banco central (usando un factor
aleatorio ciego actualizado para cada moneda). Ahora el cliente puede
@@ -817,7 +817,7 @@ privadas y los parámetros del dominio, generan sus respectivas claves
públicas $A \equiv g^{a} \mod p$ y $B \equiv g^{b} \mod p$.
Cada una de las partes ahora puede usar su propia clave privada y la
clave pública de la otra parte para calcular la clave secreta compartida
-$k \equiv \left( g \middle| b \right)^{a} \equiv \left( g^{a} \right)^{b} \equiv g^{\text{ab}} \mod p$.
+$k \equiv \left( g^b \right)^{a} \equiv \left( g^{a} \right)^{b} \equiv g^{\text{ab}} \mod p$.
\footnote{El mismo mecanismo también se podría usar para garantizar que
las monedas no se transfieran a un tercero durante el retiro. Para
lograr esto, los consumidores tendrían que salvaguardar una clave de
@@ -832,11 +832,11 @@ riesgo limitado en las transferencias a terceros al retirar monedas,
no está claro si esta mitigación sería una buena compensación.}
Para obtener el cambio (también llamado ``vuelto''), el cliente empieza
-con la clave privada de la moneda c. gastada parcialmente. Sea C la
+con la clave privada de la moneda $c$. gastada parcialmente. Sea $C$ la
correspondiente clave pública, p. ej.
$C = g^{c} \mod p$.
Cuando la moneda se gastó parcialmente, el banco central grabó en su base de
-datos la transacción en la que se incluye a C. Para simplificar, daremos
+datos la transacción en la que se incluye a $C$. Para simplificar, daremos
por sentado que existe una denominación que coincide exactamente con el
valor residual. De no ser así, se puede simplemente ejecutar
repetidamente el protocolo de cambio hasta obtener todo el cambio
@@ -859,7 +859,7 @@ $K_{i} \equiv \emph{KX}(c,t_{i})$. El protocolo de
intercambio de claves se puede usar de diferentes maneras para llegar al
mismo valor
$K_{i} \equiv \emph{KX}(C,t_{i}) = \emph{KX}(c,T_{i})$.
-Dada $K_{i}$, el cliente usa una función criptográfica hash H para
+Dada $K_{i}$, el cliente usa una función criptográfica hash $H$ para
derivar valores
$(b_{i},c_{i}) \equiv H(K_{i})$, donde
$b_{i}$ es un factor ciego válido para la clave de denominación
@@ -869,8 +869,8 @@ crear firmas criptográficas como para su futuro uso con el protocolo de
intercambio de claves (como $c$, para obtener cambio a partir del cambio).
Sea $C_{i}$ la clave pública correspondiente a $c_{i}$. El cliente
solicita entonces al banco central que cree una firma ciega sobre
-$C_{i}$ para $i \in \{ 1,\ldots,\kappa\}$. \footnote
-{Si se usara el criptosistema RSA para firmas ciegas, usaríamos
+$C_{i}$ para $i \in \{ 1,\ldots,\kappa\}$.\footnote{Si se usara el
+criptosistema RSA para firmas ciegas, usaríamos
$f \equiv \emph{FDH}_{n}(C_{i})$, donde
$\emph{FDH}_{n}()$ es el hash de dominio completo sobre
el dominio $n$.} En esta petición, el cliente también se compromete a
@@ -924,15 +924,15 @@ retirar CBDC sería como se muestra en la Figura 1.
Un cliente (1) proporciona autenticación a su banco comercial usando la
autenticación respectiva del banco comercial y los procedimientos de
autorización. A continuación, el teléfono (u ordenador) del cliente
-obtiene la clave de denominación (e, n) provista por el banco central
+obtiene la clave de denominación $(e, n)$ provista por el banco central
para ese valor; calcula entonces (2) un par de claves para una moneda,
-con la clave privada c y la clave pública C, y elige un factor de cegado
+con la clave privada c y la clave pública $C$, y elige un factor de cegado
$b$. A la clave pública de la moneda se le aplica una función hash
($\to$ $f$) y es cegada ($\to$ $f'$). A continuación, (3) el teléfono
del cliente envía $f'$ junto con una autorización para retirar la
moneda y debitar de la cuenta del cliente en el banco comercial a través
de un canal seguro establecido. El banco comercial entonces (4) debita
-la cantidad en la cuenta de depósito del cliente , (5) autoriza
+la cantidad en la cuenta de depósito del cliente, (5) autoriza
digitalmente la petición con la propia firma digital de su sucursal
bancaria y reenvía la petición y la moneda cegada al banco central para
su firma. El banco central (6) deduce el valor de la moneda en la cuenta
@@ -940,8 +940,8 @@ del banco comercial, firma la moneda de forma ciega con la clave privada
del banco central para el valor respectivo, y (7) devuelve la firma
ciega $s'$ al banco comercial. (8) reenvía la firma ciega $s'$
a la billetera electrónica del cliente. Finalmente, el teléfono del
-cliente (9) usa b para descifrar la firma ($\to$ $f$) y almacena la
-moneda recién acuñada (c, s).
+cliente (9) usa $b$ para descifrar la firma ($\to$ $f$) y almacena la
+moneda recién acuñada $(c, s)$.
Cuando se gastan CBDC, el proceso es análogo a pagar al vendedor en
efectivo. Sin embargo, para asegurar el acuerdo, el vendedor debe
@@ -950,14 +950,14 @@ Figura 2.
Un cliente y un vendedor negocian un contrato comercial, y (1) el
cliente usa una moneda electrónica para firmar el contrato o factura de
-venta con la clave privada c de la moneda y transmite la firma al
+venta con la clave privada $c$ de la moneda y transmite la firma al
vendedor. La firma de una moneda en un contrato con una moneda válida es
una instrucción del cliente para pagar al vendedor que es identificado
por la cuenta bancaria en el contrato. Los clientes pueden firmar
contratos con múltiples monedas en caso de que una sola moneda fuera
insuficiente para pagar la cantidad total. El vendedor (2) valida
entonces la firma de la moneda sobre el contrato y la firma s del banco
-central sobre $f$ que corresponde a la C de la moneda con las
+central sobre $f$ que corresponde a la $C$ de la moneda con las
respectivas claves públicas y reenvía la moneda firmada (junto con la
información de la cuenta del vendedor) al banco comercial del vendedor.
El banco comercial del vendedor (3) confirma que el vendedor es uno de