Path: utzoo!telecom-request Date: Sat, 22 Jun 91 16:42:57 bst From: The Watcher Newsgroups: comp.dcom.telecom Subject: Re: SPECIAL REPORT: Braided Streams Message-ID: Organization: Loughborough University, UK. Sender: Telecom@eecs.nwu.edu Approved: Telecom@eecs.nwu.edu X-Submissions-To: telecom@eecs.nwu.edu X-Administrivia-To: telecom-request@eecs.nwu.edu X-Telecom-Digest: Volume 11, Issue 479, Message 2 of 8 Lines: 24 > When transmitting noise or key management material, there is > no objection to padding. But when processing plaintext, we > must have a way of knowing where the end of the plaintext > is. There is, so far, no elegant solution. I suggest > reserving a character for escape purposes, and use this > character as end of file marker, unless it is itself > escaped. The ASCII escape character seems to be indicated. As you're treating the streams as bit pipes, can't you just use bit stuffing to allow you to use a flag character such as SDLC's 01111110? Using ASCII escape could cause problems if your plaintext to be encrypted isn't ASCII plaintext but binary, EBCDIC, etc. I should not think that the limitation on the number of sequentially transmitted 1's in any one stream should make much difference as the whole point of the exercise is that your cryptanalyst/spy/cracker doesn't know what stream any one bit belongs to. Then again I'm no cryptanalyst/ spy/hacker... 8-) Jon JANET: J.P.Knight@uk.ac.lut Internet: J.P.Knight@lut.ac.uk Dept. Comp.Sci., LUT, Ashby Road, Loughbourgh, Leics, England. LE11 3TZ