July 2018 - cypherpunks-legacy

Re: [silk] Everyone's surveilling
by Binand Sethumadhavan 06 Jul '18

06 Jul '18

On 12/09/2007, shiv sastry <cybersurg(a)gmail.com> wrote: > On Tuesday 11 Sep 2007 11:03 pm, ashok _ wrote: > > > do you have any statistics to this effect... that cameras have reduced > > or prevented crime ? > > Yes > > http://www.thefoucauldian.co.uk/bb.htm > "The statistics show that video surveillance can improve security. With 90 % > of banks now fitted with cameras, 50 % of robbers are identified and arrested > within two years. Thanks to video surveillance in the Paris metro, 83 % of > incidents are now detected, and arrests have risen by 36 %. The use of this > technology in department stores has reduced shoplifting by two thirds. " On the other hand, see this article (from slashdot): http://www.thisislondon.co.uk/news/article-23412867-details/Tens+of+thousan… (or http://tinyurl.com/2n6zrz) "A comparison of the number of cameras in each London borough with the proportion of crimes solved there found that police are no more likely to catch offenders in areas with hundreds of cameras than in those with hardly any". Binand ----- 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

High assurance cryptographic interface specification
by dan＠lanz.us 06 Jul '18

06 Jul '18

I have been involved for the past several years in the development of a specification Common Interface to Cryptographic Modules (CICM) that defines an application programming interface specifically for high assurance cryptographic modules. High assurance modules are typically developed by countries for their government, diplomatic and military communications. The interface differs from commercial interface standards like PKCS#11 primarily for its support for domain separation, but also for the richer module and key management capabilities required by high assurance modules. To my knowledge, CICM is the first generic high assurance API that has been developed. There has been considerable interest in the specification in the high assurance community. The specification has recently been submitted to the Internet Engineering Task Force (IETF) as an Internet Draft and is available at https://datatracker.ietf.org/drafts/draft-lanz-cicm/ . I would like to encourage interested individuals to participate in the standardization process through the IETF. If you have an interest in this effort, feel free to sign up for the IETF CICM mailing list by visiting https://www.ietf.org/mailman/listinfo/cicm . Dan --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo(a)metzdowd.com

1 0

High assurance cryptographic interface specification
by dan＠lanz.us 06 Jul '18

06 Jul '18

I have been involved for the past several years in the development of a specification Common Interface to Cryptographic Modules (CICM) that defines an application programming interface specifically for high assurance cryptographic modules. High assurance modules are typically developed by countries for their government, diplomatic and military communications. The interface differs from commercial interface standards like PKCS#11 primarily for its support for domain separation, but also for the richer module and key management capabilities required by high assurance modules. To my knowledge, CICM is the first generic high assurance API that has been developed. There has been considerable interest in the specification in the high assurance community. The specification has recently been submitted to the Internet Engineering Task Force (IETF) as an Internet Draft and is available at https://datatracker.ietf.org/drafts/draft-lanz-cicm/ . I would like to encourage interested individuals to participate in the standardization process through the IETF. If you have an interest in this effort, feel free to sign up for the IETF CICM mailing list by visiting https://www.ietf.org/mailman/listinfo/cicm . Dan --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo(a)metzdowd.com

1 0

Re: [silk] Everyone's surveilling
by Binand Sethumadhavan 06 Jul '18

06 Jul '18

On 12/09/2007, shiv sastry <cybersurg(a)gmail.com> wrote: > On Tuesday 11 Sep 2007 11:03 pm, ashok _ wrote: > > > do you have any statistics to this effect... that cameras have reduced > > or prevented crime ? > > Yes > > http://www.thefoucauldian.co.uk/bb.htm > "The statistics show that video surveillance can improve security. With 90 % > of banks now fitted with cameras, 50 % of robbers are identified and arrested > within two years. Thanks to video surveillance in the Paris metro, 83 % of > incidents are now detected, and arrests have risen by 36 %. The use of this > technology in department stores has reduced shoplifting by two thirds. " On the other hand, see this article (from slashdot): http://www.thisislondon.co.uk/news/article-23412867-details/Tens+of+thousan… (or http://tinyurl.com/2n6zrz) "A comparison of the number of cameras in each London borough with the proportion of crimes solved there found that police are no more likely to catch offenders in areas with hundreds of cameras than in those with hardly any". Binand ----- 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: saving files to blockchain
by Bryce Lynch 06 Jul '18

06 Jul '18

On Wed, Feb 27, 2013 at 7:13 AM, Eugen Leitl <eugen(a)leitl.org> wrote: > ----- Forwarded message from Karel Bmlek <kb(a)karelbilek.com> ----- > > From: Karel Bmlek <kb(a)karelbilek.com> > Date: Wed, 20 Feb 2013 09:09:34 +0100 > To: Cypherpunks list <cypherpunks(a)al-qaeda.net> > Subject: saving files to blockchain > > I built a way to save any arbitrary files to the namecoin blockchain. > (so you can save any stuff forever and anonymously) > The Namecoin codebase hasn't been touched for over a year. It's dead as the proverbial doornail. These are worth investigating, however: https://xcayp.com/ http://pouchdb.com/ -- The Doctor [412/724/301/703] [ZS] https://drwho.virtadpt.net/ "I am everywhere." -- You received this message because you are subscribed to the Google Groups "ZS-P2P" group. To unsubscribe from this group and stop receiving emails from it, send an email to zs-p2p+unsubscribe(a)googlegroups.com. To post to this group, send email to zs-p2p(a)googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. ----- 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

[tahoe-dev] Weekly Dev notes, 20-Dec-2012
by Brian 06 Jul '18

06 Jul '18

It's our last weekly chat of the year! Here are some notes: in attendance: Zooko (scribe), Marlowe, freddyb, amiller, David-Sarah, Warner (late) * translation: Rana from the Tor project walked Marlowe through workflow; Their git repo is checked by transifex. Transifex git pulls their repo. The one thing we have to do manually is that transifex has no way to check for malicious coding added in translations, like XSS/injection-style attacks. Transifex maintains a glossary of "one-offs", words that appear. voulnet does translations for Guardian Project and Tor and would be interested in doing Tahoe-LAFS as well. * Tenerife, Blake2 * ticket notes: #937, #1159, #1539: land them! #1240: probably ready to land #1525: if tests can be made to pass, land it! #1298: trivial, let's land it. If DS doesn't land by this weekend, warner will. #1643: DS will poke at it, else warner will try to fix #1679: warner will try to write a test, test_client.NodeMaker #166: DS will consider 166-3.diff, if no objections by this weekend, warner will land. The -d issue can be figured out for 1.11 #1732: warner will try to write a patch this weekend #1802: warner will write the patch #1735: warner will review and land #1777: warner will land rest of 1.10 tickets: can be landed if simple, else kick out to 1.11 * 1.10: warner will make a push this weekend and over holidays. Goal is to get a 1.10-alpha1 out by xmas, then aim for 1.10-final by late January. * leasedb * warner still needs to review davidsarah/1818-leasedb * we still need to implement starter-lease code before landing 1818-leasedb, probably in january * DS will rebase 1819-cloud-merge on top of 1818-leasedb * DS decided to stick with separate SI,shnum columns instead of a single merged shareid column: sqlite accepts foreign keys and unique keys and handles primary keys well enough that quota-measuring queries (finding unique lists of shares owned by a given account) are simple, or at least they can't be simplified enough to justify the denormalization hit * DS will consider adding the additional leasedb state-transitions to the docs (COMING->GONE when the upload process is interrupted before the backend creates any part of the share object, STABLE->GONE when the shares are deleted out-of-band, GOING->GONE when the share deletion process is interrupted but completes anyways), even before those transitions are actually implemented. There will be no dev call next week on 27-Dec-2012. We'll meet again 03-Jan-2012. happy holidays! -Brian _______________________________________________ tahoe-dev mailing list tahoe-dev(a)tahoe-lafs.org https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev ----- 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

[tahoe-dev] weekly Tahoe dev call report: 2012-07-10
by Zooko Wilcox-O'Hearn 06 Jul '18

06 Jul '18

b" 1.9.2 release! Yay David-Sarah, Release Manager. Thanks to everyone who contributed bug reports, patches, testing, packaging, etc. b" Add-only sets: Can servers exercise "editorial power" over add-only sets, remixing different legitimate adder-signed sets to form new sets? Zooko thinks this could be a problem, and that add-only sets should be designed against it, but he can't remember why he thinks that. Brian thinks that it is hardly a problem because the presence of other servers giving answers renders any one server's ability to select among legitimate answers almost moot. Andrew and David-Sarah both think that the notion of a *set* as opposed to a fully serialized sequence must surely require that readers accept unions. We agreed to drop the subject for now and move on to lease database. b" lease database b" keep information about leases in some separate location instead of bundled with each share b" let's use a sqlite db through the pysqlite API, like we do with backupdb b" for the cloud backend (that Least Authority Enterprises is building), the leasedb will be stored on persistent storage e.g Amazon Elastic Block Store (EBS), while the shares are stored on cloud storage, e.g. Amazon Simple Storage Service (S3). b" people can manually add shares, such as by just dropping a share file into a disk backend filesystem, or uploading a share object to Amazon S3, and the lease system will eventually discover them and maintain them as long as they are leased, and then delete them when they are no longer leased. b" people can manually delete shares, such as by just rm'ing a share file from a disk backend filesystem, or deleting a share object to Amazon S3, and the lease system will not break when it discovers that it is gone. b" There can be race conditions between such external actions and the progress of the crawler which is inspecting leases. A state machine must be carefully analyzed to see that in handles all such possible sequences of events. See https://tahoe-lafs.org/trac/tahoe-lafs/wiki/Summit2Day4#leasedbcrawler for initial notes about that. A state transition diagram would be a good way to analyze and communicate that. b" Brian was about to write a new lease database as the next step in his Accounting work, and Least Authority Enterprises is about to write a new lease database as the next step in our DARPA research grant contract, with a deadline of July 26. So, let's cooperate. We need to agree on separation of responsibilities. b" The crawler can be a "background task" that doesn't take up resources (CPU) for too long at a time, so there's a configurable knob for "how many seconds in a row do I run" and "how many seconds do I idle in between runs", and another knob for "how soon should I start a new pass after I've already finished the last pass". b" Should "account ids" or "lease-owner ids" be public keys or things derived from symmetric secrets? Brian wisely suggests decoupling that question from the rest of the lease db design. But, then Brian and David-Sarah agreed that the lease-owner ids should be small integers. Zooko disagrees, but nobody asked him. b" Least Authority Enterprises might someday want to store their lease databases in funky cloud databases things like Amazon's Cloud SQL DB or Microsoft's Cloud SQL DB. But for now we're just going to use pysqlite and local storage such as Amazon EBS. Brian will review his branch and write up some stuff about how the accounting branch ought to go. Brian and David-Sarah will synchronously work on it Tuesday and Thursday. _______________________________________________ tahoe-dev mailing list tahoe-dev(a)tahoe-lafs.org https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev ----- 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

[Dewayne-Net] China Tightens Its Restrictions for News Media
by Dewayne Hendricks 06 Jul '18

06 Jul '18

on the Internet Reply-To: dewayne(a)warpspeed.com [Note: This item comes from reader John McMullen. DLH] >From: "John F. McMullen" <observer(a)westnet.com> >Date: September 25, 2005 10:58:53 PM PDT >To: "johnmac's living room" <johnmacsgroup(a)yahoogroups.com> >Cc: Dewayne Hendricks <dewayne(a)warpspeed.com>, Dave Farber ><farber(a)cis.upenn.edu> >Subject: China Tightens Its Restrictions for News Media on the >Internet > > >From the New York Times -- <http://www.nytimes.com/2005/09/26/ >international/asia/26china.html? >ex=1285387200&en=38ac65b7be2e2b9b&ei=5090&partner=rssuserland&emc=rss> > >China Tightens Its Restrictions for News Media on the Internet >By JOSEPH KAHN > >BEIJING, Sept. 25 - China on Sunday imposed more restrictions >intended to limit the news and other information available to >Internet users, and it sharply restricted the scope of content >permitted on Web sites. > >The rules are part of a broader effort to roll back what the >Communist Party views as a threatening trend toward liberalization >in the news media. Taken together, the measures amount to a stepped- >up effort to police the Internet, which has become a dominant >source of news and information for millions of urban Chinese. > >Major search engines and portals like Sina.com and Sohu.com, used >by millions of Chinese each day, must stop posting their own >commentary articles and instead make available only opinion pieces >generated by government-controlled newspapers and news agencies, >the regulations stipulate. > >The rules also state that private individuals or groups must >register as "news organizations" before they can operate e-mail >distribution lists that spread news or commentary. Few individuals >or private organizations are likely to be allowed to register as >news organizations, meaning they can no longer legally distribute >information by e-mail. > >Existing online news sites, like those run by newspapers or >magazines, must "give priority" to news and commentary pieces >distributed by the leading national and provincial news organs. > >This restriction on the ability of Web sites to republish articles >produced by the huge array of news organizations that do not fall >under direct government control seems intended to ensure that the >Propaganda Department has time to filter content generated by local >publications before it can be widely disseminated on the Internet. > >The new rules are the first major update to policies on Internet >news and opinion since 2000. > >"The foremost responsibility of news sites on the Internet is to >serve the people, serve socialism, guide public opinion in the >right direction, and uphold the interests of the country and the >public good," the regulations state. > >Although Chinese authorities have already effectively unlimited >powers to control the gathering and publication of news, the >Propaganda Department has sometimes struggled to censor information >about delicate developments before it circulates on the Internet. > >About 100 million Chinese now have access to the Internet. Though >the government closely monitors domestic content and blocks what >officials consider to be subversive Web sites from overseas, savvy >users can obtain domestic and overseas information that never >appears in China's traditional news media. > >By the time officials have decided that a topic might prove harmful >to the governing party's agenda, an item about it has often already >been posted or discussed on hundreds of sites and viewed by many >people, defeating some traditional censorship tools. > >Experts who follow the Internet say one of the most significant >changes is the ban on self-generated opinion and commentary >articles that accompany the standard state-issued news bulletins on >major portal sites. > Weblog at: <http://weblog.warpspeed.com> ------------------------------------- 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.07100, 11.36820 http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE [demime 1.01d removed an attachment of type application/pgp-signature which had a name of signature.asc]

1 0

[IP] China Tightens Its Restrictions for News Media on the Internet
by David Farber 06 Jul '18

06 Jul '18

Begin forwarded message:

1 0

Re: [p2p-hackers] p2p-hackers Digest, Vol 51, Issue 8
by Ray Dillinger 06 Jul '18

06 Jul '18

On Sun, 2010-11-28 at 01:38 +0700, Jirtme Prudent wrote: > Hi! > > Sorry for the off topic (and the stupidity of the question), but could > you briefly explain me what's wrong with the use of UDP? > > Thanks! HTTP is not specified as a UDP protocol and extant browsers don't generally speak UDP. Aside from that, most of the things transmitted by HTTP (coded webpages, client-side programs, and compressed graphics) are prone to catastrophic failure from small errors, and UDP is prone to small errors. UDP does not contain any provision for correction of transmission errors. When a packet is transmitted over the internet, there is a chance that it will be corrupted en route. Electrical noise at a switch, a radio station too near a cable, cosmic rays, etc... these are all things which can cause a bit or byte or word to be different at the recieving end than it was at the transmitting end. TCP/IP is an error-correcting protocol that uses incremental checksums to detect transmission errors, so that the recieving end can say, "wait a minute, could you resend packet number 12?" or something when it realizes that it missed something or got a bad copy of something. This is a good thing because it reduces or eliminates errors, but it introduces roundtrip delays as the sender and receiver negotiate to make sure all the checksums and so on are correct. HTTP is a TCP/IP protocol that introduces several other mechanisms to try to deal with its intensive usage of bandwidth, and one of these was (is) "slow-start." "slow-start" says you don't transmit more than 4 packets before the receiver notifies you about whether the first one was received intact. After the receiver has acknolwedged the first 4 packets, you can assume that it's okay to have 5 packets "in flight" out there. After the receiver has acknowledged the next 5 packets, you can assume that it's okay to have 6 packets "in flight" out there. And so on. This whole thing was an effort not to overrun buffers along the way, not to transmit faster than the receiver could buffer and process the data, and so on. Slow-start was a good thing when it was developed, because at the time network latency was usually a small fraction of transmission time. Waiting for the acknowledgement to arrive usually didn't noticeably delay the transmission of additional packets. But things have changed. The bandwidth of our pipes, the size of our buffers, and the speed of our transmission has gone way up, switching speeds have gone up but have not kept pace, the number of hops on the trip from transmitter to receiver is now one or two jumps longer which eats the gains from faster switching times, and the speed of light has remained obnoxiously constant. So at this point the servers are sending four packets, then twiddling their thumbs for a *LONG* time (relative to the time it takes to transmit them) before the acknowledgement packet gets back and they can send the next packets. Google wants to change slow-start by increasing the initial number of packets to compensate for the increases in buffering capability and pipe length relative to transmission speed. I think this is probably a good idea. Bear _______________________________________________ p2p-hackers mailing list p2p-hackers(a)lists.zooko.com http://lists.zooko.com/mailman/listinfo/p2p-hackers ----- 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