- cypherpunks-legacy - lists.cpunks.org

Re: SUMMARY: Not-so-volatile volatile memory
by tcmay＠got.net 17 Dec '03

17 Dec '03

At 9:54 AM 9/5/95, Anonymous wrote: >> -- Summary: Data retention in semiconductor memory -- >> >> Contrary to conventional wisdom, "volatile" semiconductor memory >> does not entirely lose its contents when power is removed. Both >> static (SRAM) and dynamic (DRAM) memory retain some information on >> the data stored in it while power was still applied. SRAM is >> particularly susceptible to this problem, as storing the same data >> in it over a long period of time has the effect of altering the >> preferred power-up state to the state which was stored when power >> was removed. Older SRAM chips could often "remember" the previously >> held state for several days. In fact, it is possible to manufacture >> SRAM's which always have a certain state on power-up, but which can >> be overwritten later on - a kind of "writeable ROM". > >Is this a new discovery? When I used to work with DOD classified >data, not so long ago, disk drives had to be declassified using an >approved program, such as Norton Utilities' "WIPEINFO". (That was >approved up through the SECRET/SAR level, anyway. I don't know >about TS/SCI/SI.) But those same regulations said that RAM was >considered declassified within a certain time (30 seconds, I think) >after power was removed. (That time figure was UNclassified, BTW.) >I think it was just to allow time for the voltage to bleed off of >the power supply's filter capacitors, and not related to the >relative volatility of DRAM. The Gutman article was discussing residual/remnant storage a lot more subtle than the usual "bleed-off" charateristics. One interesting twist is using radiation sources to "snapshot" or "freeze" the internal contents of dynamic RAM. I worked with DRAMs for more than a decade at Intel, though never on this particular issue. But I read a lot of the public papers on radiation effects on DRAMS, including the "freezing" of data patterns into DRAMs by exposure. (I recall thinking at the time, circa 1980, that someday raids on computers could involve bringing in flash radiation sources to "snapshot" the contents of DRAM.) Sandia Labs did a lot of the work on this, and results are reported at the annual Nuclear and Space Radiation Effects Conference. The December issue of "IEEE Transactions on Nuclear Science" every year includes the proceedings of this conference. Any large university library should have it. It's also possible to literally freeze a DRAM--with "Arctic Freeze" spray, for example--and stop the self-discharge of DRAM cells. I doubt any of these efforts are being used, though. Looking at how raided computers are simply carted off in the backs of pickup trucks, with disk drives thrown in with monitors, I suspect nothing this sophisticated has ever been tried. Quantico might have some more sophisticated approaches, but they're not publically discussing them. ---------:---------:---------:---------:---------:---------:---------:---- Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay(a)got.net 408-728-0152 | anonymous networks, digital pseudonyms, zero Corralitos, CA | knowledge, reputations, information markets, Higher Power: 2^756839 | black markets, collapse of governments. "National borders are just speed bumps on the information superhighway."

1 0

Re: VCRPLUS Huffman code
by Peter Trei 17 Dec '03

17 Dec '03

> Has anyone worked out the VCRPLUS code? It was partially broken a few years ago, and the results published in Cryptologia. I have a xerox in a carton somewhere. The break was for codes up to 4or 5 digits long, if I recall - this covers most of the major timeslots on the main stations. Longer codes cover odd timeslots on less popular stations. Code which implemented this partial crack was published on the net, and the VCR+ people got very upset about it - apparently they make money selling the codes to TV Guide and newspapers. It's protected as a trade secret, not a patent. It used a combination of lookup tables and Huffman codes, and included a certain amount of obfuscation to resist cracking. Peter Peter Trei Senior Software Engineer Purveyor Development Team Process Software Corporation http://www.process.com trei(a)process.com

2 1

Re: Non-US SSL128 site
by Peter Trei 17 Dec '03

17 Dec '03

> > a) Use 128 bit SSL if the client allows it. > > b) Tell users which cipher is being used on a secure session. > Netscape's press release on the RC4-40 crack seems to have disappeared from > their home page, but I don't remember any specific mention of 128-bit > U.S.-only clients, just servers. > So what's up? Netscape sells a 128-bit US-only client for $39 Peter Peter Trei Senior Software Engineer Purveyor Development Team Process Software Corporation http://www.process.com trei(a)process.com

4 3

"This discussion is off-topic, please take it elsewhere"
by tcmay＠got.net 17 Dec '03

17 Dec '03

At 5:58 AM 9/5/95, Sandy Sandfort wrote: >~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > SANDY SANDFORT > . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . > >C'punks, > >This is not a crypto post, but those interested in threat models >and counter-measures might want to read on. This brings up an important issue. Sorry it is not written in C, or even TCL. I actually agree with a point the noted tentacle VZNuri ("visionary," obviously) wrote, namely, that people are getting entirely too apologetic (myself included, though most of my "apologies" have had an ironic edge to them) about posting things that are other than about coding in C, writing sockets for Windows, or breaking SSL. Folks, this list is about a _lot more_ than just some facet of writing software. It started as a wide-ranging list, with many topics, many interests. I don't think I need to try to list the topics, but they obviously include things such as legal issues, policy, PGP, remailers, digital money, money laundering, regulatory arbitrage, data havens, steganography, languages, frameworks, Unix utilities, and dozens of other related topics. We've covered hundreds of topics, and are probably the only such list on the planet that routinely considers the ramifications and ways of actually building the exciting ideas that the academics at the Crypto conferences discover and write about. (I can tell you that one of the main motivations we (Eric and I) had in starting the group was to take the academic abstractions, things like "bit commitment" and "dining cryptographers networks" and reify them into actual blocks of code, or running programs.) Some have argued that "Cypherpunks write code," which has been a short slogan making it clear that one of our main interests is in actually building and deploying these methods. This was a major goal in the spring of 1992 when Eric (Hughes, for any newcomers) and I spent time hashing out what is needed in crypto. As far as I'm concerned, we're on track. Remailers have advanced far beyond the early remailers, and that they exist at all is an accomplishment. The "theory" of remailers is immensely accelerated by having actual remailers in actual use to test theories against and to see real world behaviors. Likewise, message pools have been built. A working anonymous market (BlackNet, for example) has been instantiated, albeit not proliferated. Digital money in various forms (Magic Money, work with Chaum's DigiCash, etc.) has been used. Lots of other examples. PGP, hooks to mail programs (though a lot more are needed), key escrow considerations, etc. Of course, things have gone more slowly in some areas than in others. Digital money, and financial instruments in general, have proceeded in fits and starts. I suspect this indicates that things like money are not done lightly, and that many non-coding issues are intertwined in such a way as to make any "amateur" efforts problematic. But it's only through trying that the obstacles can be seen, so even our failures are useful. Is this "writing code" in all cases? Of course not. Not everything is coding. Planning and preparing is just as important. And consideration of threat models is part and parcel of writing code, else one will not know where to start writing code. Thus, for example, the hundreds of posts here on key escrow (and some of us anticipated Clipper six months before it was announced, allowing the Cypherpunks to hit the ground running as soon as it was announced) and GAK are useful in countering the arguments of those who have spent years planning such escrow (GAK) policies. What I'm getting at is that the "Cypherpunks write code" mantra does not mean that _only_ the few dozen folks actively writing C code can contribute. Indeed, many of the folks now writing code have _claimed_ that they were inspired to write some code in some area--remailers, digital cash, SSL challenges, whatever--by the discussions here on this list. Would they have been so inspired if all political, legal, and cultural discussions had been expunged, if only the arcania of programming and C were being discussed? After all, sci.crypt already exists, and even sci.crypt.research, so why should the Cypherpunks list even exist, as these groups are already ostensibly focussed on pure crypto issues. No, Cypherpunks is about more than just C programming, about more than just IETF issues, about more than just algorithms. I think it great that so much programming discussion occurs, that so much progress is being made. I just think some list.cops are going a bit overboard in their denunciations of "off-topic" posts, and their increasing shrillness in saying that anyone not out there writing Unix crypto programs should stop posting. Those who only want to read about "malloc" and "struct" are encouraged to use the filtering tools which they surely have access to and to stop telling us in shrill voices that posts are "off-topic." --Tim May ---------:---------:---------:---------:---------:---------:---------:---- Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay(a)got.net 408-728-0152 | anonymous networks, digital pseudonyms, zero Corralitos, CA | knowledge, reputations, information markets, Higher Power: 2^756839 | black markets, collapse of governments. "National borders are just speed bumps on the information superhighway."

3 2

Re: SSL trouble
by Peter Trei 17 Dec '03

17 Dec '03

> >I did a distributed scheme for something else that had two levels, a master > >and a group of slaves. Only the slaves talked to the master. For this > >effort I think a variation of the idea would be better. Have all of the > >brutes contact the master, who will, in the first transaction assign them > >to the next slave in a round-robin fashion. > Why not just have the brutes pick a slave at random? Of course, you need > to give them a complete list of slaves to choose from. But then the only > difference between the master and the slaves will be that the master > doesn't get any keyspace (it's got it all to begin with) and doesn't > report any results upward. This is starting to sound like alt.sex.bondage.... Peter Trei Senior Software Engineer Purveyor Development Team Process Software Corporation http://www.process.com trei(a)process.com

1 0

approx of bignum^rational
by cman＠communities.com 17 Dec '03

17 Dec '03

Does anyone have a good method for approximating bignums raised rational exponents in the interval [0,1]? Thanks, Douglas Barnes Electric Communities

1 0

Scientology and police visit XS4ALL Amsterdam
by announce 17 Dec '03

17 Dec '03

From: XS4ALL Internet Postbus 22864 1100 DJ Amsterdam tel: +31 20 6222885 fax: +31 20 6222753 PRESS RELEASE ------------- Police and members of Scientology church enter offices of XS4ALL ================================================================ Amsterdam - thuesday september 5, 1995. Today at about 14:00, XS4ALL was visited by Mr. S. Braan, bailiff. He was acting on behalf of the Religious Technology Centre, better known as the Scientology Church, or Scientology for short. He was assisted by a local police officer and Mr. Hermans from the 'Nauta-Dutilh' legal firm that represents Scientology in The Netherlands. Also present were two computer experts (Mr. Ootjes and Mr. Van Suchtelen) a locksmith (to enter had we not been present) and two American employees of Scientology, Mr. Weightman and Ms. Jenssen. Scientology is filing for seizure of XS4ALL's computer equipment. Under dutch law, this means that a bailiff comes in to record your assets. In real-life, the computer-experts that were present have recorded the types and serial numbers of all the computers in our offices. They did not take any equipment, the continuity of XS4ALL's services is not in jeopardy. What is this all about? ----------------------- The Scientology Church claims that the XS4ALL anonymous remailer was used to disseminate documents over the Internet to which the church holds the legal copyright. This has led the church to ask the president of the district court of Amsterdam to grant permission for this seizure as a prelude to legal procedures concerning damages suffered by the church. The remailer in question has been disabled more than 2 months ago. During the visit of Scientology to XS4ALL this afternoon, the remailer was not the subject of any conversation. The organisation seemed totally preoccupied with the information about Scientology that one of our users has put on his home page. Part of this information is said to be a file to which Scientology holds the copyright. If we were to delete the file in question on the spot, they were willing to drop the seizure. Responsability of Internet Providers ------------------------------------ XS4ALL categorically denies any responsability for contents of users' homepages. The users decide for themselves what is on their homepage. Since XS4ALL does not edit the homepages and has no mechanism of control over the contents we strongly feel that the users themselves are responsible for what they say on their homepage. This whole affair demonstrates the need for clarity concerning the legal postion of Internet Providers. We are shocked that our offices can be invaded bij freshly flown-in U.S. cult members. If we as Internet providers are held responsible for what our users say, that will undoubtebly kill freedom of speech on the net. Scare-tactics ------------- XS4ALL is not alone in receiving this kind of attention from Scientology. Scientology, a semi-religious multinational, is at war with a number of people on the Internet. A non-organized group of people on the net has started to openly discuss the activities of the church. Until recently, the church has always managed to supress critical voices by means of sheer intimidation and by engaging in endless legal battle. One of the people that Scientology has a problem with is 'fonss', an XS4ALL user that publishes the F.A.C.T.-net Kit on his home page (http://www.xs4all.nl/~fonss) This kit (which can be found on numerous homepages all over the Internet) consists of a large number of documents that show the true face of Scientology. One of these documents is a piece to which Scientology supposedly holds the copyright and which has been added to the kit without the church's permission. Additional information can be found on the Internet: http://www.cybercom.net/~rnewman/scientology/home.html http://www.xs4all.nl/~fonss news:alt.religion.scientology news:alt.censorship news:alt.clearing.technology

1 0

Re: Emergency File Wipe Algorithim
by shamrock＠netcom.com 17 Dec '03

17 Dec '03

At 16:20 9/5/95, Andrew Loewenstern wrote: [...] >andrew >(wonders how many readers will take their keyboards apart to look for radio >transmitters) Been there. Done that. Hmm, come to think of it, it's about time for another check. -- Lucky Green <mailto:shamrock@netcom.com> PGP encrypted mail preferred.

1 0

Son of Clipper (commentary)
by Jim Gillogly 17 Dec '03

17 Dec '03

I didn't want to mix my comments with the recent discussion paper I sent along, so here they are separately. Please refer back to my last msg to see the points I'm bitching about. It's a depressingly restrictive list of things to require for software escrow encryption. I can only conclude that they're not serious. Clipper itself fails to meet many of them, including (I think) #1, #2, #5, and #6. Rumor has it that Clipper does not meet #9 either -- at Crypto '95 somebody in the Key Escrow session said many government Clipper keys are not escrowed, and somebody in the back spoke up and said he owned such a chip. By the way, Moti Yung (noted crypto guy at IBM Yorktown Heights) presented more breaks in Clipper's protocols like those Matt Blaze found, and pointed out some aspects of Matt's break that he thinks make it more important than previously thought. Other things that bother me about the list: #1: If it's escrowed, there should be no need to limit the key length unless somebody's planning to cheat. #3: This rules out the possibility of escrowing individual session keys to limit the access of LE to sessions they are entitled by law to intercept. #5: Care to tell us how to create software that can't be patched? This is one that's been played in the marketplace and has lost. The battle between copy protectors and crackers has been decided in favor of the crackers: legitimate users largely refuse to buy packages that are too messy to deal with (e.g. they leave hidden files all over the disk, which may interfere with backups or other programs) or that use special purpose hardware (e.g. dongles that eat up a printer port). This one's a loser, I think. #6: This is clearly a research issue. Several speakers (even pro-GAK) at Crypto '95 said the policy decisions are being made before the research has been done. The protocols and system specifications are key here, and it's not obvious how this criterion can be met. It's not obviously impossible, but it certainly hasn't been solved in Clipper. #7: One of the Crypto '95 attacks on the Clipper protocol makes use of this misfeature of Clipper. It allows a broadening of the net of captured keys so that many more unauthorized messages may be read. #8: See #3 above -- let's wait on the policy decision until we have a policy debate. A mandated compromise is an oxymoron. I (for one) would prefer to see much more limited keys (like session keys) if Congress decides that the right to privacy is not infringed by these technologies. There's nothing in here that specifically excludes dividing your keys among multiple escrow agents; I assume this is still an open issue still, or that it goes without saying (one way or the other). #3 and #6 make it impossible to prevent LE from reading messages from before or after their legally authorized window. This is clearly broken. Again, this appears to be trying to put all the power in the hands of LE to the detriment of the people. It's advertized as a compromise, but I see nothing gained over Clipper I. The only differences appear to be that the escrow agent(s) may be private instead of government, and the algorithms may be something other than SKIPJACK as long as they are at least 16 bits weaker as well as being known algorithms. It also doesn't address the main problem with Clipper I: that it wouldn't work, since (like Clipper I) it will catch only crooks who are smart enough to encrypt but stupid enough to encrypt with a system they (should) know LE can read -- probably a null set. If, on the other hand, this is made mandatory for encrypted transmissions, it will create a new and unnecessary class of criminals, probably including myself (though I won't promise to break any laws at this point). This really burns me up. What do they think they're doing here? Am I missing a big piece of it? Jim Gillogly Hevensday, 14 Halimath S.R. 1995, 22:02

1 0

RE: VCRPLUS Huffman code
by James A. Tunnicliffe 17 Dec '03

17 Dec '03

>On Tue, 5 Sep 1995, Peter Trei wrote: > >> >> > Has anyone worked out the VCRPLUS code? >> > > <chomp> > >> Code which implemented this partial crack was published on the net, >> and the VCR+ people got very upset about it - apparently they make > > I believe the code is in the cookbook archive at ftp.ee.ualberta.ca, >but when I just tried to confirm I got timeouts. > > Brian Among many other places, you can get this off my Web page, in: http://www.inference.com/~tunny/crypto/primer.html - Tunny ______________________________________________________________________ James A. Tunnicliffe | WWWeb: http://www.inference.com/~tunny Inference Corporation | PGP Fingerprint: CA 23 E2 F3 AC 2D 0C 77 tunny(a)Inference.com | <--finger for key 36 07 D9 33 3D 32 53 9C ======================================================================

1 0