December 2003 - cypherpunks-legacy

RE: David Downey asks to be shot
by David Downey 17 Dec '03

17 Dec '03

Wow, I'm really moving up in the world. Now I've officially been classified as an enemy of the people. Cool! Where's my award money? ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com

3 2

Re: anyone know what this "top secret" code does? Re: anyone know what this "top secret" code does?
by anon-remailer＠utopia.hacktic.nl 17 Dec '03

17 Dec '03

hallam(a)zorch.w3.org (Phillip M. Hallam-Baker) wrote: > The code looks more than a casual hoax. Its not Skipjack, but that > does not mean its not NSA originated. Its probable that many of the > people who designed skipjack don't know its skipjack. If you read > the code carefully it is obvious why its not skipjack, an S2 > algorithm is referenced explicitly. [...] > Regardless about whether or not it is skipjack it challenges one of > the basic assumptions of many cipher designers, namely that the > amount of diffussion should be maximized at each round. I am now > very much less than convinced that this is in fact an issue. The S1 > design with its narrow diffussion provides very strong guarantees > that one round cannot undo the work of the previous one. > S1 must therefore be considered to be a significant contribution to > the cryptographic community. It has challenged a fundamental tenet of > faith which has so far been accepted without argument. It is thus > paradigmatic in that it may lead to a new method of cipher design. Does anyone remember the scenario someone suggested awhile back that hypothesized a scheme by the NSA or other TLAs to encourage the use of WEAK crypto? It involved spreading a lot of F.U.D. about PGP and other strong crypto methods, followed by the discovery/leak of a supposedly "strong" crypto algorithm to replace it. This may not be it. It may just be a trial balloon to gauge the reaction of the crypto community to an anonymous, "gift from heaven" crypto algorithm. But at least be aware of what COULD happen. One tactic that might be tried is an intentional "leak", followed by a flurry of legal actions designed to make it look like the "leak" was going to cause some real damage to their cryptanalysis efforts, due to it being "unbreakable", or whatever. Of course, anything "leaked" would be crippled in some undetectable manner so as to provide a back door...

1 0

VoicePGP Query
by Deranged Mutant 17 Dec '03

17 Dec '03

Due to some acct. problems I lost most of the mail snet to me betw. May and September. I saw a post in a newsgroup about VoicePGP betas being available, though only for Mac and WIn'95... is this true? And if so, will there be a Win 3.11 or OS/2 or DOS version out eventually? I don't intend to get Win '95 for as long as I can avoid it (and this is NOT the start of an OS flame war...) Also, what's the status of PGP 3.0? Thanks, Rob

1 0

Re: Anonymous Remailers
by nobody＠REPLAY.COM 17 Dec '03

17 Dec '03

Robert A. Costner wrote: > > In Georgia, while we have won a temporary injunction and assume we will see the law fully struck down, EFGA is still involved in lawsuit against the state over internet anonymity. I actually don't contemplate another affidavit in this case, but it may happen. If I need to write another affidavit in support of the remailer, I will only have about two weeks to get it done. Don't write an affidavit, write an indictment. Say, perhaps, an indictment of our founding fathers for their use of anonymity, as well as tacking a "use of crypto in commission of a crime" charge on to the indictment. You can site Paul Revere's use of cryptography ("one if by land, two if by sea) to implicate the whole bunch in a drug dealing child pornography ring. Perhaps you might even want to trace the founding fathers' use of anonymity and strong-lantern encryption to the moral corruption existing today. LanternMonger "The founding father of drug dealing child pornography rings."

1 0

Re: MIT distributing PGPfone -Reply
by terrell＠sam.neosoft.com 17 Dec '03

17 Dec '03

>PGPfone was out of the U.S. less than 3 hours after first appearing >publically at the MIT site. > >As I noted in a previous message, MIT takes various steps to ostensibly >protect against export, but there is clearly no practical means of stopping >export once the software has been received by someone. > >I got my copy of PGPfone 16 hours after its public release, via an >anonymous person who posted it on the Cypherpunks list through an anonymous >remailer. Of course that list is distributed to more than 20 foreign >countries, so "export" happened that way, as well as by other means. > >--Tim May > As tim May's .sig should say: "National borders are not even speed bumps on the information highway." Buford C. Terrell 1303 San Jacinto Street Professor of Law Houston, TX 77002 South Texas College of Law voice (713)646-1857 terrell(a)sam.neosoft.com fax (713)646-1766

1 0

Re: PGPfone over Appletalk
by Hal 17 Dec '03

17 Dec '03

From: "Rev. Mark Grant" <mark(a)unicorn.com> > Can someone tell me how to run PGPfone over Appletalk ? The > documentation says that support has been added for this release, and > there's a preferences box to check to use it, but there's no information > I can find in the documentation on how to initiate a call over > Appletalk.. it just says to enter a telephone number to dial. If I > press 'Connect' without entering anything it hangs up the Mac. > > How do I tell it which machine I want to connect to ? I changed the preferences box setting, but then I exited and restarted the program so that it came up in "appletalk" mode. This is probably the step you are missing. I did this on two different machines, and then when I clicked connect it no longer tried to open the modem, instead it put up a dialog box allowing me to click on the machine running the other PGPfone. I did that and it connected OK. There is a nice audio simulation of an old-fashioned telephone bell ringing. Unfortunately my appletalk "network" consists solely of my power mac and an old 68030 mac laptop, the latter apparently being underpowered for PGPfone. The voice quality changed occasionally as the software adaptively tried different coders, and the powermac instance of the program finally printed a message saying that the list of coders had been exhausted. Hal

1 0

Quickly checking signatures
by Hal 17 Dec '03

17 Dec '03

Let me describe Shamir's method for quickly doing a probabilistic signature check. Since this was a rump session paper he didn't have it written up. Shamir uses a variation of the Rabin system. The Rabin encryption system is similar to RSA, but instead of exponents which are relatively prime to the predecessors of the factors of the modulus, the exponent used is 2. This requires somewhat different techniques. A message M is encrypted by doing M^2 mod n. The decryption is then done by taking the modular square root. There are a few technical hitches that occur here but nothing major. Similarly a message M is signed by calculating its modular square root S such that S^2 = M mod n. Note that with Rabin you can't just sign any arbitrary number as that may allow the factors to be revealed. However this is not a major problem because practical systems in use today sign specially padded hashes, not arbitrary numbers. Now Shamir uses a slight modification to this. Normally we have: S^2 = M mod n This can be written as: S^2 = M + C*n for some C, which is simply the definition of modular equality. Now, what he suggests is that instead of sending S as the signature of M, you send C. This is justified on 3 grounds: - C is the same size as S - C has the same security as S (knowing M and n you can derive C from S and vice versa) _ C and S are equally easy to generate However, by sending C as the signature of a message M it allows a fast screening to be done. The idea is that the message should be accepted if M+C*n is a perfect square (because then S can be derived as the normal square root - that is how you get S from C as mentioned above). And this is something that can be checked quickly. In number theory there is a notion of a "quadratic residue" modulo some number. If a number is a quadratic residue that simply means that it has a square root, that it is the square of some other number using the modulus. With a prime modulus half of the numbers are quadratic residues and half are not. For example, with modulus 7 the q.r.'s are 1, 2 and 4 and the non q.r.'s are 3, 5, and 6. It turns out that testing whether a number x is a quadratic residue modulo a prime p can be done by calculating x^((p-1)/2) mod p. This will be 1 if and only if x is a q.r. Now, the key idea is this: if a number is a perfect square then the result of taking that number modulo a prime must be a quadratic residue. This means that we can quickly determine that C is a perfect square by checking whether C mod p for various random small primes p is a quadratic residue. By picking p to be a single precision prime of say 16 bits, the q.r. calculation can all be done without using multiple precision arithmetic and so it will be very fast compared to actually checking a signature. So, the procedure for the check is as follows: given n, M and C, choose a small prime p and calculate M+C*n mod p. Then raise this to the (p-1)/2 power mod p and see if the answer is 1. If it is, we give a "provisional" acceptance to the signature. If it is not, we reject the signature; it cannot be valid. This test may be repeated a few times with different values of p to improve the rejection of bad signatures. Once we have taken the input numbers mod p the rest of the arithmetic can be done with ordinary single precision integer variables. (One thing I overlooked is the possibility that M+C*n will be a multiple of p. In that case M+C*n mod p will be 0 and this is a provisional pass.) Of course checking the signature the old-fashioned way just takes a single multi precision multiplication, which won't be all that slow. So this puts a limit on the number of p's you can check this fast way before it becomes slower. Also, you'd have to choose the primes at random as otherwise an attacker who knew your p's could conjure up a C which would produce a quadratic residue for some small number of known p's. Hal

1 0

Re: David Downey asks to be shot
by nobody＠REPLAY.COM 17 Dec '03

17 Dec '03

Tim May wrote: > > At 6:23 AM -0700 8/19/97, David D.W.Downey wrote: > >blackjack(a)hotmail.com wrote: > >> Saw your post in the newsgroups. > >> Check this out! > > Ya know, this shit really pisses me off. I understand that we have to > >protect everyone's rights if we wish are own to be protected. > > I understand that we have to protect the enemies' > >rights too, but can't we just shoo a few of them first? Lowers the > >numbers needing protection and might help us out in the end. > I agree. We should shoot a few of the enemies first. > I suggest you be shot. Better yet, let's shoot the people "needing protection." Once they're dead, there will be no need for all those laws designed to protect them. What a brilliant idea! I'll probably get the Nobel Peace Prize for this one! FuckingForVirginityMonger

1 0

SUMMARY: Not-so-volatile volatile memory
by pgut01＠cs.auckland.ac.nz 17 Dec '03

17 Dec '03

About a month ago, I asked for comments about recovering data from semiconductor memory after power had been removed. After much procrastinating, I've finally finished the summary of what people sent me. Many thanks to everyone who responded, in particular to Bob Hale for answering many questions about the possibility of recovering data from DRAM's. If anyone has any further comments to add to this (I'm particularly interested in actual figures for data retention in DRAM cells, although I've been told this is burn-before-reading proprietary information), you can send it to me at the above address. Peter. -- 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". DRAM can also "remember" the last stored state, but in a slightly different way. It isn't so much that the charge (in the sense of a voltage appearing across a capacitance) is retained by the RAM cells, but that the thin oxide which forms the storage capacitor dielectric is highly stressed by the applied field, or is not stressed by the field, so that the properties of the oxide change slightly depending on the state of the data. One thing that can cause a threshold shift in the RAM cells is ionic contamination of the cell(s) of interest, although such contamination is rarer now than it used to be, because robotic handling of the materials and the purity of chemicals is greatly improved. However, even a perfect oxide is subject to having its properties changed by an applied field. When it comes to contaminants, sodium is the most common offender - it is found virtually everywhere, and is a fairly small (and therefore mobile) atom with a positive charge. In the presence of an electric field, it migrates towards the negative pole with a velocity which depends on temperature, concentration of the sodium, the oxide quality, and the other impurities in the oxide such as dopants from the processing. If the electric field is zero and, given enough time, the sodium contamination tends to spread itself around evenly. Other factors which affect the rate of change are temperature, the field strength of the stored charge, the quality of the oxide, and the concentration of dopants and other impurities which have already been mentioned above. The stress on the cell a cumulative effect, much like charging an RC circuit. If the data is applied for only a few milliseconds then there is very little "learning" of the cell, but if it is applied for hours then the cell will acquire a strong (relatively speaking) change in its threshold. The effects of the stress on the RAM cells can be measured using the built-in self test capabilities of the cells, which provide the the ability to impress a weak voltage on the storage cell in order to measure its margin. Cells will show different margins depending on how much oxide stress has been present. Many DRAM's have undocumented test modes which allow some normal I/O pin to become the power supply for the RAM core when the special mode is active. One way to activate the special test mode might be to underdrive a pin and turn on its protection diodes(s), which will be recognized internally and will change a multiplexer so that the core is powered by some pin which is normally a digital I/O pin. Another way, if the DRAM has suitable clocks, is to recognise an invalid combination of clocks (such as CAS before RAS, if the DRAM doesn't use that mode for higher speed operation) to enable the test mode. Great care must be taken to ensure that the test mode isn't inadvertently entered so that the memory system appears to be malfunctioning (for example in the first case if the system has substantial undershoot at the wrong time, the test mode could be activated). This problem can be avoided by designing the test mode signals such that a certain set of states which would not occur in a normally-functioning system has to be traversed to activate the mode. Manufacturers won't admit to such capabilities in their products because they don't want their customers using them and potentially rejecting devices which comply with their spec sheets, but have little margin beyond that. One way to speed up the annihilation of stored bits in semiconductor memory is to heat it. Both DRAM's and SRAM's will lose their contents a lot more quickly at Tjunction = 140C than they will at room temperature. Several hours at that temperature with no power applied will clear their contents sufficiently to make recovery difficult. Conversely, to extend the life of stored bits with the power removed, drop the temperature below -60C (some people even claim that you can permanently "imprint" an SRAM with its stored bits by rapidly cooling it below liquid nitrogen's boiling point). In any case it should lead to weeks, instead of hours or days, of data "retention". Simply repeatedly overwriting the data held in DRAM with new data isn't nearly as effective as it is for magnetic media. The new data will begin stressing or relaxing the oxide as soon as it is written, and the oxide will immediately begin to take a "set" which will either reinforce the previous "set" or will weaken it. The greater the amount of time that new data has existed in the cell, the more the old stress is "diluted", and the less reliable the information extraction will be. Generally, the rates of change due to stress and relaxation are in the same order of magnitude. Thus, a few microseconds of storing the opposite data to the currently stored value will have little effect on the oxide. Ideally, the oxide should be exposed to as much stress at the highest feasible temperature and for as long as possible to get the greatest "erasure" of the data. Unfortunately if carried too far this has a rather detrimental effect on the life expectancy of the RAM. Therefore the goal to aim for when sanitising memory is to store the data for as long as possible rather than trying to change it as often as possible. Conversely, storing the data for as short a time as possible will reduce the chances of it being "remembered" by the cell. Based on tests on DRAM cells, a storage time of one second causes such a small change in threshold that it probably isn't detectable. On the other hand, one minute probably is detectable, and 10 minutes is certainly detectable. The most practical solution to the problem of DRAM data retention is therefore to constantly flip the bits in memory to ensure that a memory cell never holds a charge long enough for it to be "remembered". While not practical for general use, it is possible to do this for small amounts of data such as encryption keys.

1 0

Unclear on Bell / Re: The Real Bell Issue / Re: Bell, etc
by nobody＠REPLAY.COM 17 Dec '03

17 Dec '03

Tim May wrote: > One lesson, or reminder, I take from the Bell matter is this: > > Avoid doing stupid and petty things like using multiple Social Security > numbers, evading taxes, and releasing stink bombs into government (or > other) offices. > > (These are things Bell has pled on, as I recall the transcripts, so > there's little doubt about them. And had he pled not guilty and gone to > trial, apparently the evidence would've convicted him on most of the > charges. Perhaps this is why he pled.) I am unclear on something. Did the government imprison without bail a citizen who evaded taxes and made a government office smell bad, or did the government allow a terrorist who was actively plotting to overthrow the government to plead guilty to inconsequential charges? If I get arrested for plotting to Nuke D.C., should I hire Bell's lawyer and try to get it reduced to jaywalking? Or should I avoid jaywalking to prevent getting arrested for plotting to Nuke D.C.? ???Monger

1 0