July 2018 - cypherpunks-legacy

Re: VoIP, Tor and Zfone by Phillip Zimmermann?
by Anothony Georgeo 06 Jul '18

06 Jul '18

I Forgot to mention, Here are a few good links: 1. "Feds fund VoIP tapping research" http://news.com.com/Feds+fund+VoIP+tapping+research/2100-7348_3-5825932.htm… part=rss&tag=5825932&subj=news 2. "Crytpo-Gram: VoIP Encryption" http://www.schneier.com/crypto-gram-0604.html#5 I like the idea of anonymous, secure (eg. DH authentication, etc) and end-to-end encrption (via. TLS)for VoIP calls. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com 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

[silk] Blackberry in India
by Gautam John 06 Jul '18

06 Jul '18

http://economictimes.indiatimes.com/At_last_govt_cracks_BlackBerry_code/art… At last, govt cracks BlackBerry code 22 Sep, 2008, 0121 hrs IST,Niranjan Bharati, ET Bureau NEW DELHI: The government has decrypted the data on Research In Motion's (RIM) BlackBerry networks. The department of telecommunication (DoT), Intelligence Bureau and security agency National Technical Research Organisation (NTRO) have done tests on service providers such as Bharti Airtel, BPL Mobile, Reliance Communications and Vodafone-Essar networks for interception of Internet messages from BlackBerry to non-BlackBerry devices. Initially, there were difficulties in cracking the same on Vodafone-Essar network but that has also been solved. This means that the e-mail messages sent on Internet through your BlackBerry sets would no longer be exclusive and government would be able to track them. "Decompression is being tested in operator's network with three successful testing on Bharti Airtel, Reliance Communication and BPL Mobile," a source in DoT said. He, however, added that the solution reached upon would not be shared with anybody including the national telecom service providers like BSNL or MTNL. "The test is being conducted wholly for non-enterprise solutions," he said. The Union cabinet has also been apprised of the recent developments by the DoT. Makers of BlackBerry set, RIM, could not be contacted for comment. An e-mail sent in this regard the company did not elicit any response till the time of going for press. An official in Vodafone-Essar, however, on conditions of anonymity said that there has been substantial progress in decoding the BlackBerry encryptions and DoT has got success on decompressing the data on the networks of all the major service providers. The test would be conducted on all the network of all the BlackBerry service providers and the service providers, on whose network the interception does not happen smoothly, would be asked to make technical changes in their services to make them compatible for decompression. Decompression is the process of decoding information with an aim to transfer the data to a different medium like data to voice, data to video or data to text. The DoT had earlier asked RIM to provide the master key to allow access to contents transferred over their handsets. RIM had, however, said that it could not handover the message encryption key to the government as its security structure does not allow any third party or even the company to read the information transferred over its network. The BlackBerry issue surfaced earlier this year when DoT asked Tata Tele-services to delay the launch of the service till appropriate security mechanisms were in place. Currently, there are over one lakh BlackBerry users in the country. Bharti Airtel, Reliance Communications, Vodafone Essar and BPL Mobile are offering this service in the country. Tata Teleservices has also been allowed to offer the BlackBerry services recently. Incidentally, Tata Teleservices launched the service after telecom secretary Siddhartha Behura said that the government has no role in stopping the company from offering the service. -- Please read our new blog at: http://blog.prathambooks.org ----- 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: Client Certificate UI for Chrome? [OT anonymous-
by Ray Dillinger 06 Jul '18

06 Jul '18

transaction bull***t] [Moderator's note: this is getting a bit off topic, and I'd prefer to limit followups. --Perry] On Wed, 2009-08-19 at 06:23 +1000, James A. Donald wrote: > Ray Dillinger wrote: >> If there is not an existing relationship (first time someone >> uses an e-tailer) then there has to be a key depository that >> both can authenticate to, with a token authorizing their >> authentication to authenticate them to the other, which then >> vouches to each for the identity of the other. > > Actually not. > > What the seller wants to know is that the buyer's money is good, not > what the true name of the buyer is - a service provided by Visa, or > Web-money, or some such. No. This juvenile fantasy is complete and utter nonsense, and I've heard people repeating it to each other far too often. If you repeat it to each other too often you run the risk of starting to believe it, and it will only get you in trouble. This is a world that has not just cryptographic protocols but also laws and rules and a society into which those protocols must fit. That stuff doesn't all go away just because some fantasy-world conception of the future of commerce as unlinkable anonymous transactions says it should. In any transaction involving physical goods, the seller also wants to know to whom to ship the product. Since the laws in most nations do not require the recipient of an erroneous shipment to return the goods and *do* require the seller to give back the buyer's money if the shipment doesn't go where the buyer wants it, sellers really care that the correct recipient will receive the package and really need some way to contact the buyer in case there's a mistake about the recipient address or identity. Otherwise you'd get people playing silly buggers with the shipping address to get out of paying for million-dollar equipment. The law usually requires that the recipient of defective goods or services has the ability to return those goods for a refund or obtain a refund in the event of seller nonperformance of services or nonshipment of goods. Since such returns can be used to launder money from illegal enterprises, laws usually restrict anonymous returns. Therefore the seller needs the buyer's (or client's) identity in order to comply with the law. In information-based transactions involving IP that's subject to copyright or trade secret protection (which is effectively all of them since other IP can be had for free) the seller also wants to know who is the licensee that's bound by the terms of the license and who now poses a "risk" of copyright breakage. In both cases this is a liability taken on by the buyer, and not something that his "money being good" for just the transaction price can ameliorate. In financial transactions The seller also wants to know that s/he can comply with, eg, "know your customer" laws and avoid liability for gross negligence in, eg, money laundering cases. In many transactions the seller wants the buyer's identity and a liability waiver signed by the buyer so as to keep track of or avoid liability for what the customer is going to do with his/her products. Most sellers want the ability to offer the buyer credit terms, especially when large sums are involved. And even where money is supposedly firm (like the money Bernie Madoff's clients had in their accounts) it is subject to catastrophic vanishment in extraordinary circumstances. The seller needs to know whom to sue or at least whose name to put on the forms for their insurance claim if contrary to expectations the buyer's money turns out not to be good. If the cert authority does not provide the identity of the buyer but asserts that the buyer's money is good, and this turns out not to be true (as in the case of Madoff's clients), then in most legal systems the cert authority is either liable, or can expect to be sued in a very expensive empirical test of liability. So the cert authority doesn't want to be in the business of vouching for the ability of anonymous people to pay. The only way for the money to be truly firm for these purposes is that the cert authority has it in escrow. This makes the cert authority a financial institution and therefore subject to "know your customer" mandatory reporting, data retention laws, subpeonas, and so on. Also, it introduces a needless delay and complication to the transaction that legitimate buyers and sellers would mostly rather not have. Also, in any large transaction the seller or cert authority or both must retain buyer identity information in order to be able to comply with subpeonas, inquests, or equivalent writs, for periods ranging from zero in a few undeveloped african nations to five years in much of the rest of the world. In most of the nations on earth, there is such a thing as sales tax or use tax on goods or services, and any transaction involving more than a tiny sum must be reported (with the names of buyer and seller) to relevant tax authorities. Even tiny transactions must be reported in aggregate, although these usually don't require the buyers' names. Since the seller has the legal obligation to report, s/he also has the legal obligation to collect identity information from his/her clients. Most nations are very sensitive about cross-border money flows, have tax laws that apply specifically to international transactions, and want to know such things as the buyer and seller identity. In this case it is the legal obligation of both buyer and seller in international transactions to collect whatever information their particular nation requires them to have and report it according to their particular nation's laws. And so on. Maybe in a cypherpunk world where there are no laws other than the natural laws of mathematics, no physical world in which goods have to be manufactured and delivered, no national borders or third parties having a tax or legal interest in transactions, no information other than valuable secrets subject to no post-sale copyrights or licensing, no liability laws or customers-rights laws whatsoever, no taxation, and a bunch of other bizarro-world conditions, the seller would not need anything more than the knowledge that the buyer's money was good. But that's like proving that a pig can fly starting from an assumption of an ideal, spherical pig of zero mass. It is not the world in which we live, unless we are black-marketeers in international waters, not subject to the laws of any nation. If you make it "optional" - where people can request a true name etc when they need it to comply with law, but don't have to request it otherwise - you will find that the number of sellers willing to do business with anonymous buyers, and the number of transactions in which they legally can do business with anonymous buyers, starts low and then drops rapidly as legal troubles and scams of various kinds, as well as new laws designed to prevent those troubles and scams, catch up to the sellers. Anyway, nothing's preventing you from building your "unlinkable" cert system to compete with other forms of commerce. But in the presence of any other system whatsoever, I expect almost no one to use it and predict that using it or running services that allow people to use it will rapidly become illegal in all developed nations. > Again, you are trying to inject a certificate authority into the > middle > of a relationship where it is just not very useful. Perhaps there are other ways to achieve all of the requirements for a system that people can use while complying with applicable laws. I cannot think of a simpler or more useful one. > Ebay does not care > about true names. Aside from being irrelevant because ebay does not function as a buyer or seller, and only minimally as a cert authority in their client's auctions (in particular they do NOT vouch for anyone's ability to pay), this is blatantly false. Ebay cares about true names, and linkable information such as bank account numbers. Without them it won't let you use its payment system. Also, try funding an ebay seller's account using just cash somehow and tell me how it goes. It used to be possible but it's been several years since the law bounced on ebay for allowing that and commanded them to collect true name information from all sellers. Also remember ebay has to collect its fee from somebody and until the auction's conclusion doesn't know how large that fee is going to be. They insist on knowing who that somebody is. Bear --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo(a)metzdowd.com

1 0

Re: [p2p-hackers] Pirate Pay
by Tom Ritter 06 Jul '18

06 Jul '18

On 14 May 2012 18:48, James A. Donald <jamesd(a)echeque.com> wrote: > Some design characteristics: > > *. Peers are identified by a durable public key. > > *. Peers interact with keys they do not trust, but expect protocol > conformance and prosocial behavior only from keys they trust. Peers limit > their exposure to non trusted keys so that they can suffer only limited > damage from non trusted keys deviating from protocol or otherwise > misbehaving. > > *. Peers may not only trust Bob, but transitively everyone Bob trusts, and > everyone that those peers trust ... If this works, they increase their > transitive trust in Bob, if it fails they decrease their transitive trust. > > *. Prosocial behavior consists of conforming to protocol, storage > availability, with valuable, or at least demanded, stuff in storage and > accessible on demand, and paying ones bandwidth and storage debts. Since > networks are unreliable, perfect protocol conformity is never expected or > demanded, but the burden that one's deviations from protocol place on other > peers counts against one's karma. Hm. I'm not sure how to bootstrap when you only want to interact with people you trust - but it seems like this could be a model for a Web of Trust that grows over time if you have a way to validate what people are supposed to be sending. I am Alice and I interact with 1000 other people, Bobs1-1000, who send me pieces of a file. They're valid, so I sign their public keys saying they were good for some number of bytes, send them the signature, but also keep it locally. I send data to 50 other people, Carols1-50 who in turn give me signatures. Over time, I interact with Bob50 again, and trust him based on my previous signature. I find a Dave, who I trust a little because he has a signature from Bob600, and Bob600 was good to me. The key pieces (and why this couldn't work for distributed DNS) are that I know that Bob[x] sent me is valid because I have the information to build a merkle tree and validate his piece. The more I download, the more people I 'trust' because they were honest actors last time. The more I upload, the more people 'trust' me because I acted honestly in the past. But I may have reinvented something simple or missed an obvious flaw, because I'm not well-versed in how DHT works, or anything published in this area. -tom _______________________________________________ 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

Re: VoIP, Tor and Zfone by Phillip Zimmermann?
by Anothony Georgeo 06 Jul '18

06 Jul '18

I Forgot to mention, Here are a few good links: 1. "Feds fund VoIP tapping research" http://news.com.com/Feds+fund+VoIP+tapping+research/2100-7348_3-5825932.htm… part=rss&tag=5825932&subj=news 2. "Crytpo-Gram: VoIP Encryption" http://www.schneier.com/crypto-gram-0604.html#5 I like the idea of anonymous, secure (eg. DH authentication, etc) and end-to-end encrption (via. TLS)for VoIP calls. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com 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

[cryptography] Fwd: Answers to some of your questions (Silent Circle responds..)
by Ali-Reza Anghaie 06 Jul '18

06 Jul '18

This was circulated on libtech and here it is for your consideration too. It confirms some of the ramblings on the pad, disposes of some others, .. Also attached is a condensed version of the pad after "summary" was put at the top. Cheers, -Ali ---------- Forwarded message ---------- From: Jon Callas <jon(a)silentcircle.com> Date: Thu, Feb 14, 2013 at 11:28 AM Subject: Answers to some of your questions To: Ali-Reza Anghaie <ali(a)packetknife.com> Cc: Jon Callas <jon(a)silentcircle.com> Hi, Ali-Reza. I saw your pastebit with some questions, and let me answer. You may repost this mail to liberation tech or anywhere else. * A Latvian company wrote most of the software, not SilentCircle When we formed Silent Circle, we looked around for people to partner with. We selected Tivi because they're really cool people -- I used their ZRTP-enabled VOIP client back in the days when I had a Nokia N95. We picked them in part because they were willing to release source code. (Other potential partners were not willing.) Our partnership with them includes that code base, and that they work for us full-time now. They're some of our main developers now. I have a bit of a raised eyebrow at this comment. (Yes, I know it's not your words, you're also explaining.) It sounds to me like whoever is making that comment is implying that there's something wrong with Latvia. Riga was for many, many years a center of European high-tech until the dark days of WWII and Soviet occupation. It's a lovely place filled with incredibly smart, friendly people. It is a part of the EU, and also a NATO nation. Our team in Riga. We picked them because they rock. Perhaps the comment comes from the fact that they were in business before our partnership. It's relatively common in high-tech that companies enter into partnerships with others. Google, Microsoft, Apple, Facebook, and others often use some sort of relationship like this to get software or technologies that they didn't have, so that it speeds up development. We are hardly unique in this. Perhaps I don't understand. If someone could explain the objection to me, I'm happy to address it further. * Application is designed for VoIP, not specifically for Security It's a secure VOIP client. Because of its history, there's a lot of latent capability in it that is VOIP related. Is there an actual question or objection? * It does use an outdated SSL library (PolarSSL 1.1.1) with some known security vulnerabilities ? No, we're using PolarSSL 1.1.4. We did not include the PolarSSL code in the drop because we didn't want to figure out the licensing details. * It does not use LibZRTP by Philip Zimmermann used in Zfone but ZRTPCPP That is correct. We're using Werner Dittmann's library. We like it. We like it so much that Werner is working for us. Werner rocks. * It does use an outdated version of ZRTPCPP library? I don't believe so. If anything, we're using a version of it that is newer than anyone else's; Werner works for us, now. Should we need release a new version, we will. * It does reveal their test/development server? - "I wonder if they are hiring new iOS devs now?" Yes, we are. We also need Android devs, and need them more than iOS devs. Feel free to send risumis to <jobs(a)silentcircle.com>. Note that we are a highly-distributed company with developers and staff stretched from Latvia to Greece, to the Pacific West. Location almost does not matter. 31337 skillz do. I will also note that the code of the VOIP system is the same across all our apps. It gets compiled for iOS and Android, as well as Windows (Silent Eyes). Each OS has its own UX skin on top of the code VOIP system. - "I'd say anything that gets Silent Circle to actually answer questions proper is useful, if that is the result." Feel free to send questions to me, or to "security(a)silentcircle.com" * In ./silentphone/tiviengine/prov.cpp there is some kind of provisioning protocols, used probably to auto-configure the voip clients. Good catch! Yes, indeed, we provision the clients ourselves. Silent Circle is a *SERVICE* not an app. * It should be evaluated the capability for a government censoring/filtering host to block the user out by blocking accounts.silentcircle.com or sccps.silentcircle.com. Maybe some dynamic methods is in place? We'd love to hear suggestions. If someone's suggestion is particularly clever, feel free to attach a risumi. * It should be asked what are the privacy handling for those data and if those can be additionally "privacy enforced" . Feel free to ask. I don't understand the question, myself. * QUESTION: What this certificate is used for ? TODO: We should check to see if this certificate is used for TLS Validation? If so that's cool, that it does not rely on third party CA. Got it in one! Thank you for thinking it's cool. Again, feel free to forward this mail to anyone, and I'm happy to entertain questions from anyone. Jon ----- Jon Callas Chief Technical Officer Silent Circle, LLC email: jon(a)silentcircle.com Silent Phone: jon NOTE: The original pad is being vadalized. A backup of the content, before nonsense, of that pad can be had at http://pastebit.com/pastie/12001 for background reading. A Summary of the useful parts of that pad is: - The TiViPhone base appears to be an acquisition by SilentCircle and the (c) reflects that. Also a number of the TiViPhone employees are SC employees. - The ZRTPCPP library being used is also maintained primarily by a SC employee and is not entirely unrelated. - We do not have a clear source vs binary tree relationship here and can't vouch that the code that has been released is a fully accurate representation of the product Silent Circle has shipped. What remains below is now the "meat" of the interesting discussion. CODE: https://github.com/SilentCircle --- * It does use an outdated SSL library (PolarSSL 1.1.1) with some known security vulnerabilities ? ??? Latest version is 1.2.5 (2013-02-02), the project seems very active as 1.1.1 has been released 2012-01-23 ??? PolarSSL Security Advisory: https://polarssl.org/tech-updates/security-advisories (most recent advisory Feb 2nd) . ??? PolarSSL Changelog https://github.com/polarssl/polarssl/blob/master/ChangeLog ??? they embed 1.1.1 and 1.1.4 in libs, but I only find 1.1.1 usage in the code ??? TODO: It should be checked in details if that 1.1.1 is vuln and/or patched to some of the advisory. ??? ^--- PolarSSL 1.1.1 suffers from "Weak Diffie-Hellman and RSA key generation": https://polarssl.org/tech-updates/security-advisories/polarssl-security-adv… ??? Easily a non-issue as w/ many other projects. Verifying against binaries is tougher. The updated codebase that was uploaded does not appear to show signs of back-ported patching so they keep upgrading the version they use - perfectly reasonable as long as we can get an idea of what is exactly used in each subsequent release to the App Store and Google Play. --- * It does use an outdated version of ZRTPCPP library? Looking at libs/zrtp/Changelog it does use ZRTPCPP 1.5.2 version (released on 05-Dec-2010). Latests version is libzrtpcpp 2.3.2 (released on 20-Nov-2012) ZRTPCPP 1.5/1.6/2.3 download: http://ftp.gnu.org/gnu/ccrtp/ . --- * It does reveal their test/development server? In the file ./apple/ios/VoipPhone/settings.txt there is the hostname fs-devel.silentcircle.org with ip 50.116.49.43 Do we have that code too? It would be nice to have a full development enviornment to play with / even a fake one would have its uses. That's a nice inquiry. It would be also very interesting, while i think it's not doable technically for smartphone platforms's constraints, to have "Deterministic Building" to always have the exact checksum of files given the same build process repeated in the same environment (Unfortunately that's an hard topic, due to various timestamps and stuff that linked put into the executable files).//AppStore binaries are encrypted/heavily obfusticated... right, proving the released binary match the released source code is hard. --- Unless the build is reproducible and verifiable, releasing the source is pretty meaningless. <-- THIS <--- Seconded A release of source against each App Store or Google Play edition seems to be in order - that isn't unlike other projects spreading legs on both sides of the App Store and FOSS fence. --- TODO: It would be nice if someone could share an url with a backup of an "Installed and configured SilentCircle" to look at!. I am trying to read some code. They are just a peice of mess. Like this: smartphone/codecs/vTiVi/ep.cpp. It is like something from a decompiler (even the indentation didn't conform)+1 definitely not iOS devs --- Like this: (this is a library search path for one of the libs) "$(SRCROOT)/../../../../../Library/Developer/Xcode/DerivedData/werner_zrtp-gibkbzjaoguukggnpjvrvnwattfm/Build/Products/Debug-iphoneos" <that's very bad and stupid, if they just brought the zrtp project into the same workspace xcode would handle all of this automagically for them // I am wondering how did they get this mess run on a phone. It's very fraigle, likely this environement works on the developer's machine (lol) and was good enough to generate a binary for app store submission. If we would have gotten lucky we might have seen his username in one of the search paths but no dice. --- * In ./silentphone/tiviengine/prov.cpp there is some kind of provisioning protocols, used probably to auto-configure the voip clients. Interesting the following strings: http://sccps.silentcircle.com/provisioning/silent_phone/tivi_cfg.xml?api_ke… http://sccps.silentcircle.com/provisioning/silent_phone/settings.txt?api_ke… http://sccps.silentcircle.com/provisioning/silent_phone/tivi_cfg_glob.txt?a… const char *pLink="https://accounts.silentcircle.com";^M It should be evaluated the capability for a government censoring/filtering host to block the user out by blocking accounts.silentcircle.com or sccps.silentcircle.com. Maybe some dynamic methods is in place? --- const char *dev_id=t_getDevID_md5();^M <--- What's up with these functions? Maybe the IMEI/UDID of the Phone hashed with md5? TODO: Someone should check it! const char *dev_name=t_getDev_name();^M Only works on IOS, returns UTF8String of NSString *n = [[UIDevice currentDevice]model]; That's something like "iPhone5" or "iPhone4s"? If so, it's less privacy invasive. It should be evaluated the privacy impact of retrieving the "name" of the device (Is that the name of the phone?) that could be stored somewhere (how?). Additionally it should be considered that if the "Device ID" is an IMEI, even hashing it with MD5, could make it easily reversable by Silentcircle to retrieve it. TODO: Checkit NSString *n = [[UIDevice currentDevice]uniqueIdentifier]; These UDID's were rendered useless a while ago weren't they? There is an advertising udid framework but you can request a fresh ID whenever you want. It's IOS's ^^^ yeah. It is deprcated since iOS5: https://developer.apple.com/library/prerelease/ios/#documentation/UIKit/Ref… It should be asked what are the privacy handling for those data and if those can be additionally "privacy enforced" . --- Are UI Bugs worth finding? Sometimes they can actually lead to code execution. For example, setting your nickname to be something that can exploit the UI for nickname display and execute code... or just mislead the user? Part of the UI includes presenting security phrases for validation, it's worth scrutinizing. From an OPSEC perspective it might lead to leeks as well. --- Random iOS tidbit of information: if you go into settings.app and change any permissions for address book/photos/etc??? any applications running that require those permissions will automatically forcequit. --- QUESTION: What this certificate is used for ? TODO: We should check to see if this certificate is used for TLS Validation? If so that's cool, that it does not rely on third party CA. const char *pEntrustCert=^M "-----BEGIN CERTIFICATE-----\r\n"^M "MIIE2DCCBEGgAwIBAgIEN0rSQzANBgkqhkiG9w0BAQUFADCBwzELMAkGA1UEBhMC\r\n"^M "VVMxFDASBgNVBAoTC0VudHJ1c3QubmV0MTswOQYDVQQLEzJ3d3cuZW50cnVzdC5u\r\n"^M "ZXQvQ1BTIGluY29ycC4gYnkgcmVmLiAobGltaXRzIGxpYWIuKTElMCMGA1UECxMc\r\n"^M "KGMpIDE5OTkgRW50cnVzdC5uZXQgTGltaXRlZDE6MDgGA1UEAxMxRW50cnVzdC5u\r\n"^M "ZXQgU2VjdXJlIFNlcnZlciBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05OTA1\r\n"^M "MjUxNjA5NDBaFw0xOTA1MjUxNjM5NDBaMIHDMQswCQYDVQQGEwJVUzEUMBIGA1UE\r\n"^M "ChMLRW50cnVzdC5uZXQxOzA5BgNVBAsTMnd3dy5lbnRydXN0Lm5ldC9DUFMgaW5j\r\n"^M "b3JwLiBieSByZWYuIChsaW1pdHMgbGlhYi4pMSUwIwYDVQQLExwoYykgMTk5OSBF\r\n"^M "bnRydXN0Lm5ldCBMaW1pdGVkMTowOAYDVQQDEzFFbnRydXN0Lm5ldCBTZWN1cmUg\r\n"^M "U2VydmVyIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MIGdMA0GCSqGSIb3DQEBAQUA\r\n"^M "A4GLADCBhwKBgQDNKIM0VBuJ8w+vN5Ex/68xYMmo6LIQaO2f55M28Qpku0f1BBc/\r\n"^M "I0dNxScZgSYMVHINiC3ZH5oSn7yzcdOAGT9HZnuMNSjSuQrfJNqc1lB5gXpa0zf3\r\n"^M "wkrYKZImZNHkmGw6AIr1NJtl+O3jEP/9uElY3KDegjlrgbEWGWG5VLbmQwIBA6OC\r\n"^M "AdcwggHTMBEGCWCGSAGG+EIBAQQEAwIABzCCARkGA1UdHwSCARAwggEMMIHeoIHb\r\n"^M "oIHYpIHVMIHSMQswCQYDVQQGEwJVUzEUMBIGA1UEChMLRW50cnVzdC5uZXQxOzA5\r\n"^M "BgNVBAsTMnd3dy5lbnRydXN0Lm5ldC9DUFMgaW5jb3JwLiBieSByZWYuIChsaW1p\r\n"^M "dHMgbGlhYi4pMSUwIwYDVQQLExwoYykgMTk5OSBFbnRydXN0Lm5ldCBMaW1pdGVk\r\n"^M "MTowOAYDVQQDEzFFbnRydXN0Lm5ldCBTZWN1cmUgU2VydmVyIENlcnRpZmljYXRp\r\n"^M "b24gQXV0aG9yaXR5MQ0wCwYDVQQDEwRDUkwxMCmgJ6AlhiNodHRwOi8vd3d3LmVu\r\n"^M "dHJ1c3QubmV0L0NSTC9uZXQxLmNybDArBgNVHRAEJDAigA8xOTk5MDUyNTE2MDk0\r\n"^M "MFqBDzIwMTkwNTI1MTYwOTQwWjALBgNVHQ8EBAMCAQYwHwYDVR0jBBgwFoAU8Bdi\r\n"^M "E1U9s/8KAGv7UISX8+1i0BowHQYDVR0OBBYEFPAXYhNVPbP/CgBr+1CEl/PtYtAa\r\n"^M "MAwGA1UdEwQFMAMBAf8wGQYJKoZIhvZ9B0EABAwwChsEVjQuMAMCBJAwDQYJKoZI\r\n"^M "hvcNAQEFBQADgYEAkNwwAvpkdMKnCqV8IY00F6j7Rw7/JXyNEwr75Ji174z4xRAN\r\n"^M "95K+8cPV1ZVqBLssziY2ZcgxxufuP+NXdYR6Ee9GTxj005i7qIcyunL2POI9n9cd\r\n"^M "2cNgQ4xYDiKWL2KjLB+6rQXvqzJ4h6BUcxm1XAX5Uj5tLUUL9wqT6u0G+bI=\r\n"^M "-----END CERTIFICATE-----\r\n"^M --- * A Backup of the Pad content has been put read-only online (with some comments and further analysis to be done) * http://pastebit.com/pasties/store/12001/silentcircle.html * http://pastebin.com/dKRPrGMN * SilentCircle source code has been temporarily removed from Github:https://github.com/SilentCircle/silent-phone-base * Nadim opened a ticket to ask about the code back:https://github.com/SilentCircle/silent-phone-base/issues/1 * A new (different) version of the code has been uploaded online:https://github.com/SilentCircle/silent-phone-base * Someone in the meantime put the original code back online (as a zip archive):http://jednorog.sneakyness.com/1U060B2S3I1P * A diff between the "original SC open source release" and the "modified SC open source release" reveal some code difference * Output of git diff "original/silent-phone-base new/silent-phone-base/ sc. patch" is available at http://codepad.org/eQkexG2R _______________________________________________ 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: So how big was it *really*?
by Jay Ashworth 06 Jul '18

06 Jul '18

----- Original Message ----- > From: "Simon Lockhart" <simon(a)slimey.org> > And there's a (semi-)public response from one of Cloudfare's > upstreams: > > http://cluepon.net/ras/gizmodo Money quote: """ In defense of the claims in other articles, there is a huge difference between "taking down the entire Internet" and "causing impact to notable portions of the Internet". My company, most other large Internet carriers, and even the largest Internet exchange points, all deliver traffic at multi-terabits-per-second rates, so in the grand scheme of things 300 Gbps is certainly not going to destroy the Internet, wipe anybody off the map, or even show up as more than a blip on the charts of global traffic levels. That said, there is absolutely NO network on this planet who maintains 300 Gbps of active/lit but unused capacity to every point in their network. This would be incredibly expensive and wasteful, and most of us are trying to run for-profit commercial networks, so when 300 Gbps of NEW traffic suddenly shows up and all wants to go to ONE location, someone is going to have a bad day. """ Cheers, -- jra -- Jay R. Ashworth Baylink jra(a)baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 ----- 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: [HacDC:Byzantium] Pie-in-the-sky potential...
by Andrew Lewis 06 Jul '18

06 Jul '18

FWIW some people that hang around Telecomix might also be interested in collaboration on stuff outside of just regular Byzantium. I also know that there are some people doing space stuff that we can reach out to, via the DARPA funding for hackerspaces and Space. I think that Byzantium is a very cool subproject that loops into a whole slew of mesh networking projects that can build an ecosystem of communication gear that can be put together in a hurry. I think that the community might be reaching critical mass where we start to integrate all this stuff. As an aside, it blew my mind that for $20k you could build a blue force/situational awareness system for a 20 kilometer radius using mesh networking. Byzantium should really look at integrating serval-maps project, as it can do some really cool stuff with mapping. Andrew On Aug 18, 2012, at 3:00 AM, haxwithaxe <me(a)haxwithaxe.net> wrote: > replies below > > On 08/18/2012 12:51 AM, Crate8 wrote: >> Greetings all, >> >> As a security and defence scholar, with an interest in technology and >> emergency management, I'm glad I've stumbled across this project.(thank >> you Reddit and Ars Technica, I think). I've been searching for an >> adaptable mesh networking application for quite some time and haven't >> found anything robust and cost-effective (read: cheap/free) until now. >> Happy to see something like this being pushed out. > thanks we're glad to be pushing it :P > >> Tossing the idea around in my noodle brought up an idea of loading this >> kind of software onto a constellation of tiny cubesats >> (http://en.wikipedia.org/wiki/CubeSat) in orbit, offering potentially >> global coverage. While I recognize that this is not the specific aim of >> the Byzantium Project, I can't help but think that with ground-based >> high-gain Wi-Fi antennas pointed to the sky, such a system would be >> wonderful. Not to mention access in the event of disaster in seriously >> remote areas. > i like the idea }:P > i was gonna put something here about power required to get to space but > then i read this :P > http://www.engadget.com/2007/06/19/venezuelans-set-new-wifi-distance-record… > > i'm not familiar enough to know whether tracking would be an issue but > that might be something to consider since getting geosyncronous orbit > for cubesats is pricey (compared to polar orbit). > >> I'll give a look-see into the project documentation, etc. I'm >> particularly interested to see how handing off is accomplished when a >> mobile user moves out of the range of one node and into another... > for the different protocols we use they might be different but the one > we use by default is babeld and i think it just waits for it to not > respond to the mesh protocol traffic and then drops it from the routing > table. > >> Any side-threads dedicated to long-term potential of this distro? I'm >> not much of a coder (mostly hobbyist Java stuff :P) but I'm creative and >> determined and would love to lend any hand I can to improving this project. > testing (including light security audits) are very useful at this point, > as are translations and documentation writing/editing. > > haxwithaxe > -- You received this message because you are subscribed to the Google Groups "Project Byzantium (Emergency Mesh Networking)" group. To post to this group, send email to Byzantium(a)hacdc.org. To unsubscribe from this group, send email to Byzantium+unsubscribe(a)hacdc.org. For more options, visit this group at http://groups.google.com/a/hacdc.org/group/Byzantium/?hl=en. ----- 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

Kiwi Cops pay for Invading Privacy
by Dave S. 06 Jul '18

06 Jul '18

* Kiwi Cops Pay To Access Encrypted Phone Calls Police in New Zealand will pay Vodafone NZ$1.1 million to be allowed access to encrypted cell phone calls. According to Stuff.co.nz, the Crimes Act in New Zealand already allows the police to intercept phone calls, but they can't decipher the encrypted calls made on the Vodafone network. Paul Swain, the communications minister, said that the money had been allocated for the deal, which was expected to be completed in a few weeks. Meanwhile, the New Zealand police forces are outraged that they have to foot the bill. The president of the Police Association, Greg O'Connor, complained that in the US and Australia the responsibility lies with the service provider to give the police access to calls. "In New Zealand it doesn't happen. In New Zealand the telecommunications companies are creaming it off police," he said. http://www.theregister.co.uk/content/8/17143.html COMMENT: Why should the telecommunications companies foot the bill? They are not in the business of providing freebies to the State. Government agencies should pay for special services just like anyone else. The New Zealand law is much more fair than corresponding legislation in the US and Australia. ************************************************************************** Subscribe to Freematt's Alerts: Pro-Individual Rights Issues Send a blank message to: freematt(a)coil.com with the words subscribe FA on the subject line. List is private and moderated (7-30 messages per month) Matthew Gaylor, 2175 Bayfield Drive, Columbus, OH 43229 (614) 313-5722 ICQ: 106212065 Archived at http://groups.yahoo.com/group/fa/ **************************************************************************

1 0

[Asrg] A New Plan for No Spam / Velocity Indicator
by Hallam-Baker, Phillip 06 Jul '18

06 Jul '18

All, I finally got the revision of my paper 'A Plan for No Spam' through legal and posted to the VeriSign Web Site. It is in PDF (sorry no HTML or plaintext version). http://www.verisign.com/resources/wp/spam/no_spam.pdf I would draw folks attention to the Velocity Indicator described in the Authentication section. This provides an overview of the trusted hardware scheme I devised a few months back. While this is a proprietary technology which we have applied for patent protection on and intend to enforce those rights the scheme requires trusted hardware as a precondition and so the license costs would fall on the harware vendor, not the software developer so the patent would not be a bar to open source implementations (unless there is a GNU CPU planned). This post does not waive the rights VeriSign has to that technology, etc. I will be publishing a fuller paper on the scheme in the large at a later date. However here is a brief summary: The trusted hardware base can be anything that is manufactured in controlled conditions. It could be a palladium class PC, but it could equally be simply a trusted bios, or a PDA feature, or it need not be a PC at all, it could be a peripheral such as a smartcard or even a cable modem, nat box, anything you like. In the simplest version of the scheme a private key, a certificate and the current time are loaded into the TCB during manufacture. To create a message the client asks the TCB to provide an authenticator token bound to the message in the usual fashion. This carries the 'velocity indicator' as an authenticated attribute. Each time a signature is created the velocity indicator is updated to reflect the current rate of signing (you could also have a count of the total signatures over the lifetime of the message). This could be the signatures in the past hour and the past day (say). When a recipient receives a message the velocity indicator and signature are checked. The probability that a message is spam is low if BOTH the signature binds to the specific delivery of the message to the user (i.e. has a valid to: field) and the velocity indicated is low. There are a couple of possible tweaks to protect anonymity. For example it is not necessary that the signature be bound to a particular key. You could use the key installed during manufacture to request new keys. You can even partition the box so you have separate counts for different signers (this could be appropriate for a bulk emailer box). If someone takes a box apart and extracts a key we revoke it - not such a big issue as you might think, the gaming studies we have done show that that would be a very poor strategy for an attacker. In essence what we have done is to reinvent the 'sender-pays' concept - hence my previous arguments against handing over actual cash. It is not necessary to have the expense of a transfer system with all the excessive mechanism to prevent fraud that would entail. All that is necessary is the scarcity property of money which we simulate in an entirely scalable fashion. Unlike hashcash and the like this scheme is not vulnerable to moore's law or assumptions of computational cost. The one big drawback is that is does depend on replacing the hardware of the Internet. This is not actually as big a deal as it sounds since it need not be the PC, it could be a cable modem or a NAT box or even a dongle. We could even sell/rent a box to an ISP that would be built on trusted hardware that would sign all the emails going through their mail servers with the velocity indicator being recorded on a per IP address basis. Bulk mailers that send out mailing lists etc have to be dealt with differently but they cannot conceal the fact they are generating large numbers of emails. There is also a layer to defend against certain obvious abuses and such but I will describe those separately since they don't depend on the trusted hardware. Here I have to untangle an issue that came up with the Borderware people who have had similar ideas to some we came up with but I could not talk about at the time. Phill _______________________________________________ Asrg mailing list Asrg(a)ietf.org https://www1.ietf.org/mailman/listinfo/asrg --- end forwarded text --- 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