- cypherpunks-legacy - lists.cpunks.org

RE: End-to-end encrypting US GSM phones?
by Steve Schear 31 Dec '01

31 Dec '01

At 01:26 PM 12/31/2001 -0500, Trei, Peter wrote: > > Lucky Green[SMTP:shamrock@cypherpunks.to] >for the Ipaq, however, I suspect that this is a temporary phenomenon. MS >is giving away it's development environment for free, and as pointed out, >there is are several Linux ports. The higher cost of PocketPC devices can >be balanced against their higher power. If platform portability is desired why not use QT? I believe there are ports to both Linux and Windows (including CE). steve

1 0

RE: End-to-end encrypting US GSM phones?
by Steve Schear 31 Dec '01

31 Dec '01

At 11:59 AM 12/31/2001 -0500, Trei, Peter wrote: >Ryan suggested earlier that the Ipaq with Fireball isn't up to the task. >I don't think this is correct. I point you to > >http://www.stanford.edu/class/cs344/staff/group10/final_report.pdf > >in which some Stanford students produce a wireless ipaq2ipaq >VoIP system. Biggest problem is that it's simplex, not because >of cpu limitations but rather that the Compaq HW can listen or >make noise, but not both simultaneously. Using a headset which >interfaces through the expansion port might enable you to >avoid this problem (and the BT headset could also offload the >codec). A 206 MHz Ipaq would, I think have sufficient HP to >do the crypto. Agreed. The port expander approach should be explored. Also needed is WinModem control for smooth analog (clear) to digital (crypto) transition. >I've toyed with the idea of porting SpeakFreely to Ipaq, but have >not actually done anything at this point. Several developers, including an ex-Starium engineer, and I have been talking about just such venture. I sure between all of us we have the wherewithal to make this happen. Besides the half-duplex problem some changes to the SF protocol are desired to work better with SOHO firewalls now common. steve

1 0

Re: End-to-end encrypting US GSM phones?
by Ryan Lackey 31 Dec '01

31 Dec '01

Actually, the ipaq *does* support full duplex audio now. PocketPC 3.0 doesn't, but compaq has provided a driver for WinCE, and the linux distribution supports it too. PocketPC supports an application called "Microsoft Portrait" and msn messenger for voice over ip. To provide maximal end-user benefit, the thing to do is probably put strong crypto into msn messenger/ms portrait, on desktop and handheld. "Off the shelf hardware" is pretty meaningless to users if they need to do the linux handheld install; I've tried before and even if you know a fair bit about linux, it takes over an hour, and is somewhat risky. Whereas if it's just a "download this app and it works" thing, it's a lot easier to get casual users. http://research.microsoft.com/~jiangli/portrait/ is the microsoft portrait page. It's MS Research, not MS MS, so it may not suck. Someone should probably contact the guy and see what's up. If they would support an open-source client, and add crypto to the protocol, it might be good. -- Ryan Lackey [RL7618 RL5931-RIPE] ryan(a)havenco.com CTO and Co-founder, HavenCo Ltd. +44 7970 633 277 the free world just milliseconds away http://www.havenco.com/ OpenPGP 4096: B8B8 3D95 F940 9760 C64B DE90 07AD BE07 D2E0 301F

1 0

RE: End-to-end encrypting US GSM phones?
by Trei, Peter 31 Dec '01

31 Dec '01

> Lucky Green[SMTP:shamrock@cypherpunks.to] > > > Ryan wrote: > > "Everyone" has palm pilots already. WinCE-based PocketPCs > > haven't made much of a dent in the marketplace. There is > > also a very large developer community for palm apps, and > > they're widely deployed in > > corporations. > > I am not sure that the existance of a large developer community has much > bearing on the suitability of Palm as an encrypting phone platform. As > for the hardware, it simply is underpowered. You can spend man-months > trying to fight the current underpowered Palm platform or you can use > the sufficiently-resourced PowerPC platform. Since I don't believe that > there is a requirement for the feature to operate on a device already in > the user's possession, I know what my choice would be. YMMV. > It's a fact that there is a much larger developer community for the Palm than for the Ipaq, however, I suspect that this is a temporary phenomenon. MS is giving away it's development environment for free, and as pointed out, there is are several Linux ports. The higher cost of PocketPC devices can be balanced against their higher power. Let's remember that for a specific app, we don't actually *need* more than one programmer. > > If you're assuming users will buy a dedicated device *and* > > put linux on it, that's reasonable (or sell pre-packaged > > systems). Otherwise, you also need to develop for WinCE on > > the PocketPC. > > The OS is really of secondary or tertiary concern here. The more > important question is which (if any) handheld hardware supports > full-duplex audio. Do we know for fact that the lack of full duplex > audio support on the VoIP handheld demo is due to lack of support in the > HW or could it be a lack of support in the WinCE OS? > I could care less if I have to program under WINCE or Linux; some OSs require a bit more learning before I'm productive, but any programmer who can't pick up another environment quickly isn't worth his salt. Doing it under WINCE (or both Linux and WINCE) has the advantage that the app develops a user base much more quickly. As for hardware limitations; I havent verified this independently, but this is from the Stanford project cited earlier: > "An investigation of the audio capture and playback capabilities of the Compaq iPAQ revealed that the speaker and microphone on the PDA are the same hardware device, and cannot both be in use at the same time. As a result, the system had to be engineered such that only one of audio playback and audio capture happens at any one time." > --Lucky > Peter ============================================================================ ================ This e-mail, its content and any files transmitted with it are intended solely for the addressee(s) and are PRIVILEGED and CONFIDENTIAL. Access by any other party is unauthorized without the express prior written permission of the sender. If you have received this e-mail in error you may not copy, disclose to any third party or use the contents, attachments or information in any way, Please delete all copies of the e-mail and the attachment(s), if any and notify the sender. Thank You. ============================================================================ ================

1 0

Have good credit? FREE Credit report!!!
by creditguy＠einstein.ssz.com 31 Dec '01

31 Dec '01

1 0

Re: End-to-end encrypting US GSM phones?
by Ryan Lackey 31 Dec '01

31 Dec '01

Quoting Trei, Peter <ptrei(a)rsasecurity.com>: > I don't quite understand why getting encrypted VoIP working on a Palm Pilot > (16-33 MHz dragonball) is the 'Holy Grail'. I would have said that the HG is > an affordable, working, portable and pocketable encrypted VoIP system with > free software, regardless of platform. The Ipaq is 2-300$ more than a Palm > device, but is that the whole issue? Ipaqs have much better cpu power > and memory, and decent Linux ports. Go for the low-hanging fruit first. "Everyone" has palm pilots already. WinCE-based PocketPCs haven't made much of a dent in the marketplace. There is also a very large developer community for palm apps, and they're widely deployed in corporations. If you're assuming users will buy a dedicated device *and* put linux on it, that's reasonable (or sell pre-packaged systems). Otherwise, you also need to develop for WinCE on the PocketPC. I still would like to see from someone who is good at integer voice encoding whether a 33MHz dragonball can do tolerable-quality voice at 14.4kbps; I'm sure it's good enough to distinguish "ki" from "eight-ball", but I'd like something good enough to distinguish "weight, y'all" from "eight-ball" Since it's very unlikely any pda will have full duplex audio anytime soon, I think the bluetooth headset is the only viable solution; I'm going to get one for my t39m soon enough, and then I'll experiment with linux bluetooth support and try to get bluetooth audio integrated into OSS on my laptop, as a proof of concept. That done, it's just a question of running linux on an ipaq for a simple demo, with libgsm compiled as integer; then maybe something more efficient. I'm pretty sure someone has made the bluetooth headset work with linux already, so it's just a question of kernel patches. The security of this would depend somewhat on the bluetooth encryption, although I'd be happier trusting unencrypted but low-propagation bluetooth vs. a PSTN/cell link. -- Ryan Lackey [RL7618 RL5931-RIPE] ryan(a)havenco.com CTO and Co-founder, HavenCo Ltd. +44 7970 633 277 the free world just milliseconds away http://www.havenco.com/ OpenPGP 4096: B8B8 3D95 F940 9760 C64B DE90 07AD BE07 D2E0 301F

2 1

RE: brinworld, sexchart
by Trei, Peter 31 Dec '01

31 Dec '01

Well, that's cute, but there were non-internet versions in SF fandom over twenty years ago. I suppose the compiler will now seek a business method patent on this 'new invention'. Peter Trei > ---------- > From: David Honig[SMTP:honig@sprynet.com] > Sent: Saturday, December 29, 2001 11:35 AM > To: cypherpunks(a)lne.com > Subject: brinworld, sexchart > > Wired interview with creator of sexchart > http://wired.com/news/culture/0,1284,48997,00.html > > The graph: > http://www.attrition.org/hosted/sexchart/sexchart.9.25 > > Relevence to Brin's _Transparent Society_ etc should be obvious. > > > > > ============================================================================ ================ This e-mail, its content and any files transmitted with it are intended solely for the addressee(s) and are PRIVILEGED and CONFIDENTIAL. Access by any other party is unauthorized without the express prior written permission of the sender. If you have received this e-mail in error you may not copy, disclose to any third party or use the contents, attachments or information in any way, Please delete all copies of the e-mail and the attachment(s), if any and notify the sender. Thank You. ============================================================================ ================

1 0

Clarification for cpunks_anon@einstein.ssz.com
by Jim Choate 31 Dec '01

31 Dec '01

This alias into the CDR is NOT intended as a general anonymizing feature (irrespective of whether I happen to delete logs or not). It is ONLY meant to obfuscate the source of traffic from current list subscribers (not parties outside the list which might be using technical or other means to execute traffic analysis). If you need true anonymity then please consider using the following: - Always(!) use 'throw away' or 'one shot' accounts. NEVER use the same account or physical access point twice. NEVER use an account you pay for with a check or credit card. Remember that video is quite prevelant in todays society so be aware that identifying the location of the source, even if financial instruments aren't used, may be sufficient to identify you. - Use an anonymizing service outside of the SSZ domain to increase the points of attack required to uncover the source. - Modify your text style; review favorite words or phrases and avoid them completely. If possible run your text through a translation service (eg source -> Spanish -> source) and then edit the resultant. If you do use an online translation service use an anonymizing service for this access as well. - Don't use sig's and such. - Avoid closed source software as there is a history for this class of technology to add identifying items to the material they generate. In an ideal world you would compile the source yourself after reviewing the source code (including the compiler mind you). However, given the general state of technical skills, this is not likely. One approach might be to take binaries, of the same rev level and compiled with the same compiler and library rev's, of a given tool from different sites and then compare them for any differences. -- ____________________________________________________________________ Day by day the Penguins are making me lose my mind. Bumper Sticker The Armadillo Group ,::////;::-. James Choate Austin, Tx /:'///// ``::>/|/ ravage(a)ssz.com www.ssz.com .', |||| `/( e\ 512-451-7087 -====~~mm-'`-```-mm --'- --------------------------------------------------------------------

1 0

RE: End-to-end encrypting US GSM phones?
by Trei, Peter 31 Dec '01

31 Dec '01

> ---------- > From: Steve Schear[SMTP:schear@lvcm.com] > Sent: Sunday, December 30, 2001 5:32 PM > To: Lucky Green > Cc: cypherpunks(a)lne.com > Subject: Re: End-to-end encrypting US GSM phones? > > At 09:19 PM 12/30/2001 +0100, you wrote: > >On Sat, 29 Dec 2001, Ryan Lackey wrote: > > > > > I'm unclear why Lucky dislikes the Sectra Tiger (www.sectra.se) the > > > key management is not what I'd like, but seems designed specifically > > > for hierarchical military or corporate organizations, which is the > only > > viable > > > market for a EUR 2500 encrypting cellphone. > > > >The reason why I have little faith in the Sectra Tiger is because I > talked > >with one of Sectra's head cryptographers. Below is a brief recap of the > >conversation: > > <recap with clueless crypto engineer deleted> > > OK, so why don't we pool our funds to encourage the reverse engineering > and > release of source code to a popular PCS/GSM phone which can be readily > re-flashed and with sufficient resources (or easily augmented) to handle > this app? I'll donate $100 e-gold to get the fund going. I'll establish a > > publicly viewable e-gold account to hold other contributions. The account > > access key can be secret shared among a few fellow CPs. > > steve > Ryan suggested earlier that the Ipaq with Fireball isn't up to the task. I don't think this is correct. I point you to http://www.stanford.edu/class/cs344/staff/group10/final_report.pdf in which some Stanford students produce a wireless ipaq2ipaq VoIP system. Biggest problem is that it's simplex, not because of cpu limitations but rather that the Compaq HW can listen or make noise, but not both simultaneously. Using a headset which interfaces through the expansion port might enable you to avoid this problem (and the BT headset could also offload the codec). A 206 MHz Ipaq would, I think have sufficient HP to do the crypto. I've toyed with the idea of porting SpeakFreely to Ipaq, but have not actually done anything at this point. I've x-posted to coderpunks, since that group is more germane. Serious further discussion should be over there, IMHO. Peter Trei ============================================================================ ================ This e-mail, its content and any files transmitted with it are intended solely for the addressee(s) and are PRIVILEGED and CONFIDENTIAL. Access by any other party is unauthorized without the express prior written permission of the sender. If you have received this e-mail in error you may not copy, disclose to any third party or use the contents, attachments or information in any way, Please delete all copies of the e-mail and the attachment(s), if any and notify the sender. Thank You. ============================================================================ ================

1 0

Slashdot | The Year in Internet Law
by Jim Choate 31 Dec '01

31 Dec '01

http://slashdot.org/articles/01/12/31/0451244.shtml -- -- ____________________________________________________________________ Day by day the Penguins are making me lose my mind. Bumper Sticker The Armadillo Group ,::////;::-. James Choate Austin, Tx /:'///// ``::>/|/ ravage(a)ssz.com www.ssz.com .', |||| `/( e\ 512-451-7087 -====~~mm-'`-```-mm --'- --------------------------------------------------------------------

1 0