[LACNIC/Seguridad] [LAC-TF] Revisión de IETF I-D: draft-ietf-6man-stable-privacy-addresses-00.txt

Matthias Bethke matthias en towiski.de
Mie Mayo 23 02:47:51 BRT 2012


Fernando Gont on Tue, May 22, 2012 at 02:53:58PM -0300:
> > Chévere. Imagino que el problema más difícil será encontrar un
> > método universalmente aplicable de generar la llave secreta y
> > después pasarlo del FS al kernel.
> 
> Exacto. En particular para que no "desencaje" con el modo de guardar
> otra información similar en el kernel de cada sistema. -- Por eso mi
> idea es consultar con cada OS antes de ponerme a hacer código, para
> que me guien un poco en ese aspecto...

En Linux podrías guardar la llave en /etc/iproute2 si no debería
funcionar completamente en el kernel, así probablemente solo queda un
argumento en  la línea de comando del.

> > Finalmente, no soy experto en eso pero creo que todo encima de 64
> > bits de entropía no va a mejorar el resultado si el output es de 64
> > bits. O 63 en la verdad, por el #6=0.
> 
> Te referis a:
> 
> a) No mejora la entropia si F() tiene un output de 64 bit, o,
> b) No mejora la entropia si el output de F() se *trunca* a 64 bits?
> 
> 
> -- Porque dado que no forzamos ninguna funcion en particular, la
> salida de F() podria ser mayor que 64 bits...

El último. Aunque el resultado de F() tenga más que 63 bits de entropía,
después de truncarlo ya no tiene más, y allí ya estamos en los 500,000
años para un escaneo otra vez.

cheers,
	Matthias

------------ próxima parte ------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <https://mail.lacnic.net/pipermail/seguridad/attachments/20120522/a16c7e14/attachment.sig>


Más información sobre la lista de distribución Seguridad