- cypherpunks-legacy - lists.cpunks.org

Re: [tor-talk] possible to identify tor user via hardware DRM?
by Seth David Schoen 06 Jul '18

06 Jul '18

Nick M. Daly writes: > I've actually been reading similar concerns (about hardware-based > tracking) on the FreedomBox list, and I have no basis for validating the > claims. Wondering if anybody could shed some light on just how serious > these claims are and how they'd impact Tor users (or privacy generally)? > The mail seems full of generalizations, but the author seems genuine: > > http://lists.alioth.debian.org/pipermail/freedombox-discuss/2012-June/00404… I find this message misleading in various ways. The basic thing that I've been telling people is that there are few situations in which either PSN or TPM uniqueness makes things qualitatively worse. There are lots of hardware unique IDs. On Linux, try "sudo lshw" and be surprised at all the things that have unique serial numbers. There are also things that are unique about your machine that are not hardware serial numbers, like filesystem serial numbers and observed combinations of software configurations. These can be bad for privacy because software can tell which computer it's running on. If the software has an adversarial relationship with you, it can then use that information in a way that you don't like. We would be better off in some regards if operating systems let us hide local uniqueness from software so that the software couldn't tell what machine it was running on, or set fake values for these unique identifiers. Some proprietary software including Microsoft Windows already makes a sophisticated profile of the local machine, including many kinds of observations, to tie a copy of the software (or an "activation") to a particular device (!). The only substantive difference with the TPM uniqueness is that the TPM uniqueness lets you prove (like a smartcard) to a remote system that you're running some software on the same machine as before. Even if the OS did let you set fake values when software tried to examine the system it was running on, the remote system could see that the TPM-related values were fake. That's useful for some applications, including but not limited to DRM-like ones. I've argued that this is bad in some ways, but at least you can still turn off the TPM. Then your system can't attempt to offer that kind of proof. As far as I know, turning off the TPM is pretty robust: it really is turned off. All of these things are anonymity problems in particular when some software on your computer is actively _trying_ to tell someone else what machine you're running on, either because it's programmed to do so or because someone has broken into your computer and installed spyware and is trying to use it to monitor you. If you're not in that situation, there is nothing especially magical about having unique hardware IDs in your machine, because everyone's machine has some uniqueness, and (for the most part) that uniqueness isn't part of standard network protocols like TCP/IP and doesn't automatically leak out to anyone and everyone you communicate with over the Internet. (There is a possible exception about clock skew, which you can read about in Steven Murdoch's paper from 2006.) Similarly, having a GPS receiver in your phone does not mean that everyone you send an SMS to or everyone you call will learn your exact physical location. However, it does mean that if there's spyware on your phone, that spyware is able to use the GPS to learn your location and leak it. If you're worried about spyware threats on your phone, which can be quite a realistic concern, the GPS itself isn't necessarily the unique core of the threat, because there are also lots of other things in the phone that can be read to help physically locate you (like wifi base station MAC addresses, taking photographs of your surroundings with the phone's camera, recording the identities and signal strengths of the GSM base stations your phone sees...). So a more fundamental question might be whether your phone operating system is able to either prevent you from getting malware or prevent the malware from accessing the sensors on your phone. In the case of a desktop PC, the hardware uniqueness is _there to be read by software_, and if it's in a TPM it _may be able to give the software remotely verifiable cryptographic proof that the software is really running on the machine containing that particular TPM_. In neither case does the hardware uniqueness directly broadcast itself to other machines, and in neither case does the hardware uniqueness prevent the operating system from preventing other software from reading it. If you do have some kind of software running on your machine that's trying to track you or trying to help other people track you, hardware uniqueness is one thing that the software might look at. But if you're a Tor user, a more basic thing for the software to try to do is make network connections to leak your real IP address in order to associate your Tor-based network activity with your non-Tor-based network activity. That might be even easier because the tracking software could just try to make a direct network connection. If you're not using Tor, at least not at a particular moment, but are still concerned about tracking, there's another problem, which is that all existing browsers _already_ reveal a great deal of software-based uniqueness to any interested web site, usually enough to make your browser unique. See https://panopticlick.eff.org/browser-uniqueness.pdf This is important because it doesn't require there to be any malicious software on your computer, just a traditional web browser. One of the defenses people have talked about against hardware fingerprinting is running inside a virtual machine. Normally, software inside the virtual machine, even if it's malicious, doesn't learn much about the physical machine that hosts the VM. If you always use Tor inside a VM, then even if there's a bug that lets someone take over your computer (or if they trick you into installing spyware), the malicious software won't be able to read much real uniqueness from the host hardware, unless there's also a bug in the VM software. Running in a VM isn't exactly a defense against software fingerprinting (like browser fingerprinting) if you use the VM for various non-Tor activities that you don't want to be linked to one another, because the software configuration inside the VM might be, or become, sufficiently different from others that it can be recognized. There's probably more research to be done about the conditions under which VMs can be uniquely identified both "from the inside" by malware, and remotely by remote software fingerprinting, absent VM bugs that give unintended access to the host. -- Seth Schoen <schoen(a)eff.org> Senior Staff Technologist https://www.eff.org/ Electronic Frontier Foundation https://www.eff.org/join 454 Shotwell Street, San Francisco, CA 94110 +1 415 436 9333 x107 _______________________________________________ tor-talk mailing list tor-talk(a)lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE

1 0

[IP] When police ask your name, you must give it, Supreme Court says
by dave＠farber.net 06 Jul '18

06 Jul '18

___ Dave Farber +1 412 726 9889 ...... Forwarded Message ....... From: Kurt Albershardt <kurt(a)nv.net> To: dave(a)farber.net Date: Mon, 21 Jun 2004 16:44:00 -0700 Subj: When police ask your name, you must give it, Supreme Court says By GINA HOLLAND, Associated Press Writer WASHINGTON - A sharply divided Supreme Court ruled Monday that people who refuse to give their names to police can be arrested, even if they've done nothing wrong. The court previously had said police may briefly detain people they suspect of wrongdoing, without any proof. But until now, the justices had never held that during those encounters a person must reveal their identity. The court's 5-4 decision upholds laws in at least 21 states giving police the right to ask people their name and jail those who don't cooperate. Law enforcement officials say identification requests are a routine part of detective work. Privacy advocates say the decision gives police too much power. Once officers have a name, they can use computer databases to learn all kinds of personal information about the person. The loser in Monday's decision was Nevada cattle rancher Larry "Dudley" Hiibel, who was arrested and convicted of a misdemeanor after he told a deputy that he didn't have to give out his name or show an ID. The encounter happened after someone called police to report arguing between Hiibel and his daughter in a truck parked along a road. An officer asked him 11 times for his identification or his name. Hiibel repeatedly refused, at one point saying, "If you've got something, take me to jail" and "I don't want to talk. I've done nothing. I've broken no laws." In fighting the arrest, Hiibel became an unlikely constitutional privacy rights crusader. He wore a cowboy hat, boots and a bolo tie to the court this year when justices heard arguments in his appeal. "A Nevada cowboy courageously fought for his right to be left alone, but lost," said his attorney, Harriet Cummings. The court ruled that forcing someone to give police their name does not violate their Fourth Amendment protection from unreasonable searches. The court also said name requests do not violate the Fifth Amendment right against self-incrimination, except in rare cases. "One's identity is, by definition, unique; yet it is, in another sense, a universal characteristic. Answering a request to disclose a name is likely to be so insignificant in the scheme of things as to be incriminating only in unusual circumstances," Justice Anthony M. Kennedy wrote for the majority. "A name can provide the key to a broad array of information about the person, particularly in the hands of a police officer with access to a range of law enforcement databases," he wrote in a dissent. Justices David H. Souter, Ruth Bader Ginsburg (news - web sites) and Stephen Breyer (news - web sites) also disagreed with the ruling. Crime-fighting and justice groups had argued that a ruling the other way would have protected terrorists and encouraged people to refuse to cooperate with police. "The constant danger of renewed terrorist activity places enormous pressure on law enforcement to identify suspected terrorists before they strike," said Charles Hobson, an attorney with the Sacramento-based Criminal Justice Legal Foundation. But Tim Lynch, an attorney with the libertarian-oriented think tank Cato Institute, said the court "ruled that the government can turn a person's silence into a criminal offense." "Ordinary Americans will be hopelessly confused about when they can assert their right to remain silent without being jailed like Mr. Hiibel," said Lynch, who expects the ruling will lead more cities and states, and possibly Congress, to consider laws like the one in Nevada. Justices had been told that at least 20 states have similar laws to the Nevada statute: Alabama, Arkansas, California, Colorado, Delaware, Florida, Georgia, Illinois, Kansas, Louisiana, Massachusetts, Montana, Nebraska, New Hampshire, New Mexico, New York, North Dakota, Rhode Island, Utah, Vermont, and Wisconsin. The ruling was a follow up to a 1968 decision that said police may briefly detain someone on reasonable suspicion of wrongdoing, without the stronger standard of probable cause, to get more information. Justices said that during such brief detentions, known as Terry stops after the 1968 ruling, people must answer questions about their identities. Marc Rotenberg, head of the Electronic Privacy Information Center, said America is different 36 years after the Terry decision. "In a modern era, when the police get your identification, they are getting an extraordinary look at your private life." The case is Hiibel v. Sixth Judicial District Court of the state of Nevada, 03-5554. ------------------------------------- You are subscribed as eugen(a)leitl.org To manage your subscription, go to http://v2.listbox.com/member/?listname=ip Archives at: http://www.interesting-people.org/archives/interesting-people/ ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> ______________________________________________________________ ICBM: 48.07078, 11.61144 http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE http://moleculardevices.org http://nanomachines.net [demime 1.01d removed an attachment of type application/pgp-signature]

1 0

Re: CRYPTO2004 Rump Session Presentations, was Re: A collision in MD5'
by james hughes 06 Jul '18

06 Jul '18

I have 2 items of note for this list. 1. The web site is updated with program and the times. http://www.iacr.org/conferences/crypto2004/rump.html 2. I was typing fast, and mistyped my title. I am General Chair this year, not 2002 as was stated. Enjoy. On Aug 17, 2004, at 1:39 PM, james hughes wrote: > Yes, my mistake. the link has an 'o' at the end. > > mms://128.111.55.99/crypto > > --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo(a)metzdowd.com --- end forwarded text -- ----------------- R. A. Hettinga <mailto: rah(a)ibuc.com> 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'

1 0

Re: [cryptography] "Zero knowledge" as a term for end-to-end encryption
by ianG 06 Jul '18

06 Jul '18

On 13/02/13 05:33 AM, Tony Arcieri wrote: > I have seen several services/people using the phrase "zero knowledge" > recently, e.g.: > > https://spideroak.com/ > > Based on my understanding of zero knowledge proofs and the traditional > use of "zero knowledge" in cryptography, this usage seems... novel, to > put it politely. Not without some precedent, there was a company called Zero Knowledge Systems back in the early 2000s that tried to build what we now would see as a Skype or Tor competitor. > In the case of SpiderOak, they're using it to mean "we > never see plaintext and we hold no keys to your ciphertexts so there's > no way we can read them" > > I've seen the Tahoe-LAFS folks, for example, attempt to use the phrase > "least authority" to imply the same thing, which makes sense to me, but > figuring out what "least authority" means in the context of a > distributed filesystem may be a tad... indirect. AFAIK, the term 'least authority' as used by Tahoe-LAFS folks does not refer to 'zero knowledge' as per cryptographic protocols, but to the concept of least authority as derived from the 'capabilities' school of security thought. This school has it in short that once one agent has authority over some object (data perhaps) then there is no economic model available to us to stop that agent from sharing the authority (by accident or intent) and thus breaching security. Given this 'truth', it derives that the best strategy for security is to reduce the amount of authority in many and serious ways. > Is there a better phrase to describe this? End-to-end encryption? > Client-side encryption? Or is it okay to let people start using the > phrase "zero knowledge" refer to this idea? As a technical paradigm, the capabilities school models everything more or less in the same way as OO programming. Every active thing is an object, and references (called capabilities) are passed around carefully. I think this fits precisely with what Tahoe-LAFS tries to do (although I'm writing from osmosis not real knowledge). It seems from a quick browser that SpiderOak use the same design? > How do people feel about "zero knowledge" being used in this way? Although there are parallels, I don't think it helpful to interchange the terms 'least authority' and 'zero knowledge' in more technical conversations. They operate at different layers or levels, and achieve rather different things. That said, in the world of marketing, it is far more appropriate to tell the customer something they understand. Least authority isn't meaningful to the end-user; zero knowledge does come much closer to what grandma can conceive of. iang _______________________________________________ cryptography mailing list cryptography(a)randombit.net http://lists.randombit.net/mailman/listinfo/cryptography ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE

1 0

Re: [liberationtech] Saudi Arabia implements electronic tracking system for women
by Brian Conley 06 Jul '18

06 Jul '18

I would be interested to know whether this system involves any automated tracking, such as a database of SIMs that are updated by default via SMS when the relevant women's SIM passes immigration, etc. It seems likely it is simply a database registry, cross referencing contact information of male guardians with the respective woman being monitored. In effect this means the men may also be tracked, at least their phones are registered in a central database. It seems the practicalities around how such a system functions may be an effective way to organize Saudi men around a campaign? I guess it depends whether, culturally, such a database of male SIMs is considered an unacceptable invasion of privacy. Thanks for the heads up! On Nov 22, 2012 12:28 PM, "Mohammad Shublaq" <moh(a)riseup.net> wrote: > > http://www.rawstory.com/rs/2012/11/22/saudi-arabia-implements-electronic-tr…<http://www.rawstory.com/rs/2012/11/22/saudi-arabia-implements-electronic-tr…> > > RIYADH b Denied the right to travel without consent from their male > guardians and banned from driving, women in Saudi Arabia are now monitored > by an electronic system that tracks any cross-border movements. > > Since last week, Saudi womenbs male guardians began receiving text > messages on their phones informing them when women under their custody > leave the country, even if they are travelling together. > > Manal al-Sherif, who became the symbol of a campaign launched last year > urging Saudi women to defy a driving ban, began spreading the information > on Twitter, after she was alerted by a couple. > > The husband, who was travelling with his wife, received a text message > from the immigration authorities informing him that his wife had left the > international airport in Riyadh. > > b The authorities are using technology to monitor women,b said columnist > Badriya al-Bishr, who criticised the b state of slavery under which women > are heldb in the ultra-conservative kingdom. > > Women are not allowed to leave the kingdom without permission from their > male guardian, who must give his consent by signing what is known as the > b yellow sheetb at the airport or border. > > The move by the Saudi authorities was swiftly condemned on social network > Twitter b a rare bubble of freedom for millions in the kingdom b with > critics mocking the decision. > > b Hello Taliban, herewith some tips from the Saudi e-government!b read one > post. > > b Why donbt you cuff your women with tracking ankle bracelets too?b wrote > Israa. > > b Why donbt we just install a microchip into our women to track them > around?b joked another. > > b If I need an SMS to let me know my wife is leaving Saudi Arabia, then Ibm > either married to the wrong woman or need a psychiatrist,b tweeted Hisham. > > b This is technology used to serve backwardness in order to keep women > imprisoned,b said Bishr, the columnist. > > b It would have been better for the government to busy itself with finding > a solution for women subjected to domestic violenceb than track their > movements into and out of the country. > > Saudi Arabia applies a strict interpretation of sharia, or Islamic law, > and is the only country in the world where women are not allowed to drive. > > In June 2011, female activists launched a campaign to defy the ban, with > many arrested for doing so and forced to sign a pledge they will never > drive again. > > No law specifically forbids women in Saudi Arabia from driving, but the > interior minister formally banned them after 47 women were arrested and > punished after demonstrating in cars in November 1990. > > Last year, King Abdullah b a cautious reformer b granted women the right > to vote and run in the 2015 municipal elections, a historic first for the > country. > > In January, the 89-year-old monarch appointed Sheikh Abdullatif Abdel Aziz > al-Sheikh, a moderate, to head the notorious religious police commission, > which enforces the kingdombs severe version of sharia law. > > Following his appointment, Sheikh banned members of the commission from > harassing Saudi women over their behaviour and attire, raising hopes a more > lenient force will ease draconian social constraints in the country. > > But the kingdombs b religious establishmentb is still to blame for the > discrimination of women in Saudi Arabia, says liberal activist Suad > Shemmari. > > b Saudi women are treated as minors throughout their lives even if they > hold high positions,b said Shemmari, who believes b there can never be > reform in the kingdom without changing the status of women and treating > themb as equals to men. > > But that seems a very long way off. > > The kingdom enforces strict rules governing mixing between the sexes, > while women are forced to wear a veil and a black cloak, or abaya, that > covers them from head to toe except for their hands and faces. > > The many restrictions on women have led to high rates of female > unemployment, officially estimated at around 30 percent. > > In October, local media published a justice ministry directive allowing > all women lawyers who have a law degree and who have spent at least three > years working in a lawyerbs office to plead cases in court. > > But the ruling, which was to take effect this month, has not been > implemented. > > -- > Unsubscribe, change to digest, or change password at: > https://mailman.stanford.edu/mailman/listinfo/liberationtech > -- Unsubscribe, change to digest, or change password at: https://mailman.stanford.edu/mailman/listinfo/liberationtech ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE

1 0

[bitcoin-list] Bitcoin 0.4.0 released
by Gavin Andresen 06 Jul '18

06 Jul '18

Bitcoin version 0.4.0 is now available for download at: http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.4.0/ The main feature in this release is wallet private key encryption; you can set a passphrase that must be entered before sending coins. See below for more information; if you decide to encrypt your wallet, WRITE DOWN YOUR PASSPHRASE AND PUT IT IN A SECURE LOCATION. If you forget or lose your wallet passphrase, you lose your bitcoins. Previous versions of bitcoin are unable to read encrypted wallets, and will crash on startup if the wallet is encrypted. Also note: bitcoin version 0.4 uses a newer version of Berkeley DB (bdb version 4.8) than previous versions (bdb 4.7). If you upgrade to version 0.4 and then revert back to an earlier version of bitcoin the it may be unable to start because bdb 4.7 cannot read bdb 4.8 "log" files. Notable bug fixes from version 0.3.24: -------------------------------------- Fix several bitcoin-becomes-unresponsive bugs due to multithreading deadlocks. Optimize database writes for large (lots of inputs) transactions (fixes a potential denial-of-service attack) Wallet Encryption ----------------- Bitcoin supports native wallet encryption so that people who steal your wallet file don't automatically get access to all of your Bitcoins. In order to enable this feature, chose "Encrypt Wallet" from the Options menu. You will be prompted to enter a passphrase, which will be used as the key to encrypt your wallet and will be needed every time you wish to send Bitcoins. If you lose this passphrase, you will lose access to spend all of the bitcoins in your wallet, no one, not even the Bitcoin developers can recover your Bitcoins. This means you are responsible for your own security, store your passphrase in a secure location and do not forget it. Remember that the encryption built into bitcoin only encrypts the actual keys which are required to send your bitcoins, not the full wallet. This means that someone who steals your wallet file will be able to see all the addresses which belong to you, as well as the relevant transactions, you are only protected from someone spending your coins. It is recommended that you backup your wallet file before you encrypt your wallet. To do this, close the Bitcoin client and copy the wallet.dat file from ~/.bitcoin/ on Linux, /Users/(user name)/Application Support/Bitcoin/ on Mac OSX, and %APPDATA%/Bitcoin/ on Windows (that is /Users/(user name)/AppData/Roaming/Bitcoin on Windows Vista and 7 and /Documents and Settings/(user name)/Application Data/Bitcoin on Windows XP). Once you have copied that file to a safe location, reopen the Bitcoin client and Encrypt your wallet. If everything goes fine, delete the backup and enjoy your encrypted wallet. Note that once you encrypt your wallet, you will never be able to go back to a version of the Bitcoin client older than 0.4. Keep in mind that you are always responsible for your own security. All it takes is a slightly more advanced wallet-stealing trojan which installs a keylogger to steal your wallet passphrase as you enter it in addition to your wallet file and you have lost all your Bitcoins. Wallet encryption cannot keep you safe if you do not practice good security, such as running up-to-date antivirus software, only entering your wallet passphrase in the Bitcoin client and using the same passphrase only as your wallet passphrase. See the doc/README file in the bitcoin source for technical details of wallet encryption. Full changelog ("git shortlog --no-merges v0.3.24..") ----------------------------------------- Abraham Jewowich (1): Fix bug with accessing vchData[0] when vchData is empty. Fix typo in CBase58Data::CompareTo Alex B (2): Romanian translation added Spanish translation update Alex Waters (1): Updated readme file Daniel Folkinshteyn (1): Update the list of seednodes. Dawid Spiechowicz (1): added polish wallet encryption messages Dean Lee (1): Update to the Chinese Simp translation Dev Random (4): Linux gitian config with separate wxWidgets build Mingw gitian with separate wxWidgets and boost Mingw gitian build with deterministic bitcoin.exe by use of faketime Add Gitian Build descriptors for Boost and wxWidgets. Doug Huff (1): Make mlock() and munlock() portable to systems that require the address to be on a page boundary. Dylan Noblesmith (1): mlock() all private keys in memory Eric Hosmer (1): Added crypter to makefile.vc. Fabian H jr. (1): Updated checkpoints, maybe Tx fee should be reduced to 0.0001 from 0.0005 and maximum minimum tx should be 0.0010. Gavin Andresen (24): Do-nothing MapPort() ifndef USE_UPNP. fixes #450 Don't std::advance past beginning of transactions array. Fixes #465 Remove unused ScanMessageStart function Compile with DEBUG_LOCKORDER to detect inconsistent lock orderings that can cause deadlocks CHECKMULTISIG unit tests. Highlight mis-matching locks Fix rpc-hanging deadlocks Fixed potential deadlocks in GUI code. Also changed semantics of CWalletTx::GetTxTime(); now always returns the time the transaction was received by this node, not the average block time. And added information about -DDEBUG_LOCKORDER to coding.txt. Fix typo ("you own security") SetCrypted() obtains keystore lock, to be safe. Logic running with -keypool=0 was wrong (empty keys were being returned). Fixes #445 Fix RPC call name in error message. obtain cs_wallet mutex to protect vchDefaultKey Fixed regression I introduced: wallets with lots of transactions were unusable in GUI. Fix bad merge: getaccountaddress was broken for new accounts Give hard-coded seed nodes a random last-seen time, to randomize order they're tried. Do not try to download blockchain from 0.3.23 nodes If compiled -DDEBUG_LOCKORDER and run with -debug, print out every mutex lock/unlock (helpful for debugging something-is-holding-a-mutex-too-long problems) Stay connected to seed nodes; disconnecting causes problems if you are trying to make the initial blockchain download. Versions 0.3.20 THROUGH 0.3.23 have trouble with blockchain downloads; avoid them Bumped version numbers to 0.4.0rc1 Optimize database writes for transactions with lots of TxIns. Patch from ArtForz, who discovered the problem. Fix AddAddress cs_mapaddresses/db transaction deadlock Fix QA email address Giel van Schijndel (15): fix warning on 64bit systems: cast to pointer from integer of different size [-Wint-to-pointer-cast] fix warnings: expression result unused [-Wunused-value] fix warnings: using the result of an assignment as a condition without parentheses [-Wparentheses] fix warning: comparison of unsigned expression < 0 is always false [-Wtautological-compare] fix warning: X enumeration values not handled in switch [-Wswitch-enum] fix warning: unused variable 'X' [-Wunused-variable] fix warning: unused function 'SigIllHandlerSSE2' [-Wunused-function] fix warning: variable bnMinDepthb set but not used [-Wunused-but-set-variable] fix warning: control reaches end of non-void function [-Wreturn-type] Make some global variables less-global (static) Cleanup makefiles such that diffs to them are smaller Move func 'REF' from util.h to serialize.h Start moving protocol-specific code to protocol.[ch]pp Move CAddress to protocol.[ch]pp Move CInv to protocol.[ch]pp Han Lin Yap (2): Comment "deprecated" Add a note to only include .po file Jay Weisskopf (4): Add logos/branding currently found on bitcoin.org into NSIS installer. Set default compression for NSIS installer to LZMA. Remove NSIS branding from bottom divider. Increase resolution of Windows icon. Jeff Garzik (8): Update CWallet::LoadWallet for proper return type. Bump version to 0.3.25 doc/README: word wrap into something readable CAddrDB::LoadAddresses: properly initialize CAddress src/makefile.unix: remove -DFOURWAYSSE2 Add reference python miner, in contrib/pyminer/ README.md: word wrap text file Revert "Define MSG_NOSIGNAL to 0 on platforms where it is unavailable." Jeroenz0r (1): Translation from "Open Bitcoin" to "Verstuur Bitcoins" JoelKatz (1): Fix UNIX-specific thread handle leak. Johannes Henninger (1): Identify as "Bitcoin + version number" when mapping UPnP port Luke Dashjr (7): Update nTime after nExtraNonce to avoid potential race (extraNonce being reset due to just-occurred time change after nTime is set) Reset extraNonce only every 15 seconds, just in case some miner is updating time himself and stuff Reset extraNonce only when prevBlock changes, so miners can continue updating the time on their work until it's stale Support for boost filesystem version 3 ignore stuff Save coinbase, not just extraNonce Bugfix: Use timestamp in coinbase rather than "bits", needed to ensure coinbase txn is unique even if address is the same Matt Corallo (35): Add minversion to wallet. Add wallet privkey encryption. Set the number of SHA512 rounds based on the speed of the computer. Push unlocked_until in getinfo. Dynamically remove/insert the Options for encryption in the menus. Add the walletlock RPC method to lock the wallet manually. Add Wallet Encryption section to README Use DB Transactions when encrypting wallet. This speeds up the encryption process significantly. Make an invalid addrIncoming so that old clients crash. Update makefile.linux-mingw to work with crypter and UPnP fix. Fix makefile.linux-mingw Fix crashes when a wallet is locked and GetReservedKey() is called Generate Warning when using default key. Fix Build in GetReservedKey() in wallet.cpp Fix bad return values in LoadWallet. Actually use mapAlreadyAskedFor. Fix EncryptKeys crash introduced by a9ba4710, identified by TD. Check for duplicate txins in CheckTransaction. Make it clear that setting proxy requires restart to fully apply. Don't listen if on TOR (resolves #441). Add missing include to serialize.h Add file for transaction tests. Cleanup test suite output to be more useful. Unify copyright notices. Missed a 'password' should be 'passphrase'. Fix incorrect RPC error messages Add specific wallet encryption details to doc/README Upgrade dependancies and tweak build process. Update binary mos to latest translations. Fix build process to actually work. Add binary mo for new translation. Update gitian build descriptors to produce proper builds. Update bitcoin icon to make nsis setup exe deterministic. Update binary mo to match latest po translation. Restructure gitian files and add download config files. Michael Bemmerl (4): Basically some grammatical fixes of the German translation. Added German wallet encryption messages translation. Changed Russian translation according to comment in issue 395 Updated German translation Michal Zima (1): Updated czech translation Nils Schneider (2): log low-level network messages only when fDebug is set missed printf in AbortMessage(); merged printfs in EndMessage Patrick Varilly (1): Single DB transaction for all addresses in a message Pieter Wuille (11): Prepare codebase for Encrypted Keys. Do not use obsolete CPrivKey for passing keys around Bugfix: add autogenerated addresses to address book get rid of mapPubKeys Use CBitcoinAddress instead of string/uint160 split off CBase58Data from CBitcoinAddress Fix for small change outputs Bugfix: don't overuse limited ExtractAddress avoid strAddress + validity checks SocketHandler thread can be detached Updated dutch translation StC)phane Gimenez (1): Single DB transaction for addresses from DNS seeds Vegard Nossum (6): Add missing includes to key.h Add missing include to script.h Add missing includes to net.h Fix testing setup Add prototype for EvalScript() to script.h Add a file for script tests Venkatesh Srinivas (4): Test for SO_NOSIGPIPE rather than assuming all BSDs support it. Qualify make_tuple with boost:: namespace. Use 'unsigned char' rather than 'char' for pchMessageStart. Define MSG_NOSIGNAL to 0 on platforms where it is unavailable. Wladimir J. van der Laan (2): remove magic number: change threshold for nLockTime to constant make SetHash160 return a value (as specified in the function signature) cjdelisle (1): wxWidgets needs to be at least version 2.9.1 because wallet crypto uses ToStdString() which is not in 2.9.0 ovdeathiam (1): Edited locale/pl/LC_MESSAGES/bitcoin.po via GitHub ------------------------------------------------------------------------------ All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2dcopy2 _______________________________________________ bitcoin-list mailing list bitcoin-list(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-list ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE

1 0

Re: [tor-talk] Hidden service security w. Apache/Win32
by Ondrej Mikle 06 Jul '18

06 Jul '18

On 02/19/2012 05:05 PM, proper(a)tormail.net wrote: > > [1] https://trac.torproject.org/projects/tor/wiki/doc/TransparentProxyLeaks > [2] https://trac.torproject.org/projects/tor/wiki/doc/TorBOX > [3] > https://trac.torproject.org/projects/tor/wiki/doc/TorBOX#hostinghiddenservi… Great howto! We've been discussing a "safest" setup for hidden service a while ago. Unfortunately the forum is not in English, so I sum it up shortly: - it's very similar to your setup, two VMs: - VM1 for Tor - VM2 for http server and database, host-only networking! - harden installation with SELinux, grsecurity or AppArmor - absolutely no php (really bad track record with php apps and language itself) - nginx/lighttpd/thttpd instead of Apache (smaller code, smaller chance of bugs) SELinux is for example by default part of RHEL and clones (CentOS, Scientific Linux). By default only targeted policy is turned on, but you can turn on full enforcing. AppArmor is in Ubuntu AFAIK. A more advanced guide for hidden service on hardened Gentoo server (this will take a bit time to set up, depends on what your threat model is): - use hardened Gentoo profile - enable grsecurity in kernel - make a monolithic kernel, disable module support - turn on all possible grsecurity features (except RBAC) - install only necessary software (like webserver and DB), turn off all USE flags you won't need - compile everything as position-independent shared object (see -fPIC, -fPIE gcc options) Addendum for truly "uberparanoid" installation: - on VM1, limit new outgoing connections to Tor node IPs, this will need some script or using NFQUEUE in iptables since the IPs change (enable other IPs temporarily when doing update) - on VM1, install unbound locally, tunnel it through Tor with socat to some recursive DNSSEC-aware resolver, make unbound default resolver in /etc/resolv.conf "nameserver 127.0.0.1" (do we need DNS at all here?) - turn on grsecurity's RBAC (role-based access control), this will be pain to set up the rules for software, but grsecurity has a learning tool that will greatly assist in generating them by observing the app With the uberparanoid installation, the greatest risk is a return-to-libc-style attack on Tor where attacker instructs Tor to make circuit to a node controlled by attacker, thus revealing IP. Ondrej _______________________________________________ tor-talk mailing list tor-talk(a)lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE

1 0

[bitcoin-list] Bitcoin 0.4.0 released
by Gavin Andresen 06 Jul '18

06 Jul '18

Bitcoin version 0.4.0 is now available for download at: http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.4.0/ The main feature in this release is wallet private key encryption; you can set a passphrase that must be entered before sending coins. See below for more information; if you decide to encrypt your wallet, WRITE DOWN YOUR PASSPHRASE AND PUT IT IN A SECURE LOCATION. If you forget or lose your wallet passphrase, you lose your bitcoins. Previous versions of bitcoin are unable to read encrypted wallets, and will crash on startup if the wallet is encrypted. Also note: bitcoin version 0.4 uses a newer version of Berkeley DB (bdb version 4.8) than previous versions (bdb 4.7). If you upgrade to version 0.4 and then revert back to an earlier version of bitcoin the it may be unable to start because bdb 4.7 cannot read bdb 4.8 "log" files. Notable bug fixes from version 0.3.24: -------------------------------------- Fix several bitcoin-becomes-unresponsive bugs due to multithreading deadlocks. Optimize database writes for large (lots of inputs) transactions (fixes a potential denial-of-service attack) Wallet Encryption ----------------- Bitcoin supports native wallet encryption so that people who steal your wallet file don't automatically get access to all of your Bitcoins. In order to enable this feature, chose "Encrypt Wallet" from the Options menu. You will be prompted to enter a passphrase, which will be used as the key to encrypt your wallet and will be needed every time you wish to send Bitcoins. If you lose this passphrase, you will lose access to spend all of the bitcoins in your wallet, no one, not even the Bitcoin developers can recover your Bitcoins. This means you are responsible for your own security, store your passphrase in a secure location and do not forget it. Remember that the encryption built into bitcoin only encrypts the actual keys which are required to send your bitcoins, not the full wallet. This means that someone who steals your wallet file will be able to see all the addresses which belong to you, as well as the relevant transactions, you are only protected from someone spending your coins. It is recommended that you backup your wallet file before you encrypt your wallet. To do this, close the Bitcoin client and copy the wallet.dat file from ~/.bitcoin/ on Linux, /Users/(user name)/Application Support/Bitcoin/ on Mac OSX, and %APPDATA%/Bitcoin/ on Windows (that is /Users/(user name)/AppData/Roaming/Bitcoin on Windows Vista and 7 and /Documents and Settings/(user name)/Application Data/Bitcoin on Windows XP). Once you have copied that file to a safe location, reopen the Bitcoin client and Encrypt your wallet. If everything goes fine, delete the backup and enjoy your encrypted wallet. Note that once you encrypt your wallet, you will never be able to go back to a version of the Bitcoin client older than 0.4. Keep in mind that you are always responsible for your own security. All it takes is a slightly more advanced wallet-stealing trojan which installs a keylogger to steal your wallet passphrase as you enter it in addition to your wallet file and you have lost all your Bitcoins. Wallet encryption cannot keep you safe if you do not practice good security, such as running up-to-date antivirus software, only entering your wallet passphrase in the Bitcoin client and using the same passphrase only as your wallet passphrase. See the doc/README file in the bitcoin source for technical details of wallet encryption. Full changelog ("git shortlog --no-merges v0.3.24..") ----------------------------------------- Abraham Jewowich (1): Fix bug with accessing vchData[0] when vchData is empty. Fix typo in CBase58Data::CompareTo Alex B (2): Romanian translation added Spanish translation update Alex Waters (1): Updated readme file Daniel Folkinshteyn (1): Update the list of seednodes. Dawid Spiechowicz (1): added polish wallet encryption messages Dean Lee (1): Update to the Chinese Simp translation Dev Random (4): Linux gitian config with separate wxWidgets build Mingw gitian with separate wxWidgets and boost Mingw gitian build with deterministic bitcoin.exe by use of faketime Add Gitian Build descriptors for Boost and wxWidgets. Doug Huff (1): Make mlock() and munlock() portable to systems that require the address to be on a page boundary. Dylan Noblesmith (1): mlock() all private keys in memory Eric Hosmer (1): Added crypter to makefile.vc. Fabian H jr. (1): Updated checkpoints, maybe Tx fee should be reduced to 0.0001 from 0.0005 and maximum minimum tx should be 0.0010. Gavin Andresen (24): Do-nothing MapPort() ifndef USE_UPNP. fixes #450 Don't std::advance past beginning of transactions array. Fixes #465 Remove unused ScanMessageStart function Compile with DEBUG_LOCKORDER to detect inconsistent lock orderings that can cause deadlocks CHECKMULTISIG unit tests. Highlight mis-matching locks Fix rpc-hanging deadlocks Fixed potential deadlocks in GUI code. Also changed semantics of CWalletTx::GetTxTime(); now always returns the time the transaction was received by this node, not the average block time. And added information about -DDEBUG_LOCKORDER to coding.txt. Fix typo ("you own security") SetCrypted() obtains keystore lock, to be safe. Logic running with -keypool=0 was wrong (empty keys were being returned). Fixes #445 Fix RPC call name in error message. obtain cs_wallet mutex to protect vchDefaultKey Fixed regression I introduced: wallets with lots of transactions were unusable in GUI. Fix bad merge: getaccountaddress was broken for new accounts Give hard-coded seed nodes a random last-seen time, to randomize order they're tried. Do not try to download blockchain from 0.3.23 nodes If compiled -DDEBUG_LOCKORDER and run with -debug, print out every mutex lock/unlock (helpful for debugging something-is-holding-a-mutex-too-long problems) Stay connected to seed nodes; disconnecting causes problems if you are trying to make the initial blockchain download. Versions 0.3.20 THROUGH 0.3.23 have trouble with blockchain downloads; avoid them Bumped version numbers to 0.4.0rc1 Optimize database writes for transactions with lots of TxIns. Patch from ArtForz, who discovered the problem. Fix AddAddress cs_mapaddresses/db transaction deadlock Fix QA email address Giel van Schijndel (15): fix warning on 64bit systems: cast to pointer from integer of different size [-Wint-to-pointer-cast] fix warnings: expression result unused [-Wunused-value] fix warnings: using the result of an assignment as a condition without parentheses [-Wparentheses] fix warning: comparison of unsigned expression < 0 is always false [-Wtautological-compare] fix warning: X enumeration values not handled in switch [-Wswitch-enum] fix warning: unused variable 'X' [-Wunused-variable] fix warning: unused function 'SigIllHandlerSSE2' [-Wunused-function] fix warning: variable bnMinDepthb set but not used [-Wunused-but-set-variable] fix warning: control reaches end of non-void function [-Wreturn-type] Make some global variables less-global (static) Cleanup makefiles such that diffs to them are smaller Move func 'REF' from util.h to serialize.h Start moving protocol-specific code to protocol.[ch]pp Move CAddress to protocol.[ch]pp Move CInv to protocol.[ch]pp Han Lin Yap (2): Comment "deprecated" Add a note to only include .po file Jay Weisskopf (4): Add logos/branding currently found on bitcoin.org into NSIS installer. Set default compression for NSIS installer to LZMA. Remove NSIS branding from bottom divider. Increase resolution of Windows icon. Jeff Garzik (8): Update CWallet::LoadWallet for proper return type. Bump version to 0.3.25 doc/README: word wrap into something readable CAddrDB::LoadAddresses: properly initialize CAddress src/makefile.unix: remove -DFOURWAYSSE2 Add reference python miner, in contrib/pyminer/ README.md: word wrap text file Revert "Define MSG_NOSIGNAL to 0 on platforms where it is unavailable." Jeroenz0r (1): Translation from "Open Bitcoin" to "Verstuur Bitcoins" JoelKatz (1): Fix UNIX-specific thread handle leak. Johannes Henninger (1): Identify as "Bitcoin + version number" when mapping UPnP port Luke Dashjr (7): Update nTime after nExtraNonce to avoid potential race (extraNonce being reset due to just-occurred time change after nTime is set) Reset extraNonce only every 15 seconds, just in case some miner is updating time himself and stuff Reset extraNonce only when prevBlock changes, so miners can continue updating the time on their work until it's stale Support for boost filesystem version 3 ignore stuff Save coinbase, not just extraNonce Bugfix: Use timestamp in coinbase rather than "bits", needed to ensure coinbase txn is unique even if address is the same Matt Corallo (35): Add minversion to wallet. Add wallet privkey encryption. Set the number of SHA512 rounds based on the speed of the computer. Push unlocked_until in getinfo. Dynamically remove/insert the Options for encryption in the menus. Add the walletlock RPC method to lock the wallet manually. Add Wallet Encryption section to README Use DB Transactions when encrypting wallet. This speeds up the encryption process significantly. Make an invalid addrIncoming so that old clients crash. Update makefile.linux-mingw to work with crypter and UPnP fix. Fix makefile.linux-mingw Fix crashes when a wallet is locked and GetReservedKey() is called Generate Warning when using default key. Fix Build in GetReservedKey() in wallet.cpp Fix bad return values in LoadWallet. Actually use mapAlreadyAskedFor. Fix EncryptKeys crash introduced by a9ba4710, identified by TD. Check for duplicate txins in CheckTransaction. Make it clear that setting proxy requires restart to fully apply. Don't listen if on TOR (resolves #441). Add missing include to serialize.h Add file for transaction tests. Cleanup test suite output to be more useful. Unify copyright notices. Missed a 'password' should be 'passphrase'. Fix incorrect RPC error messages Add specific wallet encryption details to doc/README Upgrade dependancies and tweak build process. Update binary mos to latest translations. Fix build process to actually work. Add binary mo for new translation. Update gitian build descriptors to produce proper builds. Update bitcoin icon to make nsis setup exe deterministic. Update binary mo to match latest po translation. Restructure gitian files and add download config files. Michael Bemmerl (4): Basically some grammatical fixes of the German translation. Added German wallet encryption messages translation. Changed Russian translation according to comment in issue 395 Updated German translation Michal Zima (1): Updated czech translation Nils Schneider (2): log low-level network messages only when fDebug is set missed printf in AbortMessage(); merged printfs in EndMessage Patrick Varilly (1): Single DB transaction for all addresses in a message Pieter Wuille (11): Prepare codebase for Encrypted Keys. Do not use obsolete CPrivKey for passing keys around Bugfix: add autogenerated addresses to address book get rid of mapPubKeys Use CBitcoinAddress instead of string/uint160 split off CBase58Data from CBitcoinAddress Fix for small change outputs Bugfix: don't overuse limited ExtractAddress avoid strAddress + validity checks SocketHandler thread can be detached Updated dutch translation StC)phane Gimenez (1): Single DB transaction for addresses from DNS seeds Vegard Nossum (6): Add missing includes to key.h Add missing include to script.h Add missing includes to net.h Fix testing setup Add prototype for EvalScript() to script.h Add a file for script tests Venkatesh Srinivas (4): Test for SO_NOSIGPIPE rather than assuming all BSDs support it. Qualify make_tuple with boost:: namespace. Use 'unsigned char' rather than 'char' for pchMessageStart. Define MSG_NOSIGNAL to 0 on platforms where it is unavailable. Wladimir J. van der Laan (2): remove magic number: change threshold for nLockTime to constant make SetHash160 return a value (as specified in the function signature) cjdelisle (1): wxWidgets needs to be at least version 2.9.1 because wallet crypto uses ToStdString() which is not in 2.9.0 ovdeathiam (1): Edited locale/pl/LC_MESSAGES/bitcoin.po via GitHub ------------------------------------------------------------------------------ All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2dcopy2 _______________________________________________ bitcoin-list mailing list bitcoin-list(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-list ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE

1 0

Re: [tor-talk] Hidden service security w. Apache/Win32
by Ondrej Mikle 06 Jul '18

06 Jul '18

On 02/19/2012 05:05 PM, proper(a)tormail.net wrote: > > [1] https://trac.torproject.org/projects/tor/wiki/doc/TransparentProxyLeaks > [2] https://trac.torproject.org/projects/tor/wiki/doc/TorBOX > [3] > https://trac.torproject.org/projects/tor/wiki/doc/TorBOX#hostinghiddenservi… Great howto! We've been discussing a "safest" setup for hidden service a while ago. Unfortunately the forum is not in English, so I sum it up shortly: - it's very similar to your setup, two VMs: - VM1 for Tor - VM2 for http server and database, host-only networking! - harden installation with SELinux, grsecurity or AppArmor - absolutely no php (really bad track record with php apps and language itself) - nginx/lighttpd/thttpd instead of Apache (smaller code, smaller chance of bugs) SELinux is for example by default part of RHEL and clones (CentOS, Scientific Linux). By default only targeted policy is turned on, but you can turn on full enforcing. AppArmor is in Ubuntu AFAIK. A more advanced guide for hidden service on hardened Gentoo server (this will take a bit time to set up, depends on what your threat model is): - use hardened Gentoo profile - enable grsecurity in kernel - make a monolithic kernel, disable module support - turn on all possible grsecurity features (except RBAC) - install only necessary software (like webserver and DB), turn off all USE flags you won't need - compile everything as position-independent shared object (see -fPIC, -fPIE gcc options) Addendum for truly "uberparanoid" installation: - on VM1, limit new outgoing connections to Tor node IPs, this will need some script or using NFQUEUE in iptables since the IPs change (enable other IPs temporarily when doing update) - on VM1, install unbound locally, tunnel it through Tor with socat to some recursive DNSSEC-aware resolver, make unbound default resolver in /etc/resolv.conf "nameserver 127.0.0.1" (do we need DNS at all here?) - turn on grsecurity's RBAC (role-based access control), this will be pain to set up the rules for software, but grsecurity has a learning tool that will greatly assist in generating them by observing the app With the uberparanoid installation, the greatest risk is a return-to-libc-style attack on Tor where attacker instructs Tor to make circuit to a node controlled by attacker, thus revealing IP. Ondrej _______________________________________________ tor-talk mailing list tor-talk(a)lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE

1 0

Re: [liberationtech] Looking for collaborators for free-range voting project at Knight News Challenge:
by Edwin Chu 06 Jul '18

06 Jul '18

I would argue that voting backed by re-countable physical paper is more reliable than pure electronic voting in an official election. However, I think that an electronic voting is still very useful under some specific situations. In Hong Kong, the Chief Execute are not elected by citizen through universal suffrage. The CE is instead chosen by a Election Committee consist of about a thousand of persons mainly appointed. The demands for an universal suffrage is clear, but the progress is hindered by the CCP of mainland China and the vested interests. On the 2012 CE election day, some people from the University of Hong Kong set up a mock poll, dubbed "civic referendum", to allow the citizen to express their views on the CE election. The mock is funded by public donations. The mock poll provided 15 physical polling stations, and online voting via its website and smartphone. However, shortly after the mock poll began, the online voting server were overwhelmed by huge amount of requests from attackers and legitimate voters. It completely brought down the online voting. Many people went to the physical stations, which may be far away from their home, to cast their vote. Despite the difficulties, a total of 222,990 votes are still casted in the physical stations and online voting combined. (http://en.wikipedia.org/wiki/Hong_Kong_Chief_Executive_election,_2012#Mock_…) The goal of this "civic referendum" is never to officially elect the governor. By providing an unofficial election result which has higher creditability and legitimacy than the official result from the Election Committee, we hope to discredit the elected CE and the Election Committee, demonstrating the demand for a truth universal suffrage, and to push the democratic development forward. Because the mock poll is funded by the community, we have no way to set up enough physical voting stations and voter registry comparable to the election organized by the government. Indeed, it is difficult to prevent double voting in such "poor man's election". Some supporters of the CCP criticized the mock poll for lack of creditability with these reasons. Due to the lack of resource, internet voting might be one of the only means to allow most Hong Kong citizen to participate in a mock poll. What we need is a deployable solution to allow people to vote anonymously, either online or offline, at the same time provides enough creditability and verifiability. A perfect solution is not necessary because the goal isn't to replace the official paper votes. Edwin On Tue, Feb 26, 2013 at 6:49 AM, Joseph Lorenzo Hall <joe(a)cdt.org> wrote: > > (most of the statements I make below can be cited... holler if you want > some reading.) > > On Tue Feb 26 08:15:54 2013, Ruben Bloemgarten wrote: > > Irrespective of zombies et al. Voting requires the following basic > > elements : > > 1. verifiability when casting the vote, i.e. the voter can see that the > > vote that is cast will be the vote that is counted. This is not possible > > without a paper trail which is also a valid vote. > > This is a very complex topic, one that I've worked on for many years and > was the central them of my PhD thesis. I think it's important to > recognize that there are cryptographic voting systems that do verifiable > paperless voting. With out-of-band secret sharing, it gets most of the > way to what one would want to see... of course, the client-side malware > problem and the general problem of unsupervised voting (people voting > outside of an official location with polices that make sure only one > person enters the booth, etc.). > > As a member of the board of directors of the Verified Voting Foundation, > I should say that currently a paper trail backed by robust > "risk-limiting audits" are the state-of-the-art for governmental elections. > > > 2. Counting control. Each step of the electoral process has to be > > transparent for it to be valid. This means that *anyone* is allowed to > > observe the counting of the votes, *and* is able to understand that > > counting process. A printout of a result is not sufficient. Don4t forget > > that casting the vote is the least important of the process, counting > > the votes is. > > This is somewhat of a strawman... there is no way that one individual > can observe all the steps in an election as complicated as the ones we > regularly run in the U.S. (the U.S. is very strange compared to most > other countries in terms of the massive requirements we place on the > voting process... I would argue for very good public policy reasons). > This is why the academic literature on these kinds of topics > increasingly uses cryptographic auditing mechanisms to ensure that once > a valid ballot enters the system, it can be tracked. (And, believe it or > not, RFID-based inventory controls can do a lot.) > > > 3. Anonimity. There can not be any moment that a vote can be backtracked > > to the person voting. Again, this can not be based on "trusting a > > system". In many voting laws this anonymity has to be guaranteed, a > > guarantee that even with paper ballots is problematic, but is > > practically impossible in the case of electronic voting. > > I wouldn't agree that it's practically impossible... fancy primitives > like mix-nets and interactive zero-knowledge proofs have been put to > good use to come up with some basic assurances of secrecy. As I think > you imply, there are fundamental limits... e.g., there are a number of > small precincts in CA that I'm familiar with where all the cast ballots > are virtually identical (this is just to underline that there are > fundamental practical limits on ballot secrecy). And, as Josh Benaloh > from MSR highlighted recently, this can be extended in steps to > construct pretty interesting ballot secrecy violations (as one example, > if I vote for candidate B and I see that all other ballots were counted > for candidate A, I know everyone else's vote with certainty while they > don't necessarily have the same level of certainty about others' ballots). > > > When we are discussing voting in its function of the backbone of a > > democratic system, i.e. the moment when we temporarily delegate our > > individual power to a representative, deciding who will wield the > > monopoly on violence, there can be no aspect of this process that is > > based on trust. If ever there was a system which has distrust at its > > core, it is voting. > > The popular refrain in the field, I believe from Rice's Dan Wallach is: > "the purpose of voting is to convince the loser they lost." > > > The only way to have any form of electronic voting be reliable is when > > it is seconded by a re-countable paper copy, which means the choice is > > between one big central printer distributing paper ballots or lots of > > little little ones printing the ballot on the fly. This excludes online > > voting completely and makes the entire concept a little silly really. > > I would say paper is necessary (at the moment) but not sufficient... > meaningful audits are key. And no state in the U.S. is currently doing > them in a robust manner. CA is the only state that has a pilot program > to study and test practical implementation of "risk limiting audits"; > the idea being that an audit must test the hypothesis "hand-counting all > ballots will not find enough error to change the outcome of the race." > This is a formalized notion that many of us have worked on for a number > of years... and, frankly, it's the biggest development in elections *for > the entire world* in many decades. Here is a great Ars post on this that > profiles UC Berkeley's Philip Stark, who is the leading mind here: > > http://arstechnica.com/tech-policy/2012/07/saving-american-elections-with-1… > > > Apart from a child-like enthusiasm for anything with buttons and shiny > > lights, can anyone here explain to me what the intended benefits of > > electronic voting over paper voting would be ? > > Experts in voting distinguish between "electronic voting" -- > computer-mediated vote casting -- and "internet voting" -- adding in > public networks to the equation. Electronic voting is no panacea, but > most experts would agree (that may not matter to you, I'm not sure) that > some of the real gains of computer interactivity with voting interfaces > and the unique pressures of U.S. elections are such that we won't go > back to completely paper-based elections. Sure, there are some very > small jurisdictions that do all-paper in the U.S., but they're outliers. > > > Please note that all of the above only applies to political elections, > > electronic voting is perfectly fine when voting for the X-factor. > > I would also raise labor union elections... they're different but > subject to some seriously heavy regulation in the U.S. due to past abuse. > > best, Joe > > > > > > > > > On 02/26/2013 01:35 PM, Rich Kulawiec wrote: > >> > >> It won't work. Until the bot/zombie is solved, online voting is > >> a non-starter, since any election worthy of being stolen can be. > >> It doesn't matter what you do on the server side: you can construct as > >> elaborate and clever and secure an infrastructure as you wish...because > >> on the client side, there is no way to ensure that what the user sees > >> is what's actually happening. (After all: it's not *their* computer > >> any more. Its new owners can, if they wish, cause a vote for candidate > >> A to be sent as a vote for candidate B, and they can prevent the user > >> from knowing that's happened.) > >> > >> And given that (a) we're now about a decade into the zombie problem > >> (b) no significant effort against them has ever been attempted, > >> let alone completed [1] and (c) the problem is already epidemic and > >> continues to get worse [2] [3], there is no reason whatsoever to think > >> it will be mitigated, let alone solved, in the forseeable future. > >> > >> This doesn't just apply to your proposal: it applies to *all* of > >> them. Unless you can propose and execute a viable plan for solving > >> the zombie problem, then whatever you design/build can be undercut > >> whenever someone chooses to make the effort. (And provided they're > >> not foolishly heavy-handed about it, it's unlikely you would be able > >> to detect this. [4]) > >> > >> ---rsk > >> > >> [1] Botnet "takedowns" are unimportant and irrelevant; their only > >> purpose is to provide a forum for the spokesliars at Microsoft et.al. > >> to trumpet their prowess while a gullible press and public overlook > >> that they *created* this problem. Merely removing C&C networks does > >> nothing to remediate the individual members of the botnets, which are > >> still compromised, still vulnerable, and likely to be conscripted into > >> other botnets before the day is out. > >> > >> [2] We're now seeing portable devices zombie'd: phones, tablets, etc. > >> > >> [3] Estimates of zombie population vary, of course, but clearly, any > >> estimate under 100M should be laughed out of the room. Vint Cerf gave > >> an estimate of 150M just about six years ago, and based on my own work > >> as well as that of others in the anti-spam/abuse area, I thought that > >> was on the high side at the time...but it's most certainly not now. > >> I think the number's probably in the 200-300M range at this point. > >> See: http://arstechnica.com/news.ars/post/20070125-8707.html for > >> Cerf's comments. > >> > >> [4] See Schneier's insightful and chilling piece on this here: > >> > >> https://www.schneier.com/crypto-gram-0404.html#4 > >> > >> That piece should be absolutely mandatory reading for anyone even > >> considering voting systems. It not only provides a method for > >> estimating attacker budgets, but it correctly points out that attackers > >> quite often could tip the balance of an election by manipulating a > >> rather small number of votes -- with a corresponding reduction in the > >> probability that the manipulation will be detected. > >> > >> Note that Schneier wrote that in 2004. If you repeat his analysis > >> with numbers from the 2012 election cycle you'll end up with *much* > >> large attacker budgets. For example, Schneier says that in 2002, > >> Congressional candidates raised over 500M. But > >> > >> https://www.opensecrets.org/news/2012/10/2012-election-spending-will-reach-… > >> > >> says that in 2012, they spent about $1.82B. > >> > >> -- > >> Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at companys(a)stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech > >> > > > > -- > > Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at companys(a)stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech > -- > Joseph Lorenzo Hall > Senior Staff Technologist > Center for Democracy & Technology > 1634 I ST NW STE 1100 > Washington DC 20006-4011 > (p) 202-407-8825 > (f) 202-637-0968 > joe(a)cdt.org > PGP: https://josephhall.org/gpg-key > > -- > Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at companys(a)stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech -- Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at companys(a)stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE

1 0