- cypherpunks-legacy@lists.ogf.org

Re: 'Sunday Times' article on GSM changes
by fnordbox!loydb＠cs.utexas.edu 08 Feb '93

08 Feb '93

:(Thug writes) : :> According to what I read it seems that the whole issue of cellular radio :> signal encryption is really a non-issue. They could have the most secure :... :> What makes you think they don't have the same kind of REMOB/BLV capability :> to the cellular telephone switches? I mean, if a conversation is scrambled :... Eric Fogleman writes: : :If getting around GSM encryption is no problem, then why are governments :pushing the issue? This actually hits on one of my favorite rant topics. The feds like to scream about how hard it is to tap a phone line with digital switching et al, but don't talk about the fact that anyone with half a brain can tap a line using the phone company's LMOS. The only rational theory I've come up with to explain this is that the feds aren't worried about court-ordered wiretaps, but about illegal wiretaps. I bet there's a *lot* of monitoring going on out there that they can't get a court order for, so they're doing it themselves. Monitoring without the cooperation of the phone company will get harder when the company starts paying more attention to security -- whether through encryption or simply using a shredder. :-) Loyd *************************************************************************** * loydb(a)fnordbox.UUCP Call the Fnordbox BBS * Loyd Blankenship * * GEnie: SJGAMES 2 v32bis lines, 24 hrs * PO Box 18957 * * Compu$erve: [73407,515] 512/444-2323 * Austin, TX 78760 * * cs.utexas.edu!dogface!fnordbox!loydb * 512/447-7866 * ***************************************************************************

1 0

Re: Compressed/Encrypted Voice using Modems
by Phil Karn 08 Feb '93

08 Feb '93

At 7 Feb 04:56 CST, Jim Thompson wrote: >I don't see how a 28.8kbps (raw) data rate is possible, as the Shannon >limit for a POTS line is 22kbps. Certainly parts of the phone system >no longer impose the narrow bandwidth that are part of the 'spec', but >one can not always depend on getting a line that exceedes the published >parameters of the phone system. Where do you get this figure of 22 kbps? I would tend to dispute it since I use a Codex FAST modem on my SLIP link and it really does run at 24.0 kb/s on the wire (not counting compression). The throughput display often reads 30 kb/s even when I'm shipping a pre-compressed or encrypted binary file, although that's a phony figure because it includes the asynch start/stop bits that aren't actually sent over the wire. The usual Shannon limit of a phone line is more like 30 kb/s, although it can vary enormously. Generalizations are dangerous. At the very least, you can certainly say that it's no greater than 64kb/s, since it's almost certain that your call passes through a mu-law codec somewhere. Back to vocoders, their quality does tend to be a strong function of data rate. 8kb/s CELP is really not that bad - a little warbly when there's background noise, but not objectionably so in my opinion. In a mobile telephone environment (where I'm familiar with it), it's *much* less objectionable than the usual impairments you get from ordinary FM analog transmission. 4kb/s is noticeably worse. Things get rapidly better as you go above 10-12 kb/s with present algorithms. Also, vocoders need not be constant rate. Ours selects one of four rates on the fly depending on voice activity, which doubles capacity in a CDMA radio environment. It'd also be useful in a packet network, although the small frame sizes (2/5/10/22 bytes) can make header overhead rather significant.

1 0

Re: Compressed/Encrypted Voice using Modems
by jim＠tadpole.com 08 Feb '93

08 Feb '93

> From: Peter Shipley <shipley(a)tfs.COM> > >And why are you limiting this to V.32 (9600bps)? V.32bis (14.4k bps) modem > >chips cost maybe 20% more than v.32 chips in quantity. > > at Interopt I heard some voice demos that were at 9600 4800 and 2400 baud > the 2400 sounded a phoneme chip but was *very* resionable. Quite likely what you heard were 9600/4800/2400bps (bits per second), not baud. The two are different. 2400bps compression of voice is quite a bit beyond current GP CPUs. Also, note that 9600 baud (V.32 carriers) are based on a 2400bps carrier. (And if they're not, I'm sure someone will correct me.) 2400 baud modems are based a bit rate something less than 2400bps, though I can't remember exactly what it is right now. Jim

3 3

Request from a new reader.
by A.J. Janschewitz 08 Feb '93

08 Feb '93

I am new to this group and apologize if my request is covered in a FAQ. Would someone kindly point me to an FTP site or the location of a binary application that can be used to encrypt/decrypt text in an MS-DOS environment? I understand that PGP is UNIX-based, unless there is a DOS version of which I am unaware, but that's why I'm reading this group. Thank you in advance for your help. ==a.j.==

2 1

(Non)Privacy in Phone System...
by Phiber Optik 07 Feb '93

07 Feb '93

My last message was about LMOS/MLT, and MLT's monitoring capabilities of subscriber lines. Another phone company testing system worth mentioning is SARTS (and DACS and SMAS. That's three, but they're related.) SARTS is the Switched Access Remote Test System, and is used in testing special service circuits. And what's special service? A lot of things that AREN'T POTS (Plain Old Telephone Service). Anything from WATS service, to digital carriers (DDS, T1, etc.), and so on. And it's the hard working men and women of the aptly named Special Services Center (or just "Special Services") who oversee nearly every aspect of installation and maintenance. Ah, yes. (Clears throat) The reason I mention them is because every digital carrier goes through your friendly neighborhood BOC central office, whether it be a company's private carrier or someone's dedicated connection to the Internet (EFF's, toad's, etc.). Like MLT is a system used to test subscriber lines in real time, so SARTS is a system used to test special service circuits. In conjunction with SMAS (Switched Maintenance Access System), and the ability to jack-in with their favorite test equipment (such as the much liked T-BERD), together they make up an unbeatable arsenal in trouble shooting. So why do they screw up your leased-line service? There are three rules in maintenance: Training, training, and, of course, training. Or lack thereof. The lovely system which complements these, and even supercedes the need for SMAS points, is DACS, the Digital Access and Cross-connect System. One of its most notable abilities, is providing per-channel 64kbps (DS0) electronic cross-connection and test access to individual channels, IN ANALOG OR DIGITAL FORM, from a T1 (DS1). Sounds neat. The FBI says "It can't be done! You have to make it built in!" But it IS built in, they're just not allowed to play with it (or are they anyway?) Life is funny sometimes. I'm going to pause for now, and concentrate on my Sherlock Holmes movie. I'll see if my messages are well received, and pick it up tomorrow.

1 0

Re: 'Sunday Times' article on GSM changes
by Phiber Optik 07 Feb '93

07 Feb '93

> > Thanks for going into more detail on the REMOB fantasy. > > Can you tell the group what facilities are available that actually do > allow a technician to monitor a particular line (or group of lines), > e.g. what could a telco emp or a phone phreak do (regarding a short or > long term wiretap) if they wanted? And what facilities are *actually > used* when a court-ordered wiretap is implemented? My impression is > that the two are different. > > John > I'm glad you brought up this subject, John, because there is indeed a good deal of misinformation in this area. I'll start off with some of the numerous facilities available to a telco technician. The first I'll mention is MLT (Mechanized Loop or Line Testing), a system which is part of the LCAMOS group of systems (Loop and Cable Admini- stration Maintenance Operations System). Used by Repair Service Attendants, it's seamlessly accessed through LMOS (Loop Maintenance Operations System), when the attendant specifies a 'mask' (form type) that would involve a real- time test to be performed. At the heart of LMOS is a System 370-type pro- cessor. Attendants access the various functions through a Front End (FE) system, commonly running Unix. The data comprising customer records and their corresponding trouble reports/service histories is kept on a high- capacity storage system (nicknamed the HICAPs). Each front-end accesses data from different HICAPs for the respective areas they cover. Getting back to masks, when the attendant gets a call on 611, upon the customer hanging up, they usually issue the TEST mask, which accesses MLT which in turn establishes a metallic connection to the phone line. MLT then carries out impedance, capacitance, frequency/amplitude response tests (at 404Hz, 1004Hz, and 2804Hz, standard), tests for line activity, etc., etc. The attendant then has the option to open a trouble record (using the ESTablish mask), to initiate further testing and repair, possibly dispatching someone, etc. I'm getting a bit off topic, but I thought some background was in order rather than just saying "MLT monitors lines, so there". What I'm driving at in this scenario is that there is also a mask known as TV, for Trouble Verification. The /FORm associated with this mask requests such information as the phone number, the 3-digit employee code, a callback number for security, and the type of TV (RCA, Magnavox, Toshiba, just kidding :), types being talk, (the attendant can be heard) or monitor without speech path, to name the most relevant. It would not be impossible to substitute "someone with a computer and the know-how" in the place of the word "attendant", but don't overestimate this possibility. It's bragged about FAR more than it is actually done. But it remains a possibility. I'll continue this in successive messages, so it's in manageable chunks.

1 0

Re: CELP speech compression code at cygnus.com:/pub/celp.speech.tar.Z
by pmetzger＠shearson.com 07 Feb '93

07 Feb '93

> From: gnu(a)toad.com (John Gilmore) > > The code is up for FTP where you-all can get it. I made both compressed > and gzip'd versions (gzip gives smaller files than compress, is faster > to decompress, but slower to compress). > > -rw-rw-r-- 1 gnu cygnus 2571835 Feb 5 16:04 celp.speech.tar.Z > -rw-rw-r-- 1 gnu cygnus 2099441 Feb 5 16:09 celp.speech.tar.z > > Much of the tar file is samples of compressed and uncompressed speech, > (used for testing the code). The actual C code is about 340K uncompressed, > and there's also a Fortran version in there. > > I have a copy of the actual compression standard, but not online. > The Information Liberation Front is welcome to a copy -- maybe > I should just leave it on the table at the next meeting and hope someone > "anonymously" picks it up and scans it in. It's public domain, so > there's no special thrill from liberating it. It occured to me that some people might not get the significance of all this, so prehaps I ought to amplify. With the ability to compress speech down into the same baud rate as, say, a V.32 modem, all one would have to do to have perfectly secure voice communications is replace your phone with a setup that took in your speech, digitized it, compressed it, encrypted it, and sent it over the modem to the other side where this would be inverted. Fast enough software compression of voice would mean any PC with a DSP card and a V.32 modem could become an unbreakable scrambler. The chief problem is that the DSP needed to do decent compression is very crunchy, and encryption also tends to be crunchy, so there aren't typically enough cycles on your average PC. Of course, were someone to commercially market a board that did all this in hardware... Perry

4 3

It's the Information, (that keeps you from being) Stupid!
by Arthur Abraham 07 Feb '93

07 Feb '93

Charles E. Wareing writes: >I've heard (via Tv reports, reading, etc) that PhiberOptik (paraphrasing >here) "...knows more about Phone Systems than most Bell engineers". Why >on Earth would you respond the way you did, rather than: > > 1. Ignoring it > 2. Providing pointers to technical sources > 3. Refuting it with information. I strongly support this statement, particularly 3. -a2.

1 0

Re: White Mail
by Phil Karn 07 Feb '93

07 Feb '93

>E-MAIL RULING MAY HAMPER CLINTON ADMINISTRATION Hmm, I wonder what would happen if they start using PGP? After all, the Federal government has full rights to use RSA. (Dunno about IDEA). I have mixed feelings on this issue. On the one hand, the people have a right to know how government authority is being exercised. On the other hand, even people in government have privacy rights. And if you mandate that their email is a public record, then they will just find other ways to have private conversations. Maybe the real answer lies in not giving them so much power in the first place. Phil

1 0

PAX code posted
by dclunie＠pax.tpa.com.au 07 Feb '93

07 Feb '93

After many requests from loyal fans, I have posted the ugly and crude scripts that used to be the PAX anonymous and encrypted remailing service to alt.sources.

1 0