Other Directory Sites: SeekWonder | Directory Owners Forum
The following archive was created by hippie-mail 7.98617-22 on Fri Aug 21 1998 - 17:16:15 ADT
Mark A. Herschberg (hershey@MIT.EDU)
Wed, 25 Mar 1998 14:24:24 EST
movits@syndata.com said:
> My second question is: Ron notes that you can add more than one
> subsequence of chaff to the stream, and make those chaff with another
> key. The "extra" key that created the chaff could be given over to
> authorities, which would extract a readable, but incorrect message.
> He compares this to deniable encryption. If you are doing this, why
> bother making it a subsequence? Let ALL the chaff come from some
> innocuous message! This would work especially well with my first idea,
> since the two messages would not have to be the same size.
This sounds like a good idea. Suppose we want to have a half hour
"conversation." Someitme before, we open a channel, and start sending
packets, including, not just chaff, but also Shakespeare's _Hamlet_, data from
my web page, etc., each one a different "message." These different messages
jump in and out of the channel to inhibit timing analysis. At some point, I
also include the actual information I want to secretly tell you. There's
plenty of extra messages to hand over to the courts. (Note: you may need to
include a channel with private, useless messages, and not just public
information such as _Hamlet_ and your web page, but dummy private messages
could easily be made.)
The drawback to this system is the heavy load. Certainly, if we all use
this protocol, especially where we sure the channel significantly ahead of
time (as described above), the internet going to be extremely jammed.
However, a more practical use for this might be over the phone. To send a
secure fax, for example, we'll have a "private" (although not secure) line
which we can stuff packets down to our heart's content.
Art Housnger brough up the follwing point to me the other day:
Why not just send
(1,0,351216)
(1,1,351216)
(2,0,452412)
(2,1,452412)
(3,0,639723)
(3,1,639723)
(4,0,321329)
(4,1,321329)
were for each bit of wheat, the chaff uses the same MAC. This, in and of
itself, doesn't seem to add any security, but what if we do the following:
(1,0,1,351216)
(2,0,1,452412)
(3,0,1,639723)
(4,0,1,321329)
In the above case, each packet has two bits with it, one of which matches the MAC, and one of which doesn't. (And occasionally packets neither of which work as some extra chaff?) Clearly in the bit case, the "0,1" can be left out. If more than one bit is sent per packet, then one could imagine when sending, say, hex, a packet like
(1,E,5,657439)
where the MAC is valid for either E or 5.
I haven't had time to look this up, but I seem to recall in literature some use of MACs for security that works in this way.
Now in the example with 4 packets, it's still revealing that a message is 4 bits long (and there may be other flaws I'm not thinking of). If this isn't a problem (and I didn't miss a security hole), then we just made the algorithm 50% more efficient.
I've only given brief thought to this, as I'm extremely busy with other projects, but I would be interesting in hearing feedback and/or point out what I've missed here.
Some points to consider:
Would this work even with a bad MAC? (Since # of 1's = # of 0's)
Is this stronger when using 2 or 3 different MACs for one message?
--Mark A. Herschberg
The following archive was created by hippie-mail 7.98617-22 on Fri Aug 21 1998 - 17:16:15 ADT