My two cents worth. Considering the technical difficulties in cheating nationally. We might finally realize the dream of clean and fair elections on the national level. Specially with PLUG on the job. Ehem ehem (plugging PLUG)
I'm afraid however that cheating will simply be done locally by sabotaging, destroying or simply invalidating the machines credibility by destroying the seals of the voting machines before, during or after the elections. Therefore forcing the local elections to be postponed or use a manual system again. If done nationally, halata. But if done locally, specially in isolated regions, they could simply blame the MILF or Abu's. (are the bombings recently a dry run to condition our minds to accept that bombings on election day are not totaly out of the question) In a tightly contested race whether local or national. This could be enough to win. I harken back to SysAdmin 101: Secure the server physically first! Otherwise, all bets are off. Is the comelec putting up guidelines for physical protection of the server? Because from why I know, police and military men are not allowed within 100 meters of the precints for fear of intimidation tactics. Has this been revised? If not, are we arming the teachers then? (just kidding by the way). How do we protect the integrity of the machines? I for one do not wish for all this technical planning and expertise go to waste because our corrupt politicians will simply force the use of manual systems because that is the system they know how to "hack". Regards, Danny Ching On Jul 14, 2009, at 2:13 PM, Pablo Manalastas <[email protected]> wrote: > > My GPG 1.4.9 supports the following algorithms: > > Pubkey: RSA, RSA-E, RSA-S, ELG-E, DSA > Cipher: 3DES (S2), CAST5 (S3), BLOWFISH (S4), AES (S7), AES192 (S8), > AES256 (S9), TWOFISH (S10) > Hash: MD5 (H1), SHA1 (H2), RIPEMD160 (H3), SHA256 (H8), SHA384 (H9), > SHA512 (H10), SHA224 (H11) > Compression: Uncompressed (Z0), ZIP (Z1), ZLIB (Z2), BZIP2 (Z3) > > So GPG uses AES256 only for encryption/decryption, and not for > computing hashes. I think SHA256 should work just fine. > > //PManalastas > > > --- On Tue, 7/14/09, Ariz Jacinto <[email protected]> wrote: > >> From: Ariz Jacinto <[email protected]> > >> Hi Pablo, >> >> There's a problem with that suggestion since MD5[1] and >> SHA1[2] are >> both vulnerable to hash collisions[3]. Try AES-256 :-D >> >> [1] http://www.mscs.dal.ca/~selinger/md5collision/ >> [2] http://csrc.nist.gov/groups/ST/hash/statement.html >> [3] http://en.wikipedia.org/wiki/Collision_%28computer_science%29 >> [4] http://www.schneier.com/blog/archives/2009/07/ >> new_attack_on_a.html >> >> >> >> 2009/7/13 Pablo Manalastas <[email protected]>: >>> ....We can suggest to Comelec to compute SHA1 or MD5 >> checksums of the approved programs, and at election time, >> the checksums can be recomputed (manually) and if the >> original checksum and new checksum agree, then there is no >> substitution. > _________________________________________________ > Philippine Linux Users' Group (PLUG) Mailing List > http://lists.linux.org.ph/mailman/listinfo/plug > Searchable Archives: http://archives.free.net.ph _________________________________________________ Philippine Linux Users' Group (PLUG) Mailing List http://lists.linux.org.ph/mailman/listinfo/plug Searchable Archives: http://archives.free.net.ph
