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:16 ADT
Mordechai Ovits (movits@syndata.com)
Wed, 25 Mar 1998 14:53:26 -0500
Mark A. Herschberg wrote:
> 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
I believe that there is a problem with using your (1,E,5,657439) idea.
What if your message was "HELLO"? It might get sent like this:
(1,H,Y,24457)
(2,T,E,36274)
(3,L,X,34743)
(4,L,O,98544)
(5,J,O,74394)
Clearly, there is no path through the letters that makes any sense other
than "HELLO". If you use more than one bit per packet/MAC, you leave it
open to some cryptanalysis through, at the very least, "di-bit
frequency". It gets worse as you increase bits per packet/MAC.
I like Art's idea to slim the message size down quite a lot. Every
packet would simply be the MAC of a sequence number and the bit to be
sent. Assuming a reliable connection, you need not even send the
sequence number! The only thing sent down the pipe will be MACs!
However, the single bit wasn't contributing much to the size problem to
begin with :-).
Anyone have any ideas to make it even *more* practical?
The following archive was created by hippie-mail 7.98617-22 on Fri Aug 21 1998 - 17:16:16 ADT