¿Cómo "cifraría" un mensaje usando una *clave pública* de Bitcoin y usaría su clave privada para descifrarlo?

Tengo la siguiente cadena de texto:

Este es un mensaje de prueba.

  • Usando mi clave pública de bitcoin (¿dirección de bitcoin?), ¿cómo puedo cifrar este mensaje?

  • ¿Cómo descifraría el mensaje usando una clave privada de bitcoin?

¿Quiere cifrar con una clave pública o usar una contraseña? Esos dos requieren tecnologías muy diferentes.
Básicamente, tome la dirección de bitcoin de cualquier persona y cifre un mensaje, luego envíe a esta persona el mensaje cifrado donde puede descifrar con su clave privada de bitcoin. ¿O eso no funciona en absoluto?
¿Pero también menciona AES y necesita una contraseña para descifrar?
pregunta actualizada. Se eliminó la referencia aes. fue confuso.
La dirección de Bitcoin se deriva de la clave pública, pero no es suficiente para cifrar.
He estado mirando esto. Pensé en tener una llave que fuera súper portátil como una llave BTC. Algo que se puede almacenar a través de un mnemotécnico en lugar de archivos grandes.

Respuestas (3)

Sí, esto es posible.

Sin embargo, quiero decir por adelantado que esto no es recomendable por varias razones:

  • Las claves de Bitcoin están destinadas a ser de un solo uso por razones de privacidad, y aprovecharlas para el cifrado fomenta innecesariamente que se traten como una identidad de larga duración.
  • Puede haber interacciones desagradables y peligrosas cuando las claves se usan para múltiples protocolos de forma independiente.
  • Es mucho mejor usar sistemas que en realidad fueron diseñados para el cifrado que intentar aprovechar la criptografía de Bitcoin.
  • Implementar su propia criptografía es muy peligroso (en general, a menos que sepa lo que está haciendo y obtenga muchas revisiones de expertos).

Existe un esquema llamado ECIES que le permite aprovechar las claves de curva elíptica para crear un sistema de cifrado.

En resumen, funciona por:

El remitente:

  • genera una clave privada efímera k utilizando un generador criptográfico fuerte de números aleatorios, con una clave pública asociada k = kG (la multiplicación se refiere aquí a la multiplicación de curva elíptica ).
  • calcula un secreto compartido ECDH s = H(kP) , donde P es la clave pública del destinatario.
  • calcula dos claves simétricas x 1 y x 2 usando un KDF sembrado por s : (x 1 , x 2 ) = KDF(s) .
  • cifra el mensaje m utilizando AES, con x 1 como clave, para obtener c = AECEnc x 1 (m) .
  • calcule un MAC en K y c con x 2 como clave: h = MAC x 2 (K || c) .
  • envía (K, c, h) al destinatario.

El recipiente:

  • calcula el secreto compartido ECDH, usando s = H(pK) , donde p es su clave privada.
  • calcula las mismas dos claves simétricas x 1 y x 2 : (x 1 , x 2 ) = KDF(s) .
  • calcula el mismo MAC h' = MAC x 2 (K || c)
  • verifica que h' = h , y falla si no.
  • descifra el mensaje usando s , m' = AESDec x 1 (c) .
Si no tiene una MAC, lo que ha implementado no es ECIES y, a menudo, sería vulnerable a los ataques de Oracle de descifrado. Por ejemplo, le llevo un mensaje que quiero descifrar y luego le envío una serie de mensajes reutilizando la clave efímera y probando cómo responde a diferentes textos cifrados basura.
@ G.Maxwell Buen punto, arreglado.
un par de errores tipográficos: with associated public key k = kG.. aquí debería ser mayúscula K = kG; y AECEncdebería serAESEnc

Si desea encriptar mensajes, debe usar una herramienta de encriptación de mensajes/archivos adecuada como PGP/GPG. La criptografía casera que usa cosas de bitcoin es propensa a tener malas propiedades de seguridad.

Aunque probablemente tengas razón. Esto realmente no parece responder a la pregunta. Pensaría que estás diciendo "no se puede hacer", pero, de nuevo, parece que estás diciendo que se puede hacer, pero no estás respondiendo "cómo", que es la pregunta.
La respuesta es "probablemente no deberías". Creo que esta es una respuesta mucho más valiosa que dar un tutorial que finalmente deja al autor de la pregunta menos informado y potencialmente completamente inseguro.
No estoy de acuerdo, "probablemente no deberías" es una respuesta en absoluto. Podría ser parte de una respuesta, como un descargo de responsabilidad como en la respuesta de Pieter. Solo, sin embargo, es más como negar una respuesta. Aunque las preguntas a veces incluyen cosas que parece que nadie debería necesitar, podría haber casos de uso legítimos raros. Incluso si la necesidad del OP no es legítima, la de un futuro lector podría.

Asegúrese de seguir las advertencias proporcionadas anteriormente en otras respuestas, pero para que conste, esto se implementó en un proyecto llamado Bitmessage . La implementación principal está en Python en https://github.com/Bitmessage/PyBitmessage . También hay un módulo npm para node.js que implementó esto para el servidor y el navegador usando bibliotecas openssl c bajo el capó eccrypto:

Instalar dependencias

$ npm install -g eccrypto

índice.js

var crypto = require("crypto");
var eccrypto = require("eccrypto");

var privateKeyA = crypto.randomBytes(32);
var publicKeyA = eccrypto.getPublic(privateKeyA);
var privateKeyB = crypto.randomBytes(32);
var publicKeyB = eccrypto.getPublic(privateKeyB);

// Encrypting the message for B.
eccrypto.encrypt(publicKeyB, Buffer("msg to b")).then(function(encrypted) {
  // B decrypting the message.
  eccrypto.decrypt(privateKeyB, encrypted).then(function(plaintext) {
    console.log("Message to part B:", plaintext.toString());
  });
});

// Encrypting the message for A.
eccrypto.encrypt(publicKeyA, Buffer("msg to a")).then(function(encrypted) {
  // A decrypting the message.
  eccrypto.decrypt(privateKeyA, encrypted).then(function(plaintext) {
    console.log("Message to part A:", plaintext.toString());
  });
});