Member of The Internet Defense League Últimos cambios
Últimos Cambios
Blog personal: El hilo del laberinto Geocaching

Chaffing&Winnowing

Última Actualización: 20 de Octubre de 1.998 - Viernes

"Chaffing&Winnowing" ("empajar" y cribar) es una técnica de cifrado, propuesta por Ronald L. Rivest en Marzo de 1.998, que no utiliza ninguna clave de cifrado propiamente dicha, sino que emplea la tecnología de autentificación para lograr transmitir documentos de forma segura sin, en principio, estar sometido a las regulaciones sobre exportaciones de criptosistemas de cifrado.

La técnica empleada es muy sencilla:

  1. El transmisor y el receptor comparten una clave secreta de autentificación. Esta clave se utiliza para verificar:

    • Que el transmisor del mensaje es quien dice ser.
    • Que el mensaje no ha sido modificado en modo alguno.

    Las claves de autentificación no están sujetas a restricciones de exportación, ya que el documento en sí no se cifra.

  2. El transmisor divide el mensaje a enviar en bits individuales.

  3. Por cada bit del mensaje, manda dos paquetes con el formato:
    [número de serie]0[MAC0]
    [número de serie]1[MAC1]
    

    El número de serie sirve para secuenciar los mensajes y los bits individuales dentro de cada mensaje, y no deben reutilizarse. El MAC (message Autentication Code) se calcula con la clave secreta de autentificación. El MAC0 será correcto si estamos transmitiendo un cero, y el correcto seráa el MAC1 si lo que estamos transmitiendo es un uno. En ambos casos, el otro MAC es incorrecto, y se puede generar de forma aleatoria.

  4. El receptor recibe ambos paquetes. Para comprobar cual de los dos en el correcto, tan sólo debe validar ambos MACs utilizando la clave secreta. El otro, simplemente, se descarta.

El sistema, como puede verse, es francamente sencillo. Su problema es que para transmitir un único bit es preciso enviar dos paquetes, cada uno de ellos con un tamaño de cientos de bits. Ante este problema existen varias soluciones.

  • Una posibilidad es negociar un número de secuencia inicial (es importante que no se repita) y confiar en la entrega secuencial de protocolos como el TCP, lo que nos evita tener que enviar el número de secuencia en cada paquete, ya que pasa a ser implícito.

  • Otra posibilidad es no enviar dos paquetes, sino sólo un único MAC. En el receptor se calculará el MAC correspondiente a los bits "0" y "1", y se tomará el que coincida.

  • Se puede enviar sólo el número de bits del MAC necesarios para resolver la ambigüedad entre cero y uno. Bastará con un bit en la mitad de los casos, con dos bits en la cuarta parte, etc. Idea mía, desarrollada en privado.

  • También se puede: (Idea mía, publicada en Internet - 11/May/98)

    • Generar el MAC para el cero y el uno.
    • Comparar ambos hasta encontrar un bit diferente.
    • Enviar exclusivamente ese bit de diferencia.

    Basádose en esa idea, Bill Stewart ha propuesto una pequeña diferencia, que consiste en decidir el bit a enviar en función de qué MAC sera numéricamente mayor o menor, no en el primer bit diferente. La implementación resulta más rápida, aunque el 99.995% del tiempo de CPU se invierte en el cálculo de los MAC, y ese paso no se puede eliminar...

  • Por último, se puede: (Idea mía, no publicada - 19/Oct/98)

    • Generar el MAC para el cero y el uno.
    • Comparar ambos hasta encontrar un bit diferente.
    • Enviar exclusivamente ese bit de diferencia.
    • Para los siguientes bits a enviar, tomar los MAC anteriores e ir aprovechando los bits diferentes de ellos. No se calculan MACs nuevos hasta haber agotado las diferencias de los antiguos.

Aunque mis propuestas probablemente no pasasen las normas de exportación de aplicaciones criptográficas de EE.UU., pretendía probar:

  • Que pueden aplicar las técnicas de Winnowing & Chaffing sin sobrecarga en la longitud del documento.
  • Que se pueden utilizar las tecnologías de firma digital, que no están reguladas, para proporcionar cifrado seguro.

Creo haber logrado ambos puntos.

A medida que reducimos la sobrecarga del protocolo, se va desvirtuando sus intenciones originales, que son transmitir el texto en claro, sin cifrar, pero sin poder leerlo a menos que se conozca la clave de autentificación.

Se puede reducir el "overhead", también, transmitiendo bloques más grandes que un bit, sin filtrar información. Se pueden utilizar técnicas "todo o nada" para asegurarse que el receptor sólo pueda descifrar el mensaje si lo ha recibido completo. Una posibilidad:

  1. Dividir el documento original en "n" bloques.

  2. Elegir una clave al azar y cifrar los bloques con esa clave.

  3. Tomar los bloques cifrados y calcular el hash de cada uno de ellos.

  4. Enviar un bloque adicional formado con la clave aleatoria elegida para el cifrado, XOR el XOR del hashing de los bloques.

Con este esquema, un receptor sólo puede descifrar el mensaje si recibe todos los bloques. Si le falta alguno, no podrá descifrar ninguno de ellos. Tampoco se puede considerar que esta técnica sea un cifrado, ya que la clave de cifrado, que protege el texto, se transmite con el propio mensaje.

Si el documento original se divide en "n" trozos, y por cada trozo se transmite un bloque de "enmascaramiento", hay que hacer 2n descifrados. Este sistema, por tanto, reduce el "overhead" a sólo el 100%, mientras conserva la dificultad del descifrado por parte de un atacante. En realidad se puede reducir el overhead de forma arbitraria, para un documento lo bastante largo, sin más que usar "n" fragmentos de "chaffing", con una complejidad "por fuerza bruta" de 2n, donde "n" lo elegimos nosotros. Es decir, se puede tener una protección excelente enviando comparativamente poco "chaffing"; no hace falta enviar tantos paquetes de "grano" como de "paja".

De hecho el propio Ronald L. Rivest sugiere una implementación páctica muy eficiente enviando sólo "n*mac" bits de "chaffing", donde 2n es el nivel de dificultad que queremos imponer y "mac" es la longitud del MAC que utilizamos. El mensaje original se puede ver al final de este documento:

  • Aplicamos una transformación Todo-o-Nada al documento a transmitir.
  • Transmitimos los primeros "n" bits del documento usando la técnica de Chaffing&Winnowing en su forma original.
  • Transmitimos el resto del documento tal cual.

La ventaja del esquema original es que se puede argumentar que el documento no va cifrado, como es el caso. Las legislaciones nacionales permiten la exportación de software de firmas digitales sin restricciones, pero los algoritmos con capacidad de cifrado están sujetos a controles. Este esquema demuestra, por tanto, que no se puede restringir la exportación criptográfica de forma arbitraria.

Una aplicación de esta técnica consiste en emplearla como un sistema de "Deniable Encryption", donde se multiplexan dos documentos, siendo uno la "paja" del otro. De esta forma, en caso de problemas, bastará con proporcionar la clave de la "paja", lo que descifrará un documento inocuo.


Para leer


Message-ID: <35571323.D109A0D2@argo.es>
Date: Mon, 11 May 1998 15:02:59 +0000
From: "Jesús Cea Avión" <jcea@argo.es>
Organization: Argo Redes y Servicios Telematicos, S.A.
To: coderpunks@toad.com, cypherpunks@toad.com, cryptography@c2.net, hacking@argo.es, teleco-vigo@argo.es, cert-es@listserv.rediris.es, MAIL-PGP@LISTSERV.REDIRIS.ES, apedanica@encomix.com, cripto-foro@fi.upm.es
Subject: Chaffing & winnowing without overhead

You can have chaffing & winnowing without bandwidth overhead, but the resulting scheme hasn't the original "elegance" anymore. In particular, you don't send the plaintext on the clear.

The new schema is useful to cypher a document using any standard signature library, exportable by definition. Very nice :), since you can use, at last, strong crypto :).

  1. When the connection starts, negociate an initial sequence number. The sequence number mustn't be reused. We assume a ordered delivery, like TCP.

  2. Calculate the signature for:
    [sequence]0  ->  MAC0

    and

    [sequence]1  ->  MAC1

  3. Compare both MACs and locate the first "different" bit, from high to low bit or viceversa.

  4. Send that bit from MAC0 if you want to send a "0" or from MAC1 if you want to send a "1".
-- 
Jesus Cea Avion                         _/_/      _/_/_/        _/_/_/
jcea@argo.es http://www.argo.es/~jcea/ _/_/    _/_/  _/_/    _/_/  _/_/
                                      _/_/    _/_/          _/_/_/_/_/
PGP Key Available at KeyServ   _/_/  _/_/    _/_/          _/_/  _/_/
"Things are not so easy"      _/_/  _/_/    _/_/  _/_/    _/_/  _/_/
"My name is Dump, Core Dump"   _/_/_/        _/_/_/      _/_/  _/_/
"El amor es poner tu felicidad en la felicidad de otro" - Leibnitz


Message-ID: <35572194.51CDC872@syndata.com>
Date: Mon, 11 May 1998 12:04:36 -0400
From: "Mordechai Ovits" <movits@syndata.com>
To: "Jesús Cea Avión" <jcea@argo.es>
CC: coderpunks@toad.com, cypherpunks@toad.com, cryptography@c2.net, hacking@argo.es, teleco-vigo@argo.es, cert-es@listserv.rediris.es, MAIL-PGP@LISTSERV.REDIRIS.ES, apedanica@encomix.com, cripto-foro@fi.upm.es
Subject: Re: Chaffing & winnowing without overhead
References: <35571323.D109A0D2@argo.es>

Jesús Cea Avión wrote:

> You can have chaffing & winnowing without bandwidth overhead, but the
> resulting scheme hasn't the original "elegance" anymore. In particular,
> you don't send the plaintext on the clear.
>
> The new schema is useful to cypher a document using any standard
> signature library, exportable by definition. Very nice :), since you can
> use, at last, strong crypto :).
>
> a) When the connection starts, negociate an initial sequence number.
> The sequence number mustn't be reused. We assume a ordered delivery,
> like TCP.
>
> b) Calculate the signature for:
>
> [sequence]0 -> MAC0
>
> and
>
> [sequence]1 -> MAC1
>
> c) Compare both MACs and locate the first "different" bit,
> from high to low bit or viceversa.
>
> d) Send that bit from MAC0 if you want to send a "0" or from
> MAC1 if you want to send a "1".

On the contrary, it has an elegance all it's own :-).

Since this idea has gone through several iterations, starting from Ron's original paper, I wanted to summarize in one place Jesus Cea Avion's idea. All credit for the following technique goes to him.

Alice does this:
Mreal = MAC(serial number, message bit, key)
Mfake = MAC(serial number, complement of message bit, key)

In english: She MACs both the bit she means, and then MACs the bit she does NOT mean. She then compares the two MACs to find the first different bit. Then she sends to Bob the bit from Mreal in the position of difference.

When Bob gets the bit, he does this:
Ma = MAC(serial number, 0, key)
Mb = MAC(serial number, 1, key)

He then compares Ma to Mb and finds the first difference. The bit in the position of difference is the one that was sent to him by Alice. He then knows whether Ma or Mb is correct. If Ma is the correct one then the plaintext bit is 0, if Mb is the correct one then the plaintext bit is 1.

Remember that there is no need to send the serial number, but you MUST use it in the MAC. If you are using a reliable protocol like TCP, or storing it in a file, the serial number is implied by the order it was received/stored.

However clever this technique is (and it *is* clever), it defeats the original purpose of Ron's idea. The original reason Ron created chaffing and winnowing was to show that encryption laws are useless. He demonstrated that you can use authentication technologies to create privacy. Even more, even if the government demands that the plaintext be in the open, his original paper was set up to pass even that egregious requirement. Think of what the govenrnment would see with this latest chaffing and winnowing. Two people are send a bitstream that is unreadable without a secret key. No plaintext is visible. In fact, it bears very little resemblance to the name "chaffing and winnowing." It would not matter to them wether you were using DES, IDEA, or C&W. If it looks like a duck, walks like a duck, and quacks like a duck...

Another point of Ron's paper was that any technique the government tried to impose on C&W would create unacceptable problems. I dont think these problems would exist in this version of C&W. Anyone know better?

-- 
o Mordy Ovits
o Programmer / Cryptographer
o SynData Technologies Inc.
o Download A Free Copy Of Our Software At:
o http://www.syncrypt.com


Message-ID: <3557576A.C5EF9791@argo.es>
Date: Mon, 11 May 1998 19:54:18 +0000
From: "Jesús Cea Avión" <jcea@argo.es>
Organization: Argo Redes y Servicios Telematicos, S.A.
To: Mordechai Ovits <movits@syndata.com>
CC: coderpunks@toad.com, cypherpunks@toad.com, cryptography@c2.net, hacking@argo.es, teleco-vigo@argo.es, cert-es@listserv.rediris.es, Lista PGP <MAIL-PGP@listserv.rediris.es>, Lista Apedanica <apedanica@encomix.com>, cripto-foro@fi.upm.es
Subject: Re: Chaffing & winnowing without overhead
References: <35571323.D109A0D2@argo.es> <35572194.51CDC872@syndata.com>

> However clever this technique is (and it *is* clever), it defeats the
> original purpose of Ron's idea.

Yes, you are right, Mordechai. My point was:

  1. Prove that you can implement chaffing & winnowing without bandwidth overhead. I agree that the final schema doesn't resemble C&W anymore :).

  2. Prove that you can use signature schemes, strong and exportable, to achieve confidentiality. In that way, my objetive is the same that Rivest had.

I'm happy knowing I can use full strengh signatures to keep my secrets, secret :)

> No plaintext is visible.

In the Rivest's paper you transmit, indeed, all the 2n plaintexts for a "n" bit length };-). And if you are using "All Or Nothing Encryption"...

-- 
Jesus Cea Avion                         _/_/      _/_/_/        _/_/_/
jcea@argo.es http://www.argo.es/~jcea/ _/_/    _/_/  _/_/    _/_/  _/_/
                                      _/_/    _/_/          _/_/_/_/_/
PGP Key Available at KeyServ   _/_/  _/_/    _/_/          _/_/  _/_/
"Things are not so easy"      _/_/  _/_/    _/_/  _/_/    _/_/  _/_/
"My name is Dump, Core Dump"   _/_/_/        _/_/_/      _/_/  _/_/
"El amor es poner tu felicidad en la felicidad de otro" - Leibnitz


Message-ID: <3.0.5.32.19980511115153.00941970@popd.ix.netcom.com>
Date: Mon, 11 May 1998 11:51:53 -0700
To: "Mordechai Ovits" <movits@syndata.com>, "Jesús Cea Avión" <jcea@argo.es>
From: Bill Stewart <bill.stewart@pobox.com>
Subject: Re: Chaffing & winnowing without overhead
CC: coderpunks@toad.com, cypherpunks@toad.com, cryptography@c2.net, hacking@argo.es, teleco-vigo@argo.es, cert-es@listserv.rediris.es
In-Reply-To: <35572194.51CDC872@syndata.com>
References: <35571323.D109A0D2@argo.es>

>Jesús Cea Avión wrote:
>> You can have chaffing & winnowing without bandwidth overhead, but the
>> resulting scheme hasn't the original "elegance" anymore. In particular,
>> you don't send the plaintext on the clear.
...
>> b) Calculate the signature for:
>> [sequence]0 -> MAC0
>> [sequence]1 -> MAC1
>> c) Compare both MACs and locate the first "different" bit,
>> from high to low bit or viceversa.
>> d) Send that bit from MAC0 if you want to send a "0" or from
>> MAC1 if you want to send a "1".

So why not _send_ the plaintext in the clear?

Send the 0 bit, and the bit from the MAC0, and the 1 and the MAC1 bit

0 0, 1 1, 0 1, 1 0,

Yes, it's expanding the data 4:1, but that's much better than before.

At 12:04 PM 5/11/98 -0400, Mordechai Ovits wrote:
>On the contrary, it has an elegance all it's own :-).

I strongly agree. I had proposed using a short checksum, e.g. 8 bits of the MAC, which does leave collisions every ~256 sets, but this is almost as short a checksum as you can get, and eliminates the collision except every ~2**64 pairs.

>However clever this technique is (and it *is* clever),
>it defeats the original purpose of Ron's idea.

If you do include the data bits, you maintain (very marginally) the letter of the requirement here. What you do lose with this method is the ability to mix traffic from different people; 1 bit of MAC just isn't enough to pick out your own bits. Any short MAC limits the amount of mixing you can do; an 8-bit MAC lets you mix a bit without too many collisions, and a 64-bit MAC should be enough for any mixture you'd ever bother with (probably 16 or 32 would as well, though especially for 16 you'd still need a longitudinal checksum or some method of handling rare collisions.)

Is it close enough for government work? Probably.

Thanks!
Bill

Bill Stewart, bill.stewart@pobox.com
PGP Fingerprint D454 E202 CBC8 40BF  3C85 B884 0ABE 4639


Message-ID: <35574C41.816CA545@syndata.com>
Date: Mon, 11 May 1998 15:06:41 -0400
From: "Mordechai Ovits" <movits@syndata.com>
To: "Jesús Cea Avión" <jcea@argo.es>
CC: coderpunks@toad.com, cypherpunks@toad.com, cryptography@c2.net, hacking@argo.es, teleco-vigo@argo.es, Lista PGP <MAIL-PGP@listserv.rediris.es>, Lista Apedanica <apedanica@encomix.com>, cripto-foro@fi.upm.es
Subject: Re: Chaffing & winnowing without overhead
References: <35571323.D109A0D2@argo.es> <35572194.51CDC872@syndata.com> <3557576A.C5EF9791@argo.es>

Jesús Cea Avión wrote:

> In the Rivest's paper you transmit, indeed, all the 2^n plaintexts for a
> n bit length };-).

Not so. In his paper (before the package tranform stuff), he had the following expansion.

Assuming a 32 bit serial number and a 160 bit MAC, n bits would expand to 388n. This is because Ron is sending it out like this: quote from http://theory.lcs.mit.edu/~rivest/chaffing.txt.

>To make this clearer with an example, note that the adversary
>will see triples of the form:
> (1,0,351216)
> (1,1,895634)
> (2,0,452412)
> (2,1,534981)
> (3,0,639723)
> (3,1,905344)
> (4,0,321329)
> (4,1,978823)
> ...
>and so on.

Every bit is getting 2 32-bit serial numbers, its own complement, and 2 160-bit MACs. a 10KB file would explode into a 3.789MB file.

Not too practical, eh? :-)

-- 
o Mordy Ovits
o Programmer / Cryptographer
o SynData Technologies Inc.
o Download A Free Copy Of Our Software At:
o http://www.syncrypt.com


Date: Mon, 11 May 1998 16:36:27 -0400 (EDT)
From: Ryan Anderson <ryan@michonline.com>
To: Mordechai Ovits <movits@syndata.com>
CC: Jesús Cea Avión <jcea@argo.es>, coderpunks@toad.com, cypherpunks@toad.com, cryptography@c2.net, hacking@argo.es, teleco-vigo@argo.es, Lista PGP <MAIL-PGP@listserv.rediris.es>, Lista Apedanica <apedanica@encomix.com>, cripto-foro@fi.upm.es
Subject: Re: Chaffing & winnowing without overhead
In-Reply-To: <35574C41.816CA545@syndata.com>
Message-ID: <Pine.GSO.3.96.980511163424.41C-100000@pawn.michonline.com>

On Mon, 11 May 1998, Mordechai Ovits wrote:

> > In the Rivest's paper you transmit, indeed, all the 2^n plaintexts for a
> > n bit length };-).
>
> Not so. In his paper (before the package tranform stuff), he had the following expansion.

Note that any of the 2^n plaintexts can be reconstructed from the following sequence of triples. (Assuming no knowledge of the MAC. The attacker has no idea which of each pair of triples related to each sequence is correct, so he must search every possibility, which turns out to be each of the 2^n plaintexts.)

[QUOTEO BORRADO]

Ryan Anderson 
PGP fp: 7E 8E C6 54 96 AC D9 57  E4 F8 AE 9C 10 7E 78 C9


Message-ID: <3.0.5.32.19980512111053.008af100@popd.ix.netcom.com>
Date: Tue, 12 May 1998 11:10:53 -0700
To: Mark Hahn <mhahn@tcbtech.com>
From: Bill Stewart <bill.stewart@pobox.com>
Subject: Re: Chaffing & winnowing without overhead
CC: "Mordechai Ovits" <movits@syndata.com>, "Jesús Cea Avión" <jcea@argo.es>
In-Reply-To: <3.0.1.32.19980512084508.006d60b8@mail.aosi.com>
References: <3.0.5.32.19980511115153.00941970@popd.ix.netcom.com> <35572194.51CDC872@syndata.com> <35571323.D109A0D2@argo.es>

At 08:45 AM 5/12/98 -0400, Mark Hahn wrote:
>At 11:51 AM 5/11/98 -0700, Bill Stewart wrote:
>> ...
>>Any short MAC limits the amount of mixing you can do;
>>an 8-bit MAC lets you mix a bit without too many collisions,
>>and a 64-bit MAC should be enough for any mixture you'd
>>ever bother with (probably 16 or 32 would as well,
>> ...
>
>[This my be off the subject so I have cc:ed the mail list.]
>
>If you mix data streams, doesn't the IP routing information allow
>someone to identify the bits for just your message.

No. The Chaffing/Winnowing protocol is designed to mix everybody's data together, so that you can only find the data addressed to you by checking the authentication on all the packets and keeping the packets that pass. This way, everybody's traffic acts as chaff for everybody else's traffic. If you could use external information, such as IP addresses, to distinguish between streams of packets, you could identify each message, which would let you read it.

>Assume that the
>carrier (ISP) is mixing your traffic and mine, and my packets are
>going to Alice and yours are going to Betty. In this case, doesn't
>the IP header with the source and destination clearly identify the
>individual streams of data. The packets are identified at the
>IP level with mine having ME->ALICE and yours having YOU->BETTY
>in the header?
>
>It seems to me that C&W works on "broadcast" networks, but
>most of the current usable infrastructure is "routed". Especially
>long haul communications where C&W is most likely to be
>needed.

[*See silly footnote at end.]

Broadcast networks are one way to use C&W, but it's also designed well for multiplexer networks, where you're carrying multiple streams of data with the same endpoints, e.g. multiple communications between two offices with groups of people at each end. One big problem with C&W is that it scales very badly, since every recipient must read every message.

>I must be missing something either elegant or complete obvious.

C&W is elegant because it is very obvious after the fact; it's easy to see how it works, and it cuts to the heart of the issues. The fact that it's not very practical isn't too important :-) though Jesús's work has made it much less impractical. (Rivest also did a more practical follow-on, though the security behaviour is much different, since it's batch-oriented rather than stream-oriented.)

[* Footnote - yes, when I've been doing long-haul driving, most of the broadcast radio has been Country&Western... Oh - wrong C&W...]

Thanks!
Bill

Bill Stewart, bill.stewart@pobox.com
PGP Fingerprint D454 E202 CBC8 40BF  3C85 B884 0ABE 4639


Message-ID: <3.0.5.32.19980512180231.008ae790@popd.ix.netcom.com>
Date: Tue, 12 May 1998 18:02:31 -0700
To: "Mordechai Ovits" <movits@syndata.com>, "Jesús Cea Avión" <jcea@argo.es>
From: Bill Stewart <bill.stewart@pobox.com>
Subject: Re: Chaffing & winnowing without overhead
CC: coderpunks@toad.com, cypherpunks@toad.com, cryptography@c2.net, hacking@argo.es, cripto-foro@fi.upm.es
In-Reply-To: <35574C41.816CA545@syndata.com>
References: <35571323.D109A0D2@argo.es> <35572194.51CDC872@syndata.com> <3557576A.C5EF9791@argo.es>

By the way, instead of transmitting the first bit for which MAC(sequence,0) differs from MAC(sequence,1), as Jesús suggests, you can get the same effect by transmitting a 0 or 1 depending on

MAC(sequence,0) < MAC(sequence,1)

(This assumes a big-endian system and unsigned comparisons; little-endians will have to calculate it the hard way.) If you're willing to be wrong 1 time out of 2**33, you can just use the top 32 bits.

>> In the Rivest's paper you transmit, indeed, all the 2^n plaintexts for a
>> n bit length };-).
>Not so. In his paper (before the package tranform stuff), he had the following expansion.
>Assuming a 32 bit serial number and a 160 bit MAC, n bits would expand to 388n.
>>To make this clearer with an example, note that the adversary
>>will see triples of the form:
>> (1,0,351216)
>> (1,1,895634)
>> (2,0,452412)
>> (2,1,534981)

But that _does_ send the 2^n plaintexts, which are 0 and 1, and n=1.

Thanks!
Bill

Bill Stewart, bill.stewart@pobox.com
PGP Fingerprint D454 E202 CBC8 40BF  3C85 B884 0ABE 4639


Date: Wed, 13 May 1998 02:47:04 -0500 (CDT)
Message-ID: <199805130747.CAA18984@hosaka.smallworks.com>
From: Jim Thompson <jim@smallworks.com>
To: cryptography@c2.org
CC: coderpunks@toad.com, cypherpunks@toad.com
Subject: [rivest@theory.lcs.mit.edu: Chaffing question]

With all of the discussion of C&W, and potential expansion, along with a sideband discussion of same, I decided to ask 'the man' himself.

The '10K email file' used in the example came from the sideband discussion.

Forwarded for your edification.

------- Start of forwarded message -------
Date: Tue, 12 May 1998 18:24:46 -0400
From: Ron Rivest 
Subject: Chaffing question

Suppose you can start with a 10KB email file.

Running a package (all-or-nothing) transform on it adds only a small amount to the length---say 128 bits total, or less (basically the length of a key in your favorite algorithm).

You can break the result into 128 one-bit blocks and one 10KB block. MAC each block.

Add 128 bits of chaff, intermingled with the first 128 blocks from above.

The final result has 128+128+1 packets, and total length 10KB (the original email) + 257*64 bits (for the 257 64-bit MAC values) plus 128 bits (the chaff bits), and assuming that the sequence numbers are implicit rather than explicit, you get a total of around 12.3 KB.

Cheers,
Ron

------- End of forwarded message -------
-- 
Jim Thompson / Smallworks, Inc. / jim@smallworks.com  
      512 338 0619 phone / 512 338 0625 fax
Real, cheap Hardware RNG:  http://www.fringeware.com/nscd/



Python Zope ©1998 jcea@jcea.es

Más información sobre los OpenBadges

Donación BitCoin: 19niBN42ac2pqDQFx6GJZxry2JQSFvwAfS