November 2002 - cypherpunks-legacy

AECWorkForce Professional News (November 8, 2002)
by AECWorkForce Professional News 08 Nov '02

08 Nov '02

=========================================================================== AECWorkForce Professional News Where great careers in design and construction are built http://www.AECWorkForce.com ========================================================================== Friday, November 8, 2002 THIS WEEK 1. JOB SEARCH STRATEGIES - RESIGNING PROFESSIONALLY 2. AEC CAREER TRENDS - STAYING ON TOP OF THE JOB MARKET 3. CAREER MENTOR - "IS THIS GOING TO BE ON THE TEST?" 4. HOT FIRM - TRANSYSTEMS CORPORATION 5. HOT JOBS - MORE HOT LISTINGS FROM AECWORKFORCE.COM Questions about your subscription to AECWorkForce Professional News? Check the end of this message for information. *********************************************************** 1. AEC JOB SEARCH STRATEGIES RESIGNING PROFESSIONALLY So you've finally decided to quit your lousy job. Here are some tips on how to keep your professionalism intact during your resignation. MORE: http://www.aecworkforce.com/magazine/jobsearch/current.htm 2. AEC CAREER TRENDS STAYING ON TOP OF THE JOB MARKET Today, more and more qualified, experienced professionals are actively testing the job market to see what it has to offer-while they're still employed. Learn why that's not a bad idea. MORE: http://www.aecworkforce.com/magazine/careers/current.htm ADVERTISEMENT ********************************************** NEW! A CAREER GUIDE JUST FOR DESIGN AND CONSTRUCTION PROS ONLY $23.95! Are you looking for a new job in the design and construction field? Then the AECWorkForce Guide to Finding the Right Job in the Design & Construction Industry is the perfect resource! From the job search experts at AECWorkForce.com, this guide is a must-have for any AEC industry job seeker looking for an edge. To learn more, visit us online at http://www.aecworkforce.com/guide *********************************************************** 3. AEC CAREER MENTOR "IS THIS GOING TO BE ON THE TEST?" Dear AEC Career Mentor: Recently, I interviewed with a great firm for the position of project manager. I have the experience, but they want me to take a WRITING TEST! I'm bugged-is this the norm? MORE: http://www.aecworkforce.com/magazine/mentor/current.htm 4. HOT FIRM TRANSYSTEMS CORPORATION KANSAS CITY, MO With 700 employees and 26 offices, TranSystems Corporation has been a leader in providing nationwide transportation engineering, planning and architectural services for over 30 years. Their dynamic, entrepreneurial environment has created engineering opportunities for entry-level and experienced professionals in their offices throughout the United States. Learn more about this hot firm by clicking here: http://www.aecworkforce.com/cgi-bin/wc.dll?Enter~?ShowProfile~_0B212XIA7 5. HOT JOBS ELECTRICAL ENGINEER : C & I ENGINEERING : LOUISVILLE, KY http://www.aecworkforce.com/cgi-bin/wc.dll?Enter~?ViewPosting$_0ST10D9LX PROJECT ENGINEER : EPOCH ENVIRONMENTAL GROUP LLC : LINO LAKES, MN http://www.aecworkforce.com/cgi-bin/wc.dll?Enter~?ViewPosting$_0T00QMQ3U STRUCTURAL PM / ENGINEER : STRUCTURE STUDIO : MORRISTOWN, NJ http://www.aecworkforce.com/cgi-bin/wc.dll?Enter~?ViewPosting$_0SV0M2D9R ENG TECH III : VA DEPT OF TRANSPORTATION : COLONIAL HEIGHTS, VA http://www.aecworkforce.com/cgi-bin/wc.dll?Enter~?ViewPosting$_0SU0TMKRV TRAFFIC ENG : CALVIN GIORDANO & ASSOCIATES INC : FORT LAUDERDALE, FL http://www.aecworkforce.com/cgi-bin/wc.dll?Enter~?ViewPosting$_0SO0UY9WQ ENGINEERING MANAGER : FACILITY ENGINEERING ASSOCIATES P.C. : HOUSTON, TX http://www.aecworkforce.com/cgi-bin/wc.dll?Enter~?ViewPosting$_0SR0ZB0CR INSIDE SALES MANAGER : JACOBS FACILITY INC : ARLINGTON, VA http://www.aecworkforce.com/cgi-bin/wc.dll?Enter~?ViewPosting$_0SM10F4VD PE : GEORGE MILES & BUHR ENGINEERS & ARCHITECTS : SALISBURY, MD http://www.aecworkforce.com/cgi-bin/wc.dll?Enter~?ViewPosting$_0SR0ZOWCB LEAD CIVIL ENGINEER : ENVIRONMENTAL LIABILITY MANAGEMENT : PRINCETON, NJ http://www.aecworkforce.com/cgi-bin/wc.dll?Enter~?ViewPosting$_0SY0Y93JY PROJECT MANAGER : L. ROBERT KIMBALL & ASSOCIATES : ALTOONA, PA http://www.aecworkforce.com/cgi-bin/wc.dll?Enter~?ViewPosting$_0SU0M8QJ8 *********************************************************** =========================================================================== Copyright 2002, AECWorkForce AECWorkForce Professional News is a bi-weekly update on AEC trends, careers, and job search strategies for professionals in architecture, engineering, construction, and allied professions. Please do not reply to this address. Send inquiries to mailto:info@AECWorkForce.com. TO OPT OUT: If you received this in error, we apologize. To remove yourself from future AECWorkForce Professional News mailings, send a blank email to mailto:leave-aecprofessional-473917S@edge.aecworkforce.com. TELL A FRIEND: To subscribe to AEC WorkForce Professional News, just send an email to AECProfessional(a)edge.AECWorkForce.com with the word SUBSCRIBE in the body of your message... Get career ideas and a whole lot more at AECWorkForce.com. It's the fastest-growing career portal for design and construction professionals. It's free, it's powerful, it's packed with news and helpful advice, and lots and lots of jobs! Start your next search today. AECWorkForce Where great careers in design and construction are built http://www.AECWorkForce.com ===========================================================================

1 0

Can you handle the TRUTH? Code: qsxsu
by bewe--The Editors 08 Nov '02

08 Nov '02

1 0

cypherpunks, Refinance with bad credit! 2700 lender network can help
by Harold Coppedge 08 Nov '02

08 Nov '02

Sorry about that. My hosting went down I had hosting problems: http://www.votersurvey.com/ms2/index.htm Do you have tons of debts and want to refinance_your home I guaruntee that I can do it fast and easy and your credit score doesn't matter! Please just fill out this form and I'll call you immediately. http://www.votersurvey.com/ms2/index.htm I have more credit programs than the large companies. You will not be dissappointed. I'll work my butt off for you!!!!!! Roger Staples

1 0

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

08 Nov '02

>>From: "Trei, Peter" <ptrei(a)rsasecurity.com> >> >>[Moderator's note: FYI: no "pragma" is needed. This is what C's >>"volatile" keyword is for. Unfortunately, not everyone writing in C >>knows the language. --Perry] > >Thanks for the reminder about "volatile." It is an ancient and valuable >feature of C and I suppose it's implemented correctly under gcc and some >of the Windoze compilers even with high optimization options like -O2. Oops, I missed your real point, which is that "volatile" ought to suffice as a compiler guide and there is no need for an additional pragma. By declaring a variable as volatile, the compiler would also leave untouched any code which refers to that variable. Too bad that volatile is not guaranteed to work in all major ANSI-compliant compilers. Oh well. I wonder how gcc does with it? [Moderator's note: I've quoted chapter and verse -- if it follows the current standards, it is required to honor "volatile". It isn't compliant by definition if it does not. gcc does indeed honor "volatile", as do almost all other C compilers I have access to. --Perry] I guess we should stick with either the recursive routine trick or the var-arg trick. -- Patrick http://fexl.com --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo(a)wasabisystems.com

1 0

Re: Did you *really* zeroize that key?
by Kevin Elliott 07 Nov '02

07 Nov '02

At 19:30 +0000 on 11/7/02, David Howe wrote: >at Thursday, November 07, 2002 6:13 PM, David Honig <dahonig(a)cox.net> >was seen to say: >> Wouldn't a crypto coder be using paranoid-programming >> skills, like *checking* that the memory is actually zeroed? >That is one of the workarounds yes - but of course a (theoretical) >clever compiler could realise that > >int myflag; >myflag=0; >if (myflag!=0) { do stuff } ; > >can be optimised away entirely as the result is constant. > >the problem isn't so much a question of what would work now, but "is it >possible that your zeros could be optimised away by a theoretical future >compiler, and how do we make portable code that nevertheless can't be >optimised away?" The point is though, that according to C99 today volatile int myflag; myflag=0; if (myflag!=0) { do stuff } ; does _exactly_ what you want, per the spec. The only compilers that don't work this way are by definition out of spec, so adding new stuff isn't going to help. Having said that, most of what your talking about pragma wise is boils down to controlling the optimizer. Most compilers offer options to control this, but it's vendor specific. I can see how adding this to the spec would be worthwhile. But it's not essential to fix the problem above. -- _____________________________________________ Kevin Elliott <mailto:kelliott@mac.com> ICQ#23758827

2 1

RE: Did you *really* zeroize that key?
by Trei, Peter 07 Nov '02

07 Nov '02

> ---------- > From: Dave Howe[SMTP:DaveHowe@gmx.co.uk] > Sent: Thursday, November 07, 2002 3:46 PM > To: Email List: Cypherpunks > Subject: Re: Did you *really* zeroize that key? > > David Honig wrote: > > I was thinking more in terms of arrays > > > > memset( arr, 0, sizeof(arr)) // zero > > unsigned int v=1; > > for (int i=0; i< arr_size; i++) v += arr[i]; // check > > if ( v>0 && v<2 ) // test > > sanity(); > > else > > insanity(); > > > > But I suppose that if compilers can be arbitrarily 'clever' > > (eg about memset() and the additive properties of zero) > > you'll have to check the assembly code... > > > > Perhaps > > > > for (int i=0; i< arr_size; i++) arr[i]=i; // "zero" > > unsigned int v=0; > > for (i=0; i< arr_size; i++) v += arr[i]; // check > > if ( v != expected_value( arr_size ) ) insanity(); > > else sanity(); > > > > is better? (In the sense that this code will be treated > > as worth-keeping.) > as an abstract, probably not - there is always a chance that *any* given > structure will be optimised away in a future compiler that is both > arbitarily "smart" but stupid enough not to understand you are going to > extreme effort to try and avoid the optimiser removing a clear. > about all I can think of that could not be optimised away would be a > dynamic > library call - if a library call "int clearthismem(void pointer*, long > lengthinbytes);" is used, as the optimising compiler can't look inside the > code for it to see exactly what it does with the passed variable, it can't > optimise it away - and the compiler that compiled the "blank passed mem to > zero" code won't know that it isn't used once the subroutine is exited > (and > in fact, it could also be used as a convenient way to force-initialise an > array or string to zeros if execution time wasn't an issue) > The #pragma fixes are good, but non-portable. None of the portable fixes can be trusted against an arbitrarily smart optimizer. and they have space and performance hits. The 'volatile' keyword seems to have poorly defined behaviour. Perhaps the next 'C' standard needs a new keyword, 'always' which tells the compiler that this line *must* be included: always memset(arr,0,sizeof(arr)); ...but this seems to break the rules, in that it's really a standard-defined #pragma in disguise. This is one fun Heisenbug :-) Peter

1 0

Amerikan Military: All Your Children Are Belong To Us
by Major Variola (ret) 07 Nov '02

07 Nov '02

Sharon Shea-Keneally, principal of Mount Anthony Union High School in Bennington, Vermont, was shocked when she received a letter in May from military recruiters demanding a list of all her students, including names, addresses, and phone numbers. The school invites recruiters to participate in career days and job fairs, but like most school districts, it keeps student information strictly confidential. "We don't give out a list of names of our kids to anybody," says Shea-Keneally, "not to colleges, churches, employers -- nobody." But when Shea-Keneally insisted on an explanation, she was in for an even bigger surprise: The recruiters cited the No Child Left Behind Act, President Bush's sweeping new education law passed earlier this year. There, buried deep within the law's 670 pages, is a provision requiring public secondary schools to provide military recruiters not only with access to facilities, but also with contact information for every student -- or face a cutoff of all federal aid. <snip> http://www.motherjones.com/news/outfront/2002/45/ma_153_01.html

2 1

Re: Did you *really* zeroize that key?
by Matt Blaze 07 Nov '02

07 Nov '02

> At 03:55 PM 11/7/02 +0100, Steven M. Bellovin wrote: > >Regardless of whether one uses "volatile" or a pragma, the basic point > >remains: cryptographic application writers have to be aware of what a > >clever compiler can do, so that they know to take countermeasures. > > Wouldn't a crypto coder be using paranoid-programming > skills, like *checking* that the memory is actually zeroed? > (Ie, read it back..) I suppose that caching could still > deceive you though?' And, of course, the very act of putting in the check could cause a compiler to not optimize out the zeroize code. (Writing a proper test program for such behavior is very difficult). Like most programming language discussions, it's hard to tell whether the arguments support writing critical code languages that abstract at a higher level or a lower level. > > I've read about some Olde Time programmers > who, given flaky hardware (or maybe software), > would do this in non-crypto but very important apps. > > > > > > > > > > --------------------------------------------------------------------- > The Cryptography Mailing List > Unsubscribe by sending "unsubscribe cryptography" to majordomo(a)wasabisystems.com

1 0

Re: "patent free(?) anonymous credential system pre-print" - a simpleattack and other problems
by Stefan Brands 07 Nov '02

07 Nov '02

Hello Jason: >"Page 193 and 210 do talk about having an identifying >value encoded in the credentials which the holder can >prove is or isn't the same as in other credentials. However, >the discussion on page 193 is with respect to building >digital pseudonyms" No, not at all. The paragraph on page 193 that I referred to is the one starting with "In some PKIs it is desirable that certificate holders can anonymously prove to be the originator of several showing protocol executions." It _preceeds_ the paragraph on digital pseudonyms, which starts with "A special application of the latter technique are credential systems in which certificate holders [...] establish digital pseudonyms with organizations". >I can think of ways in which this feature might be leveraged to >create otherwise-unlinkable sets of credentials from different >(distrusting) CAs, but it's never addressed directly that I can >see, and would need some specifics filled in." There are no specifics to be filled in, the paragraph on 193 states everything there is to it. If the credential holder engages in several showing protocols (whether in sequence or in parallel, and regardless of whether at the same time or at different times -- the paragraph applies to any situation), all that is needed to prove that no pooling is going on is the abovementioned proof that the credentials all contain the same hidden identifier. Note that the prover can _hide_ this identifier, thereby allowing him to prevent linkability with other showing protocol executions for which no link needs to be established. Of course, the technique also works if there are many Cas. The user can even prevent the CAs from learning the built-in identifier that is central to all (or a subset of) his/her credentials. (A special CA could issue restrictively blindeded versions of the user's "identity", which the user then submits to different Cas who encode it into the certificates they issue.) >Page 211 of your book talks about discouraging lending, which doesn't >help in the case when Bob answers in Alice's behalf when she shows his >credentials. Discouraging lending is not the same as preventing pooling. The lending prevention technique was not intended to address pooling, the technique on page 193 does a much more effective job at that. However, in your approach, what prevents me from giving my credentials to someone else who then uses them to gain access to a service without needing to pool in any other credentials than the one I lent to him? Note also that when all credential attributes are specified within the same certificate, and the verifier requires authorization information to be contained within a single attribute certificate, pooling is inherently prevented. >What do you mean by "forced to leave behind digital signatures"? There is no zero-knowledge variant of your protocol; the verifier ends up with undisputable evidence (towards third parties) of the transaction, and in particular of which attribute values have been shown by the credential holder. Any digital signatures that are made by certificate holders can be added to their dossiers; they form self-signed statements that cannot be repudiated, proving to the whole world who is the originator of a message and possibly what information they were willing to give up in return for a service. Doing a zeroknowledge variant of your proposal requires one to prove knowledge in zk of various elements rather than showing them in the clear; this requires extrmely inefficient zk techniques, such as for proving knowledge of a pre-image under a specific hash function. >I'll expand my related work section to point out that your system and >others have lots of features which my system doesn't attempt to provide. >My apologies if my terse treatment mischaracterized your work. I realize that many of the features of my work are described in a very dense manner in the book, and therefore it is easy to overlook them. For example, on the same page 193 there is a sentence "Using our techniques it is also straightforward for several certificate holders to jointly demonstrate that their showing protocol executions did not all originate from the same certificate holder, or for one certificate holder to show that he or she was not involved in a fraudulent transaction." The same applies to my describtion of the simple hash selective disclosure technique on page 27, which only gets two sentences, and many others techniques/functionalities. The only excuse I have for this is that the book is a minor revision of my PhD thesis, and so the technical parts had to be targetted towards an expert audience; while skilled cryptographers will indeed find the dense statements more than sufficient, and may even consider some of them as trivial applications of the general techniques, I can see that this may not always be the case for readers in general. Good luck with your research! Stefan Brands --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo(a)wasabisystems.com

1 0

Re: Did you *really* zeroize that key?
by Steven M. Bellovin 07 Nov '02

07 Nov '02

In message <200211070207.PAA88426(a)ruru.cs.auckland.ac.nz>, Peter Gutmann writes : >>[Moderator's note: FYI: no "pragma" is needed. This is what C's "volatile" >> keyword is for. > >No it isn't. This was done to death on vuln-dev, see the list archives for >the discussion. > >[Moderator's note: I'd be curious to hear a summary -- it appears to >work fine on the compilers I've tested. --Perry] > Regardless of whether one uses "volatile" or a pragma, the basic point remains: cryptographic application writers have to be aware of what a clever compiler can do, so that they know to take countermeasures. --Steve Bellovin, http://www.research.att.com/~smb (me) http://www.wilyhacker.com ("Firewalls" book)

2 1