- cypherpunks-legacy - lists.cpunks.org

Mature Audience Only elm
by Nicole Kiddmen 09 Nov '02

09 Nov '02

1 0

Re: Debt termination
by Dale Hoff 09 Nov '02

09 Nov '02

1 0

Bulk Email Sending & Bullet Proof Web Hosting
by chriscafe 08 Nov '02

08 Nov '02

We offer you databases of e-mail addresses for advertisement mailing; we sell databases, carry out mailing the advertising projects. We can work on a turnkey project create a site with original design, contents. Our databases are daily updated with e-mail addresses from all over the world. Their validity and originality are verified. Today they contain over 50 million addresses. We use our own mailing be ideally adjusted for any customer. We have a wide channel and a high power server. The allows us to keep the prices low. http://www.e-mailpromo.net Please contact us. We�ll be glad to answer any questions. HTTP: www.e-mailpromo.net E-mail: info(a)e-mailpromo.net ICQ: 130982 We received your address from a public place. We apologies if this letter have reached you by mistake. We'll not disturb you any more. NB. This message is sent in compliance of the new email bill section 301. Under Bill S. US Congress. This message cannot be considered we include the way to be Removed, Paragraph (a)(c) of S. 1618. TO REMOVE: send message to info(a)e-mailpromo.net with "Remove" in Subject.

1 0

Don`t Miss Out: Name your price with NO obligation to buy!
by Great Deals 08 Nov '02

08 Nov '02

1 0

RE: Did you *really* zeroize that key?
by Patrick Chkoreff 08 Nov '02

08 Nov '02

>From: "James A. Donald" <jamesd(a)echeque.com> >... >If the optimizer ever optimizes away a write to volatile >memory, device drivers will fail. Most device drivers are >written in C. If anyone ever produces a C compiler in which >"volatile" does not do what we want, not only are they out of >spec, but smoke will start coming out of hardware when the >device drivers are recompiled. Good point #1. Excellent point, in fact. >From: "Dave Howe" <DaveHowe(a)gmx.co.uk> >... >Yup, granted. >however, saying after a security breach "this wasn't my fault, the compiler >was out of spec" isn't going to help much. >in the real world, murphys law applies more often than anyone elses; you can >virtually guarantee you will meet up *sometime* with an out of spec compiler >... Good point #2. Excellent point, in fact. So, given 1 and 2, it sounds like a good strategy might be: a. Declare your sensitive variables volatile and zero them normally. b. Check the assembler output because you have to do that anyway :-) c. If (b) exposes an out-of-spec compiler, report it far and wide to all available e-mail lists. Then preferably use a different compiler. If that's not an option, try the va_list trick and go to (b). -- Patrick http://fexl.com

1 0

[Anonymity, Blacknet, Mil secrecy] Photos in transport plane of prisoners
by Major Variola (ret) 08 Nov '02

08 Nov '02

Note that the Cypherpunks Image/Postscript Document Examination Laboratories should be able to amplify some of the (US; the unPOWs are black-bagged) faces in the pix.. Pentagon Seeks Source of Photos By PAULINE JELINEK Associated Press Writer WASHINGTON (AP)--The Pentagon was investigating Friday to find out who took and released photographs of terror suspects as they were being transported in heavy restraints aboard a U.S. military plane. Four photographs of prisoners--handcuffed, heads covered with black hoods and bound with straps on the floor of a plane _ appeared overnight on the Web site of radio talk show host Art Bell. ``Anonymous mailer sends us photos taken inside a military C-130 transporting POWS,'' the headline said. http://www.ocnow.com/news/newsfd/shared/news/ap/ap_story.html/Washington/AP…

1 0

Re: Did you *really* zeroize that key?
by Sunder 08 Nov '02

08 Nov '02

> Back in the early days of compiler benchmarks, one fancy compiler noticed > that the result of a lengthy calculation wasn't being used, and dutifully > removed the calculations. That calculation was, of course, the kernel of > the benchmark. The solution was to print the result. Or you do something like using binary OR from both ends of the memory chunk simultaneously, so when they finish, you're guaranteed to have 0xff (all 1's) all over your memory. This is off the top of my head, so bugs may exist, etc. int zapmem(uint8 *mem, size_t size) { int i,j,a,b; for (a=0xaa,b=0x55,i=0, j=size-1; i<size, i++,j--) { a|=mem[i]; mem[i]=a; b|=mem[j]; mem[j]=b; } return a|b; } At the end of the loop, mem will be 0xff. Why? Because we use OR, and since one half is using 010101 and the other half is using 10101010, as i,j pass each other and OR themselves, you're guaranteed to have 0xff (11111111) as output. You could also use 0xf0 and 0x0f or any other complementary values for the initial a and b values. There's a return value, the compiler has to return it, and thus can't easily optimize it out. I don't think there exist smart compilers that will figure out what this does - if you can write such a compiler that can figure out what you indend in all cases, you will be a very rich man. Of course if some compiler writer decides to make the above a special case and optimize it out, all bets are off.

1 0

RE: Did you *really* zeroize that key?
by Gil Hamilton 08 Nov '02

08 Nov '02

Peter Gutmann writes: >"James A. Donald" <jamesd(a)echeque.com> writes: > > >If the optimizer ever optimizes away a write to volatile > >memory, device drivers will fail. Most device drivers are > >written in C. If anyone ever produces a C compiler in which > >"volatile" does not do what we want, not only are they out of > >spec, but smoke will start coming out of hardware when the > >device drivers are recompiled. > >The people who assume that any compiler which compiles their code gets >an obscure feature like volatile exactly as per the spec are probably the >same ones who assume that fixed-size buffers will never be exceeded. I don't understand this extraordinary level of concern As both James and Perry have tried to point out, 'volatile' is *not* an obscure feature. Maybe it was obscure back in the mid-1980s, but every C compiler I've seen in years supports volatile. Its behavior has been part of the C std for a long time now, and it's a critical part of a large body of code on pretty much every platform. It's interesting that you bring up the subject of "fixed size buffers" being overrun. That also results from ignorance and carelessness on the programmer's part *not* from incorrect compiler implementation. >It's my job to be paranoid. I will assume that an arbitrary compiler >gets a while() loop right (it'd be obvious if it didn't), but I won't >gamble my crypto keys over assumptions about the correct handling of >volatile in all compilers. It sounds like the problem is more a lack of understanding of what 'volatile' means. Nowhere in this thread (or from what I can tell, the thread on vuln-dev) has anyone alleged that an actual compiler didn't handle 'volatile' correctly. - GH _________________________________________________________________ The new MSN 8: smart spam protection and 2 months FREE* http://join.msn.com/?page=features/junkmail

1 0

Re: Did you *really* zeroize that key?
by Patrick Chkoreff 08 Nov '02

08 Nov '02

At 02:22 PM 11/8/2002 +0000, Vincent Penquerc'h wrote: >while (!is_all_memory_zero(ptr)) zero_memory(ptr); Right, unfortunately the compiler might be insightful enough just to optimize that whole thing to skip() -- Dijkstra's null statement. Even Welschenbach calls "ispurged" immediately after "purgevars" to make sure the memory is actually zero. The ispurged routine is also defined using va_list, and if you turn on assertion checking it dies if the memory is nonzero. The problem is you NEVER KNOW if the compiler is just being clever and optimizing the assertion away, e.g.: sensitive = 0; if (sensitive) abort(); The compiler will simply "know" to optimize this whole thing to skip(). However, it is highly unlikely the compiler will be able to see through va_list manipulations. This problem is a real bear. I guess you just have to check the assembler output, eh? -- Patrick http://fexl.com

1 0

Aussies to censor web
by Major Variola (ret) 08 Nov '02

08 Nov '02

Ellison to pull plug on protest websites Sean Parnell and Matthew Fynes-Clinton 07nov02 THE Federal Government plans to stop Australians gaining access to websites used to organise protests. The move is part of a major crackdown on Internet-assisted crime. Justice Minister Chris Ellison, acting on a request from NSW Police Minister Michael Costa, will look at upgrading federal powers to block certain websites. A police ministers meeting in Darwin this week agreed it was "unacceptable websites advocating or facilitating violent protest action be accessible from Australia". <snip> http://www.couriermail.news.com.au/common/story_page/0,5936,5437553%5E8362,…

1 0