API de Números Aleatorios Seguros: Bytes y Auditoría

Puntos clave

Use un servicio basado en CSPRNG para bytes sensibles, números acotados, barajado y muestreo.
Defina operación, rango, cantidad y comportamiento de error antes de integrar el endpoint.
Considere el recibo como evidencia de lo registrado, no como una prueba pública que predice o reconstruye el valor.

CSPRNG describe resistencia a predicción, no apariencia

Un generador pseudoaleatorio criptográficamente seguro busca impedir que la observación de salidas anteriores permita predecir las siguientes en la práctica. Es distinto de un generador de simulación reproducible, donde conocer la semilla suele ser útil.

La API debe ofrecer operaciones inequívocas para evitar que cada cliente convierta bytes de forma diferente. Rantropy admite bytes aleatorios, números acotados, barajado, muestreo y distribuciones mediante REST y gRPC. La operación elegida forma parte del contexto de uso y evidencia.

Decisiones anteriores a la primera solicitud

Separe material de seguridad y aleatoriedad de negocio. Secretos de sesión y nonces requieren salida en bytes y manejo estricto. Sorteos, ítems probabilísticos y muestras requieren rangos, tamaños de lista, reglas de reemplazo y errores explícitos.

Use REST para compatibilidad amplia o gRPC para tráfico persistente entre servicios.
Defina límites de tiempo, reintentos e idempotencia para la operación de negocio.
Guarde claves API en un gestor de secretos y sepárelas por entorno o servicio.
Decida qué solicitudes necesitan recibo y cuánto tiempo conservar la evidencia.

Llame al endpoint REST con una cantidad explícita

La operación de bytes aleatorios recibe count en JSON. En la respuesta REST JSON, el campo bytes de protobuf se representa como data en base64, mientras randomnessBytesConsumed indica la cantidad facturable de la operación.

receiptId solo aparece cuando la generación de recibos está habilitada para el contrato y la solicitud. El cliente debe tratarlo como opcional y no asumir que toda respuesta correcta incluye un recibo.

Solicitar 32 bytes aleatoriosMantenga el endpoint y las credenciales en variables de entorno o en un gestor de secretos.

curl --request POST "$RANTROPY_REST_URL/v1/random/bytes" \
  --header "content-type: application/json" \
  --header "x-api-key: $RANTROPY_API_KEY" \
  --header "x-api-secret: $RANTROPY_API_SECRET" \
  --data '{"count":32}'

Ejemplo de respuesta JSONDescodifique data desde base64 antes de utilizar los 32 bytes originales.

{
  "response": {
    "success": true
  },
  "data": "<base64-encoded-random-bytes>",
  "randomnessBytesConsumed": 32,
  "receiptId": "<receipt-id-when-enabled>"
}

Qué verifica Rantropy y qué no afirma

Rantropy conecta solicitud, hash del resultado, uso y tiempo con un recibo consultable. Cuando el plan y la política lo permiten, cadenas hash y pruebas de Merkle ayudan a detectar eliminaciones o modificaciones posteriores.

Este modelo no es una función aleatoria verificable, un beacon público ni un protocolo commit-reveal. Esos sistemas responden a otras amenazas, como probar un valor con una clave pública o impedir que una parte elija sola la semilla final. El modelo debe elegirse según el riesgo.

Comprobaciones operativas posteriores

Observe latencia y errores por operación, concilie uso y contrato, verifique recibos periódicamente y pruebe la rotación de claves. En alto volumen, incluya número de claves y proporción de recibos en las pruebas porque la evidencia asíncrona tiene su propia capacidad.

Qué exigir a una API de números aleatorios seguros