oops! Voting software firm gets sued.
http://www.wired.com/news/politics/0,1283,57831,00.html Never mind the wrongful termination - actually, do mind, - he got canned because of whistleblowing: ... The suit claims the termination occurred shortly before Spillane had planned to meet with officials of the independent testing authority responsible for certifying voting machines and the U.S. General Accounting Office. He claims the firing was clearly in retaliation for whistleblowing. Although more than a year and a half has passed since he lost his job, Spillane said he decided to file the suit because he believed it was important to disclose potential defects in voting software applications and in the certification process. ... In his lawsuit, Spillane claims that he submitted about 250 defect reports during his tenure at VoteHere, where he was hired in January 2001 to test voting applications to ensure they were in compliance with Federal Election Commission guidelines and industry standards. One of the defects he cited was a data path flaw that interfered with the software's ability to correctly transmit votes from the computer screen to the record log. Other defects affected usability of touch-screen voting systems, particularly for seniors and people with limited educational experience. ... --Kaos-Keraunos-Kybernetos--- + ^ + :NSA got $20Bil/year |Passwords are like underwear. You don't /|\ \|/ :and didn't stop 9-11|share them, you don't hang them on your/\|/\ --*--:Instead of rewarding|monitor, or under your keyboard, you \/|\/ /|\ :their failures, we |don't email them, or put them on a web \|/ + v + :should get refunds! |site, and you must change them very often. [EMAIL PROTECTED] http://www.sunder.net
Wiretap Act Does Not Cover Message 'in Storage' For Short Period (was Re: BNA's Internet Law News (ILN) - 2/27/03)
At 9:01 AM -0500 on 2/27/03, BNA Highlights wrote: WIRETAP ACT DOES NOT COVER MESSAGE 'IN STORAGE' FOR SHORT PERIOD BNA's Electronic Commerce Law Report reports that a federal court in Massachusetts has ruled that the federal Wiretap Act does not prohibit the improper acquisition of electronic communications that were in storage no matter how ephemeral that storage may be. The court relied on Konop v. Hawaiian Airlines Inc., which held that no Wiretap Act violation occurs when an electronic communication is accessed while in storage, even if the interception takes place during a nanosecond 'juncture' of storage along the path of transmission. Case name is U.S. v. Councilman. Article at http://pubs.bna.com/ip/BNA/eip.nsf/is/a0a6m6y1k8 For a free trial to source of this story, visit http://web.bna.com/products/ip/eplr.htm -- - R. A. Hettinga mailto: [EMAIL PROTECTED] The Internet Bearer Underwriting Corporation http://www.ibuc.com/ 44 Farquhar Street, Boston, MA 02131 USA ... however it may deserve respect for its usefulness and antiquity, [predicting the end of the world] has not been found agreeable to experience. -- Edward Gibbon, 'Decline and Fall of the Roman Empire'
Re: Trivial OTP generation method? (makernd.c)
At 03:17 AM 2/27/03 +0100, Thomas Shaddack wrote: Here's what I do for random bits: http://www.etoan.com/random-number-generation/index.html Nice!!! :) I wasn't aware such electronics is so cheap! Note on RNG/hacking the PC-Geiger counter: If you want to change the RM-60's Time Base Unit, change byte 384 in the aw-rad.set file. [I reverse engineered this; Aware tries to sell software to do this.] This can be useful if you're using counts per unit time instead of inter-count intervals as your raw measurement and are using a hot source like Am241. The RM-60 is a great little toy for those of us not at CERN.
Re: Trivial OTP generation method? (makernd.c)
Several things: * Using the output to seed MD5 for the next block exposes that part of the state of the RNG. Might be better to use half the MD5 output as seed for the next block, and the other half as output data. * Your RNG takes input from an attackable source. I can significantly reduce the entropy of your system by placing a transmitter near your machine (even if I didn't know what frequency you were tuned to, I could try to just overload the receiver's front end, or burn it out entirely). If my transmitter and your receiver are very clean, the entropy could go quite low. With a better entropy check, that might just turn into a DoS attack, but even then it might be attackable - it would depend on how well I could manipulate the /dev/dsp output via my transmitter. The present check only requires that some pair of bytes differ by 16 - something that might be relatively easy to cause with a transmitter. Of course, reading 128 bytes buys you a lot of entropy even just from marginal noise, so you may still be okay. -J
