hes@ncsu.UUCP (Henry Schaffer) (02/27/86)
<>After reading the discussion on how the inter-character distances of a printout (easy to do on a laser printer) could be used to encode information, I started thinking about other places to hide information. One place I came up with can hold quite a bit (pun intentional) of information is the stop bit of serial ascii transmission. (One can consider this another example of inter-character distances.) It wouldn't take very much special in the way of extra hardware to generate a few different lengths of stop bits (e.g., 1, 1 1/4, 1 1/2, and 1 3/4 bit timings long) and to differentiate between them at receipt. However most data communications equipment will completely ignore these differences (and have indeed been designed to ignore them.) The information could be lost if the data transmission went through a regenerator or a packet net, ... . Has anyone been doing this? --henry schaffer
john@anasazi.UUCP (John Moore) (03/04/86)
In article <3031@ncsu.UUCP> hes@ncsu.UUCP (Henry Schaffer) writes: ><>After reading the discussion on how the inter-character distances >of a printout (easy to do on a laser printer) could be used to encode >information, I started thinking about other places to hide information. > One place I came up with can hold quite a bit (pun intentional) of >information is the stop bit of serial ascii transmission. (One can >consider this another example of inter-character distances.) It >wouldn't take very much special in the way of extra hardware to >generate a few different lengths of stop bits (e.g., 1, 1 1/4, 1 1/2, >and 1 3/4 bit timings long) and to differentiate between them at One tries to design optimal filters for modems based on the signalling speed. Thus, if you are using a 1200bps modem, the data filters (which are essential for improving the signal to noise ration) will cut off information above the 1200bps rate. The different lengths of stop bits correspond to increasing the baud rate of the line (they add higher frequencies to the baseband signal. Hence, the better the modem you use, the worse this technique will work! -- John Moore (NJ7E/XE1HDO) {decvax|ihnp4|hao}!noao!terak!anasazi!john {hao!noao|decvax|ihnp4|seismo}!terak!anasazi!john terak!anasazi!john@SEISMO.CSS.GOV (602) 951-9326 (day or evening) 7525 Clearwater Pkwy, Paradise Valley, AZ, 85253 (Home Address) The opinions expressed here are obviously not mine, so they must be someone else's.
gnu@hoptoad.uucp (John Gilmore) (03/16/86)
In article <611@anasazi.UUCP>, john@anasazi.UUCP (John Moore) writes: > In article <3031@ncsu.UUCP> hes@ncsu.UUCP (Henry Schaffer) writes: > > One place I came up with can hold quite a bit (pun intentional) of > >information is the stop bit of serial ascii transmission. (One can > >consider this another example of inter-character distances.) It > >wouldn't take very much special in the way of extra hardware to > >generate a few different lengths of stop bits (e.g., 1, 1 1/4, 1 1/2, > >and 1 3/4 bit timings long)... In fact, some of the more recent UART or SCC chips allow you to set "stop bit shaving" like the above. The reason is that if you are relaying data, someone could be feeding you data with a slightly overspeed clock (say 1210 baud instead of 1200). If you pass it on at 1200 you will need infinite bufferring. Instead, when your buffer starts to fill, you can shave your stop bits down to 3/4 bit time and catch up. Also note that many high speed modems receive your async data and convert it to synchronous for the actual modem<->modem protocol. I recall seeing 4800 baud modem designs work that way. This would blow away the shaved stop bits. -- John Gilmore {sun,ptsfa,lll-crg,ihnp4}!hoptoad!gnu jgilmore@lll-crg.arpa
phil@amdcad.UUCP (Phil Ngai) (03/17/86)
In article <622@hoptoad.uucp> gnu@hoptoad.uucp (John Gilmore) writes: >Also note that many high speed modems receive your async data and >convert it to synchronous for the actual modem<->modem protocol. >I recall seeing 4800 baud modem designs work that way. This would >blow away the shaved stop bits. Modems as slow as Bell 212 convert async input to sync data before putting it out on the phone line. This (shaving stop bits to transmit data) is a very boring subject, in my opinion. If you can modulate at twice your bit rate or four times your bit rate, why not just send ALL your bits faster? Why stop with only diddling the stop bit? (this paragraph is in response to the original question. John Gilmore's article points out a useful application of bit shaving.) -- "We must welcome the future, remembering that soon it will become the present, and respect the past, knowing that once it was all that was humanly possible." Phil Ngai +1 408 749 5720 UUCP: {ucbvax,decwrl,ihnp4,allegra}!amdcad!phil ARPA: amdcad!phil@decwrl.dec.com