Re: [cryptography] MalwareBytes
In article <576d6d35.3080...@gmail.com> you write: >Do you want to take chances in a world of stolen certificates? Why is this certificate more likely to be stolen today than it was a week ago? It's the same certificate, it hasn't changed. R's, John >On 6/24/2016 11:09 AM, Jason Richards wrote: I just downloaded the new MBAM installer. Its certificate expired 6/19/2016. Should I just ignore that fact? >>> I wouldn't ignore it at all. >> The certificate that signed the code expired? If the certificate was >> valid when the code was signed then there should be no issues. Nothing >> has changed. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] USG moves to vacate hearing tomorrow due to possible method to unlock iPhone
>>(But who is the outside party? A lone wolf? The NSA? Other?) >Would Apple be the outside party? As in its offshore stashing of >foreign revenue as foreign entity? No, Apple is Apple. My guess is that one of the many people who've been saying you can image and reload the phone's memory card finally got the attention of someone in the litigation juggernaut. Note that this is consistent with the Brooklyn decision in which the judge said the FBI had told him in other cases that they could unlock a 5C. It's hard to tell whether it also means that they were worried that the wind was blowing the wrong way and they'd rather have no decision than an unfavorable one. R's, John ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] a new blockchain POW proposal
>1) Can we use SAT (or another NPC problem) as a POW? Meybe. Remember that a POW has to be hard to compute but easy to verify and each instance should be roughly the same difficulty. My impression is that some SAT problems are a lot harder than others, and you can't tell in advance which is which. >3) Would there be any problems in allowing people to solve a problem > defined in advance, rather than having it vary based on the current > block? Yes. The amount of computing power that people have thrown at bitcoin mining has increased by orders of magnitude since bitcoins were invented, and varying the problems keeps the mining rate roughly constant. If you had problems of fixed difficulty, either they'd be too hard and mining would creak to a halt, or they'd be too easy and the price would crash from the flood of new bitcoin blocks, at least until they hit the fixed total block limit. >4) Would it be useful to decouple any of the aspects of the block chain > from each other? Could one decouple the financial impacts from the > cryptographic operations from the persistent, distributed storage? There are certainly blockchains whose entries are things other than sort-of-money, and there's plenty of electronic money that doesn't use blockchains. So this question doesn't make a lot of sense. >6) Could we create markets around the various services required to > implement the block chain in a way that creates incentives that > align with the overall goals? Depends what you think the goals are. The current process meltdown is an argument between people who want to make what they see as a simple and overdue change to increase the number of transactions, and people who for various reasons ranging from algorithmic purity to protecting the transaction fees their racks of mining hardware is collecting. R's, John ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Varoufakis claims had approval to plan parallel banking system for Greece
In article you write: >Varoufakis claims had approval to plan parallel banking system for Greece > >http://www.ekathimerini.com/199945/article/ekathimerini/news/varoufakis-claims-had-approval-to-plan-parallel-banking-system > >Allegedly aided by Columbia University IT professor to design a hack >of existing taxation systems. > >Columbia Computer Science Faculty > >http://www.cs.columbia.edu/people/faculty Pretty easy to tell who it is, there's three Greeks on the faculty but only one does crypto. Given the financial mess in Greece, it's perfectly reasonable to make contingency plans for running the financial system if they get booted out of the Euro and have to switch back to the drachma on short notice. The crypto hackery does seem a bit odd, but nothing in Greece seems to work the way one might expect. R's, John ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Ancient history: GeoTrust Launches GeoRoot
In article you write: >http://www.prnewswire.com/news-releases/geotrust-launches-georoot-allows-organizations-with-their-own-certificate-authority-ca-to-chain-to-geotrusts-ubiquitous-public-root-54048807.html Ten seconds of Googlage reveals that this press release is from February 2005, over a decade ago. http://www.thewhir.com/web-hosting-news/geotrust-launches-georoot-ssl-tool I would have thought that a bunch of crack crypto nerds would be a wee bit more sceptical about being punked. R's, John ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Unbreakable crypto?
>Would a commonly available large binary file make a good one-time pad? >Something like ubuntu-14.10-desktop-amd64.iso12 maybe.. Unlkely for two reasons. One is that the point of a one-time pad is that only the sender and recipient are supposed to have a copy. The other is that something like a Linux distribution has extremely obvious regularities, so it wouldn't be hard for a cryptographer to figure out what it was. The way you make a one time pad is to take a source of actual (not pseudo) randomness and record a lot of it in a form that is relatively easy to distribute securely, like a DVD-ROM. R's, John ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] [Cryptography] IBM looking at adopting bitcoin technology for major currencies
In article <0f84f471-a996-41ed-af73-30c53b658...@me.com> you write: >Did you hear about how the Fed would not allow Germany to visit to audit their >gold, eventually, German personnel were allowed to stand in the door way of >only >one of their vaults, but not enter and randomly inspect their bars. ... Yes. Great story, other than the minor detail that it is mostly false. Here's a story from Der Speigel, an actual news magazine, that is a lot more credible than the nonsense you find on gold bug blogs. http://www.spiegel.de/international/germany/german-politicians-demand-to-see-gold-in-us-federal-reserve-a-864068.html Also see this story in which German gold bug Peter Boehringer has an impressive array of conspiracy theories about missing German gold, except that it's all there. http://www.bloomberg.com/news/features/2015-02-05/germany-s-gold-repatriation-activist-peter-boehringer-gets-results R's, John ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] [Cryptography] traffic analysis
>> Yeah, but ... who can realistically afford that bandwidth? To every >possible recipient? Clearly you have to make a tradeoff. There's at least one usenet group that has nothing but encrypted messages. >It's a crying shame no one can figure out how to re-purpose all the >existing spam traffic as cover traffic. Sigh. There have been many rumors over the years of signal hidden in the spam noise, but none that anyone's been able to track down. A lot of spam contain random chunks of text as hashbusters, which would be a dandy place to hide the signal. By the way, don't miss this story about a message hidden in Morse code in a pop song broadcast to prisoners in the jungle in Colombia. It includes a link to the song, they're not making it up: http://www.theverge.com/2015/1/7/7483235/the-code-colombian-army-morsecode-hostages R's, John ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] [Cryptography] FCC commissioner Pai statement on Netflix encryption
In article <1421436949.4138.11.camel@terabyte> you write: >https://www.fcc.gov/document/commissioner-pai-stmt-netflixs-conduct-re-open-video-standards > >I am not really sure what it is that he is claiming here, but he seems >to be taking issue with the use of encryption to prevent DPI. It looks to me like he's under the misimpression that Netflix uses simple file downloads which could be cached by typical "transparent" web caches. In fact they use some Flash thing that adapts to available bandwidth, so as far as I can tell, there is nothing to usefully cache. There's also the issue of how a third party cache could tell which users had paid to see copies of the cached stuff. Part of the long running argument between Netflix and large ISPs involves whether Netflix can put their own servers inside the ISPs, along the lines of what Akamai does. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Gogo inflight Internet uses fake SSL certs to MITM their users
>It is what they are doing. I am an unhappy (for many reasons) regular (for many >other reasons) Gogo customer, and noticed pretty quickly when they started >doing >it. I looked at their certs and it's an awful-user-experience way of blocking >videos, and I strongly suspect that the rotten user experience is the intent. Do the fake certs validate in web browsers? If so, who's giving them fake *.google.com certs? R's, John ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
[cryptography] Gogo inflight Internet uses fake SSL certs to MITM their users
http://venturebeat.com/2015/01/05/gogo-in-flight-internet-says-it-issues-fake-ssl-certificates-to-throttle-video-streaming/ They claim they're doing it to throttle video streaming, not to be evil. Am I missing something, or is this stupid? If they want to throttle user bandwidth (not unreasonable on a plane), they can just do it. The longer a connection is open, the less bandwidth it gets. R's, John ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] [Cryptography] Why aren’t we using SSH for everything?
>>> gpg signed attestations, e.g. see up front of my site, https://psg.com >> >> Not sure if that helps at all - the CA is an invalid certificate and would >> be expired even if the validity dates were correct. That doesn't indicate >> proper cert handling... >> > >And if it was SSH, how would we ever truly verify that public key. I'm not Randy, and I rarely look at SSH keys, but I do note that the bogus CA doesn't matter, since the file you download contains a PGP signature you can verify. Well, you can if you believe that the key with ID EA37E360 belongs to Randy. Perhaps I'll ask him when I see him in Dallas. R's, John ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] stab from the past, was John Gilmore: Cryptography list is censoring my emails
>The point is block lists suck, they're always blocking false things, >and vigilante abusive takes 3x longer to take you off than for you to >complain or unresponsive etc. The most amazing thing just happened. Last night I went to bed in 2014, and today, based on the messages I'm reading, it is 1996 rather than 2015. You know when someone shows up and says he has a new super unbreakable crypto scheme, and he'll pay $100 to anyone who can break it (but you can only see it after you sign a one-sided NDA), or the web would be totally secure if every web server used https because then you'd know exactly who ran every web site? Well, that's how this discussion sounds to anyone who is familiar with the way modern mail systems work. You can't run a non-toy mail system without DNSBLs.* The mail stream is 90% or more spam, and well run DNSBLs will tag or knock out about 80% of that 90% with a very low error rate. The DNSBLs that people actually use, notably Spamhaus and Spamcop, have turned from hobbies into businesses, and the good ones work very hard to minimize the error rate. It is certainly true that any moron can run an DNSBL, and many morons do, but nobody uses the moronic BLs so it doesn't matter. SORBS, the list that Gilmore is complaining about, is an odd case. It's one of the oldest BLs and used to be widely used, but now its management can best be described as peculiar. I know the gal (formerly guy) who runs it who is fairly peculiar, too. These days it seems mostly to be used by small systems who added it to their configuration a long time ago and haven't noticed the false positives yet. My mail server is listed on it, due to a single message sent three months ago that I am fairly sure was not spam (I have logs.) But if people want to use it, that's their problem. Gilmore's listing is probably not a false positive, since he famously insists on running an open mail relay that leaks spam. Even in 1996, the problem that open relays addressed (partial network connectivity) had largely gone away, so I do not pretend to understand what point he purports to be making. R's, John * - don't argue unless you've talked to the postmasters at Gmail, Yahoo, AOL, Hotmail, Comcast, Roadrunner, Charter, Verizon, and AT&T. I have. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] FW: Request - PKI/CA History Lesson - the definition of trust
>You're right yes ( I did forget :), but if a DNS can somehow guarantee a >correct "hostname->IPAddress" mapping, then it can also guarantee a correct >"hostname->public key" ( or self signed certificate) mapping. WebServers >would present a self-signed certificate with the public key to HTTPS(TLS) >clients, and the client side PKIX chain validation would need to be modified >to validate the public key matches that which is in the DNS. You're not the first person to think of this idea, and might want to read RFCs 6698 and 6394. R's, John ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Request - PKI/CA History Lesson - the definition of trust
In article you write: >On 2014-05-03, at 3:22 AM, wrote: > >> Frankly, if we could "trust" in DNS, we would not need to "trust" in >> web-PKIX [2] - since the one is just the bandaid for the other. > >Have you forgotten that routing can be subverted? > >Just because you are talking to the right IP address doesn�t mean >you are talking the right host. Sure, but if the cert it presents has the hash in the DNSSEC signed DANE record, it does. R's, John ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] [Cryptography] making money secure, was The Best 419 Message I've Seen
> when you give someone your ABA routing number and account >number. An account number for incoming funds only (drop box?) would >solve a number of these problems. Actually there are inbound-only ACH account numbers, but only businesses use them. ACH transfers are reversible, so they're not very useful for fraud unless you can ensure that the victim won't notice before you have time for the transfer to complete and for you to clean out the account. >Unfortunately, the brain dead payment geniuses in (for instance) the >United States manage to design a payment system that permits third >parties to order drafts (e-checks) against arbitrary account numbers >in order to (for instance) enable e-payments to be pulled from >checking accounts at the prompting of the payee. Same thing, they're reversible. One security model is to make sure that nothing bad ever happens, the other is to admit that bad things will happen and make provision for reversing them. In the US at least, bank security is mostly the latter and only a little bit the former. Bank wires are not usually reversible, which is why there's no such thing as a pull bank wire, and why crooks like to break into business web accounts and send wires to their overseas selves. My bank does fairly credible 2FA for wires. I have to punch the last digits of the recipient account number into my physical security token and enter the code it provides, which I'd think would make it pretty hard to do most of the MITM tricks. http://obvious.services.net/2013/07/better-have-big-pockets-if-you-want.html R's, John ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] [Cryptography] Swap space (Re: It's all K&R's fault)
>That is, the purpose of vfork() was to let you implement spawn(). (Prior >to Linux, no O/S even considered the "overcommit_memory" approach >because, let's face it, it's idiotic.) Sort of. The vfork() call was added to 3BSD around 1980, while COW memory management was written for Mach in the late 1980s and wasn't merged into 4BSD until the mid 1990s. Like much of what Bill Joy added to Unix, vfork() was a hack. He noted that fork()/blah/exec() was a common idiom with a fairly small amount of blah, so he added vfork to handle that special case. It's still more general than spawn since the blah can be anything, not just whatever options spawn provides. Like every hack, it was quickly misused, often by the child process making changes to memory that the parent could see after the child's exec(). I wrote a history of COW a while ago: http://obvious.services.net/2011/01/history-of-copy-on-write-memory.html I would worry more about shared libraries with writable data pages that don't get copied when you fork. That's supposed to be a feature, to handle shared buffers for dbm style libraries, but wow, what a way to leak data. R's, John ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] [Cryptography] Swap space (Re: It's all K&R's fault)
In article you write: >Nemo writes: > >>Well, Windows does not use fork()+exec(); it uses spawn() and its variants. >>Hence it avoids the whole vfork() / "memory overcommit" mess. > >Aren't many fork()s now pretty close to vfork(), via COW? Yes. Every modern Unix-ish system I know of does COW both for forks and for writable data segments. Also keep in mind that even if you have no swap space for writable memory, any read-only code can be discarded and then reloaded from the file it was originally loaded from, which permits RAM to be significantly overcommited and still not run out of space. For crypto, I think this means that whatever model you have for where your data are is likely wrong, so I wouldn't spend a lot of time obsessing about it. I sort of see the point of encrypted swap, although I don't really understand the threat model where the attacker can defeat file protections and look at the /dev/swap but not at /dev/mem. R's, John ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] [Cryptography] GCC bug 30475 (was Re: bounded pointers in C)
>> In my opinion, the GNU Project and the developers of GCC would be well >> advised to get legal advice on their responsibilities and liabilities >> in this matter. > >Err, no, sadly: > >http://www.openssl.org/source/license.html > > * THIS SOFTWARE IS PROVIDED BY THE OpenSSL PROJECT ``AS IS'' AND ANY > > * EXPRESSED OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE > > * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR > > * PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE OpenSSL PROJECT OR > > * ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, > > * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT > > * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; > > * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) > > * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, > > * STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) > > * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED > > * OF THE POSSIBILITY OF SUCH DAMAGE. > > >Leave the lawyering to the wretched slime who passed the bar. It is far from settled to what extent you can disclaim liability in a purported license. There isn't much case law at all for open source software, where there's generally no exchange of consideration so it is highly debatable whether a contract exists, and none I'm aware of on liability, only on copyright. As Arnold said, find a lawyer who understands this stuff, if such a lawyer exists. R's, John ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] question about heartbleed on Linux
> Well, the operating system clears memory when it is allocated to a new > process, >but that doesn't matter. The residue containing memory sits around until it's >needed. And quite possibly during that time before it is re-allocated it is >subject to disclosure via heartbleed. Heartbleed is a bug in an application library. It can leak data from the process in which the application is running, e.g. an SSL web server, but not from the rest of the computer. That's plenty bad, of course. R's, John ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] question about heartbleed on Linux
In article <20140410172648.gj8...@platypus.pepperfish.net> you write: >On Thu, Apr 10, 2014 at 10:09:10AM -0700, Scott G. Kelly wrote: >> Does heartbleed allow one to read (discarded, freed) physical memory >> containing data from the OS and/or other processes in linux? > >Yes. It doesn't clear memory when it is freed, so you may end up >allocating memory that has old content in it, perhaps even from swap. I don't ever remember any Unix-ish or Linux system where the kernel didn't clear newly allocated process memory, other than perhaps some ancient tiny machines with no memory protection, and I've been in this biz since the 1970s. That would be a horrible security hole that malware would be exploiting directly, not by accident via something like heartbleed. I agree that these days the implementation is typically that new memory is page faulted in from the equivalent of /dev/zero. R's, John ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] [Cryptography] glitter security, was nuclear arming codes
>Very cool, but it requires a photo of what the nail polish is supposed to look >like. A secure photo. > >Don't trust your regular cell phone with this, sounds like a job for the >off-line "phone" you carry. You do carry one, right? Whatever happened to prints on photo paper? ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Can we move to a forum, please?
>Stick with the mailing list. If we are going to move anywhere, it >should be toward something like a moderated Usenet newsgroup (if not >actually moving to Usenet). Agreed. By the way, I gateway this list to a local newsgroup on my usenet server and read it there. Moving to usenet wouldn't be hard, give or take the hardness of people spinning up usenet clients. >> Also, do you enjoy not being able to edit your comments? Yes. It encourages me to think before sending. R's, John ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] [Cryptography] HSBC's Password Approach: Impressive
>> They are being pretty clever to make up for terribly endpoint security. > >Yeah, all that might work for non brick and mortar stuff you maybe care about, >say email [1], and your fave pornsite. But really... you need to be able to >demand a hardware OTP token from your bank and brokerage... They do that, too. I have accounts at six of HSBC's banks, of which five have some sort of token protection. You can see four of them here: http://obvious.services.net/2013/07/better-have-big-pockets-if-you-want.html For the fifth one, they gave me a choice of another token or an app running on my Android tablet so I took the app. They have a federated authentication setup so when you're logged into a bank in one country, you can switch to banks in most other countries where you have an account without logging in again. Most require the token when you switch, one gives you read only access if you don't have the token. The one bank that doesn't offer a token is the one in the U.S., by the way. R's, John ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
[cryptography] Whatare remaining U.S. export controls on crypto?
I'm updating a very old legal article that mentions crypto. As I understand it, nearly all of the controls were lifted in 2010 other than some exports to North Korea and such. Is there a comprensible summary of the current rules anywhere? Tia. R's, John ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] [Cryptography] PGP Key Signing parties
> I am going to be interested to hear what the rest of the list says > about this, because this definitely contradicts what has been > presented to me as 'standard practice' for PGP use -- verifying > identity using government issued ID, and completely ignoring personal > knowledge. That seems needlessly pedantic. If your government ID is a passport or (at least in the states where I've lived) a driver's license, a permissible form of ID is for someone else with another ID to say that he or she personally knows you. Back when I first applied, if the passport official knew you, that was all the ID you needed. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] [Cryptography] the introduction problem, was prism proof email, namespaces, and anonymity
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 > Jabber, Facebook and other services where all or essentially all > communications require a bi-directional decision to enable messages > for years now, and there is virtually no spam in such systems > because of it. So, require such bi-directional "friending" within > our postulated new messaging network -- authentication is handled > by the public keys of course. This is an old approach, trying to reduce the spam problem to the introduction problem. It works, sort of, but it's not as simple as it looks. I know people who do security at Facebook, and the lack of spam is due more to the fact that it's a closed system with people whose job it is to keep spammers from annoying the customers than to the introduction aspect. For Jabber, I expect it's that other than gmail (which has its own security department) there aren't any Jabber networks large enough to be worth spamming. There's plenty of spam in AOL's instant messaging system, where you can send anyone one message asking to be introduced. Introductions have terrible scaling properties. If you want a messaging system that can do what email does, it needs to be able to handle mail sent by robots. For example, when you buy a plane ticket online, you probably want to let the airline send you a confirmation, and also updates if the flights change. How do you authorize that, short of allowing anyone to send you a request that you look at? And more importantly, how do you tell the flight updates from valuable offers sent by the same company? Or, remarkably often, an organization's contact list will leak (it's hard to tell whether by malicious employees, incompetence, or malware) and now you have to abandon the existing token and set up a replacement. This isn't a useless technique, and it's very useful for some situations like small children whose parents manage their list of correspondents, but I don't think you'll find it a very useful way to keep out unwanted messages in general, unless you're also willing to lose a lot of wanted ones. R's, John -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.21 (FreeBSD) iEYEARECAAYFAlI0pZAACgkQkEiFRdeC/kWevQCgnBETJDi4Vo1+hZ3xz1EsePS4 JxYAn2jqKCR+89BxzDFiRfC3Jlo220Ut =0TEa -END PGP SIGNATURE- ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] [Cryptography] IPv6 and IPSEC
>But with IPv6 privacy extensions, a single machine might be using >pseudorandomly-generated addresses in a /64 subnet, I believe this problem falls into the category where the solution is "don't do that." You can do whatever you want with your internal hosts, but your mail relay needs to hold still so receivers can develop a reputation for it. If you want people to accept your mail, send it from a fixed IP address with forward and backward matching DNS. You need to figure out enough about SPF to publish a record that blesses your outgoing servers. If that's too hard, it's time to outsource your mail to someone who can deal with it. R's, John PS: Google accepts my IPv6 mail just fine. Even the mailing lists. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] not a Paypal phish using EV certificate
In article you write: >I recently got a another of the standard phishing emails for Paypal, directing >me to https://email-edg.paypal.com, which redirects to >https://view.paypal-communication.com, which has a PayPal EV certificate from >Verisign. According to this post >http://www.onelogin.com/a-paypal-phishing-attack/ it may or may not be a >phishing attack (no-one's really sure), and this post >http://www.linuxevolution.net/?p=12 says it is a phishing attack and the site >will be shut down by Paypal... back in May 2011. > >Can anyone explain this? Sure. It's Paypal. If you look at the WHOIS and DNS for paypal-communication.com, they're the same as paypal.com, with DNS at ISC. The web page is hosted at Akamai, who know who their customers are (so they can send them large invoices.) If you read the linuxevolution.net post, the guy got the message, and sent a query to Paypal support. The person who answered it at 3 AM Bangalore time sent the canned "thanks for reporting a phish" message that they send to EVERY SINGLE COMPLAINT, even ones for mail with paypal.com addresses coming from paypal.com servers. In sort of defense, most of the complaints really are about phishes, but I'd think they would be able to do automation to look for their own domains and IP addresses and give the staff a hint that this might be a real one. I agree that it was not a great idea for Paypal to invent paypal-communication.com rather than a subdomain of one of their existing well-known domains such as communication.paypal.com. R's, John ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] skype backdoor confirmation
>[3] E.g., as John reported, a clear case of non-intelligence low-bar >availability for a routine prosecution of some random journeyman level >scumbags. John, if you're still suffering our questions, was your case >civil or criminal? Criminal, US vs. Christopher Rad. http://www.justice.gov/usao/nj/Press/files/Rad,%20Christopher%20Verdict%20PR.html ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] skype backdoor confirmation
>> I was a technical expert in a pump and dump spam trial last fall, >> and a large part of the evidence was Skype chat logs among the members >> of the spamming group. >Who provided the chat logs? Were they provided by Skype or where they >provided by one or the other members? The reason I ask is that if there >is any sensitivity in sources, the prosecutors will routinely obscure >the sources. I got them from the prosecutors. They appeared to have been provided by Skype. R's, John ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] skype backdoor confirmation
>Maybe we will see subpoenas or public hearings for Microsoft and their >Skype. For what? Skype has kept chat logs for years, and the government routinely subpoenas them. I was a technical expert in a pump and dump spam trial last fall, and a large part of the evidence was Skype chat logs among the members of the spamming group. Also keep in mind that Microsoft bought Skype from eBay, so there is nothing new about it being owned by a U.S. company. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] metadiscussion of topics, was Bonding or Insuring of CAs?
>Well, are there more people here who want a more strict crypto only list ... I'd like a list where people ensured that the subject lines of their messages described what the message was about, so I can easily skip the ones that aren't of interest. Then I don't much care whether the discussion wanders afield of what I want to read. R's, John ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Gmail and SSL
>I don't have hundreds of dollars to get my ssl certificates signed, ... I don't have a strong opinion either way about Gmail's new signing requirement, but if the issue is money, Startcom's free certs seem to satisfy Gmail. Once you set up an account, it takes about five minutes to get a cert issued. I got one for my mail server this morning. https://www.startssl.com/ ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] DKIM: Who cares?
>Note the weasel-words "long-lived." I think that the people caught out >in this were risking things -- but let's also note that the length of >exposure is the TTL of the DNS entries. Seems to me that if it's possible to reverse engineer the signing key in three days, you'd need to change the key more often than that. I've asked around, and found that it's rare for people to rotate their DKIM keys more often than quarterly. So even if a key takes two months to crack, there could still be a fairly wide window to use the cracked key before it's rotated. I rotate every month, but appear to be the only mail system in the world that rotates that often. This kind of key problem isn't specific to DKIM, of course. DKIM key rotation is very easy, and you can use at least a 1536 bit key before you run into DNS packet size issues, so it's not hard to do right. R's, John ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] DKIM: Who cares?
>I think it's more likely that DKIM is affecting spammers so little (if at all) >that they never really cared about it, and the organisations deploying it know >that and don't bother doing anything more than going through the motions using >the shortest (= lowest-overhead) keys. Hmmn. Is there some point to speculating about the behavior of mail systems about which you know nothing? I'm typing this from a conference attended by all of the large ISPs in North America and many from Europe and Asia. I can assure you that they do check DKIM and they do use it to do the things that it can do. Random spam from random addresses is little affected by DKIM; it's hard to imagine why anyone who was familar with it would think otherwise. It's quite useful to recognize mail from known senders, which makes it easier to recognize and deal with some kinds of phishing. As more people use it, it's very useful to bypass filtering for known good signers and decrease the filtering load R's, John ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] DKIM: Who cares?
> Does anyone know why they all do this? Hi. I'm was a member of the working group that developed DKIM. The problem is set and forget software. DKIM is a descendant of Yahoo's DomainKeys, which was developed in about 2005. DKIM is sufficiently upward compatible with DK that most DK key records work as DKIM key records. So someone set up scripts to do 512 bit DK keys back in 2006, the scripts still work, and they forgot that they were using antique keys. Oops. I suspect that few people had done the math to figure out how easy it is to crack a 512 bit key on modern hardware, I know I hadn't. The assertion that longer keys don't fit in UDP DNS packets is just wrong. The keys are stored in base64 ASCII, and my 1024 bit key records are 240 characters long. R's, John ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Bitcoin-mining Botnets observed in the wild? (was: Re: Bitcoin in endgame
> Personally I lost a bundle on major currency devaluation GBP, EUR, > USD look at them against the CHF to see how much you'all lost due to > whatever human / political inefficiencies you attribute currency > devaluation on that scale to. A stable mechanism for value storage > would be a rather useful instrument. This is why there are forward currency markets and inflation indexed bonds. It's not a problem that crypto will solve, and certainly not a problem that virtual pet rocks (aka Bitcoin) are relevant to. R's, John ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] (off-topic) Bitcoin is a repeated lesson in cryptography applications - was "endgame"
>Then you'll find out about Santayana's curse - those that don't study >history are doomed to repeat it. For reference, start with read John >MacKay, _Extraordinary Popular Delusions and the Madness of Crowds_. MacKay turns out not to be all that accurate. The definitive work on financial bubbles is Kindleberger's "Manias, Panics, and Crashes: A History of Financial Crises." Get the 2005 5th edition, which was edited by Robert Solow after Kindleberger died. It's quite readable, and should help put Bitcoin in context. -- Regards, John Levine, jo...@iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. http://jl.ly ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Bitcoin in endgame
> I would also argue the Wall Street Bankers would have been happy > to legitmize BitCoin if they got a cut (confer: derivatives). Hmmn. You know how painful it is when finance types pontificate about cryptography that they don't understand? Well, ... Let me just say that it is not a bug in the US financial system that there are provisions for unwinding bank transactions, nor that there is a central bank with the authority and ability to increase and decrease the money supply. We spent several centuries doing it the other way before Bagehot wrote Lombard Street. The crypto model of Bitcoin is extremely clever, but the financial model would have been state of the art in about 1500 AD. The collapse due to external attacks, both the botnet mining, and the various well-publicised thefts of bitcoins and the failures of various bitcoin markets was utterly predictable. As I said a while ago, they're not money, they're pet rocks. R's, John ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] trustwave admits issuing corporate mitm certs
>> They also claim in their defense that other CAs are doing this. >Evading computer security systems and tampering with communications is >a violation of federal law in the US. As the article made quite clear, this particular cert was used to monitor traffic on the customer's own network, which is 100% legal absent some contractual agreement with the customers not to do that. (In which case it still be a tort, not a crime.) It's not like the Ticketmaster case, where the guy was outside Ticketmaster's network, effectively breaking in to trick them into selling him tickets that they didn't want to sell him. I'm not arguing that MITM certificates are a good idea, but they're not illegal until someone uses them to do something illegal, and I don't see that here. R's, John ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] CAPTCHA as a Security System?
Ticket sellers and scalpers have been been fighting since long before there was an Internet. >To do much better than slow down the scalpers Ticketmaster would have >to either do a lot of work (with payments system providers' help) to >ensure that payments are not anonymous and that the there is one >person per ticket purchase for any one event They already do that -- the only way to pay on their web site is with a credit card, and you can't use the same card for a lot of purchases in a row. I'm pretty sure you can't use another card with the same mailing address, either. > or else they'd have to auction off the tickets so as to find the > market price for them. For a variety of business reasons they usually don't want to do that, and they don't want brokers to do it for them. Sports teams want it to be at least somewhat possible for fans to get tickets. That's why they let people wait in long lines, since that's correlated with fanly devotion rather than wealth, and sends the message to the rest of the fans that if they were equally devoted, they too could get tickets. Ticketmaster wants to make it as easy as possible for individuals to buy tickets, while making it as hard as possible for scalpers pretending to be individuals, or individuals working for scalpers, to buy them. CAPTCHAs keep out the less determined scalpers, but there is no reliable mechanical way to tell a nice human from a nasty one. Scalping can be very profitable, with markups of $100 per ticket not unsusual, so if I were a scalper, I'd have a network of web proxies, to make it hard to tell that they're all me, a farm of human CAPTCHA breakers in Asia who cost maybe 5c per CAPTCHA, a large set of employees, friends, and relatives who will let me use their names and credit cards (for a small commission) and scripts that blast through Ticketmaster's web pages as fast as they can, so they can buy the tickets the moment they go on sale, before real humans can. At some point, since there aren't that many large scalping operations, rather than playing an endless game of jumping through hoops and crypto cat and mouse which will certainly have the side-effect of losing some legit purchases, it is perfectly sensible to go after them legally. One of the advantages of having a working legal system is so that we can live reasonable lives with $20 locks in our doors, rather than all having to spend thousands to armor all the doors and windows, like they do in some other parts of the world. R's, John ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] CAPTCHA as a Security System?
>The reason I ask is Wiseguy Tickets Inc and their gaming of >Ticketmaster's CAPTCHA system to buy tickets [1]. Eventually, Wiseguy >Tickets was indicted, and the indictment included a an assertion, >"[Wiseguy Tickets Inc] defeated online ticket vendors' security >mechanisms" [2]. I'm not convinced CAPTCHA is a security system, and I >definitely don't consider it a system to protect multi-million dollar >assets. Law is not software. Ticketmaster's CAPTCHA is a security system in the sense that it is obviously meant to keep out robo-purchasers. It doesn't matter that CAPTCHAs are not impossible to defeat, it matters that any reasonable person can understand what's going on. To draw a rough analogy, if I'm arrested for breaking into your house, it is not a defense that I couldn't have done it if you had a stronger lock on the door. R's, John ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Password non-similarity?
>> I finally realized, that's so when the organization gets pwn3d, you >> won't have used the stolen passwords anywhere else. Or maybe they >> imagine that if your password is stolen somewhere else, you won't have >> changed all the passwords at the same time. > >Really? So you're proposing *cross*site* non-reuse? How does that work? >If you make me change passwords, and many sites do that, what incentive >is there to do anything other than use the same password [or a trivial >mod] for each? I didn't say this was a particularly good rationale, just that the idea is that your password won't be exactly the same as the one they used other places, because their password rules are so stringent. >> There's also the backup tape that fell off a truck issue, ... >but I don't understand again: if that happens, then presumably the IT >folk *know* and _then_ you can make everyone change their passwords [at >least for a reason]. How would they know if the tape fell off the truck? When it gets to the offsite vault, do you really think they carefully count the number of tapes in each incoming box and compare it to some manifest? And if they don't match, is the count or the manifest more likely to be wrong? Again, I don't think this is a particularly compelling argument, but backup media do get lost from time to time, and people often don't notice until they look for it and can't find it. R's, John ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Password non-similarity?
> Well, on more than a few occasions, I've observed cases >where users have accidentally entered their password into the >"username" field (either alone, or with the username preprended). >Of course, the login attempt fails and, more to the point, the >invalid "user name" is logged. The users almost immediately >realize their mistakes, and then login correctly. Unfortunately, >most users don't realize that their password has just been logged >as an invalid user name and their logged subsequent successful login >makes it rather trivial to associate that password with the actual >username of the user. Where's this log? Wherever it is, it's on a system that also has their actual password. If I wanted to reverse engineer passwords, this doesn't strike me as a particularly efficient way to do so. R's, John ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Password non-similarity?
>The standard rationale is that for any given time interval, there's a >non-zero probability that a given password has been compromised. At >some point, the probability is high enough that it's a real risk. Sure, but where does that probability come from? (Various tactless anatomical guesses elided here.) If the probability is low enough the replacement interval could be greater than the lifetime of the system. I see they relate it to the guess rate, so I'd rather limit that then push costs on users and force them to rotate passwords. R's, John PS: Masking passwords as they're typed made a lot of sense on an ASR-33. Is this another throwback? ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Password non-similarity?
>This is the very question I was asking: *WHY* "changed regularly? What >threat/vulnerability is addressed by regularly changing your password? I finally realized, that's so when the organization gets pwn3d, you won't have used the stolen passwords anywhere else. Or maybe they imagine that if your password is stolen somewhere else, you won't have changed all the passwords at the same time. There's also the backup tape that fell off a truck issue, but it's a pretty lame organization who decides to push that risk onto the million users rather than the three IT guys who should be managing the database and backup passwords and related security. (We assume, for the purposes of argument, that there are still backup tapes in use somewhere.) The incentives of the people setting the rules are often not aligned with the interests of the users. R's, John ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Password non-similarity?
>Passwords aren't dead, and despite what IBM says I don't think they're >going away any time soon. But we need new rules and new guidelines >for managing them; the ones from the 1980s don't work anymore. Yeah. At this point the issues seem to be, in no particular order: 1. Trivially guessable passwords 2. Password reuse 3. Keyloggers and other password stealing software The various risks depend a lot on the environment, e.g., what's trivially guessable depends on how often you're allowed to guess. R's, John ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Password non-similarity?
>> You can't force people to invent and memorize an endless stream of >> unrelated strong passwords. > >I'm not sure I agree with this phrasing. It is easy to memorize a strong >password -- it just has to be long enough. Don't forget "endless stream of unrelated". I have some strong passwords for the accounts that matter, but I don't have to start over every month. >So what problem _is_ being addressed by requiring passwords to be changed >so often [and so inconveniently]? Compliance with standards written by people who created the standard by copying standards they saw other places. I suspect a lot of them still trace back to attacks on /etc/passwd on PDP-11 Unix. Regards, John Levine, jo...@iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. http://jl.ly ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Password non-similarity?
>>Has anyone ever implemented a system to enforce non-similarity business rules? Sure. Every month, the first time a user logs in generate a new random password, show it to him, and tell him to write it down. You can't force people to invent and memorize an endless stream of unrelated strong passwords. We just can't do it. Yes, password reuse can be a problem, but I cannot tell you of how tired I am of self-important web sites that demand super strong passwords to protect stuff of only minor value. My least favorite one contains nothing but some conference papers they want me to review. My second least favorite only lets me look at statements for my credit card merchant account, with the card numbers redacted. The more often you make people change passwords, the less effort they are willing to put into each password, so you can be absolutely sure that if you demand a new password every month, they will use dog+digit or whatever is the easiest way to get a password that will let them log in and get their fripping job done. R's, John ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Hi guys, looking for a talanted crypto for an early stage funded bitcoin-related startup.
>I'm looking for a talanted crypto for an early stage funded bitcoin-related >startup, I have to ask: funded with what? R's, John ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] reply-to theology, was Non-governmental
>The list is configured to set Reply-To. This is bad, .. It's a theological issue. Some people like it, some people hate it, no amount of arguing has ever made anyone change his mind about it. In superior list software such as majordomo2, it's a configurable per-user option. R's, John ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Tell Grandma to remember the Key ID and forget the phone number. [was: Re: Let's go back to the beginning on this]
>Now what you're suggesting could work if you did something like made >some directories that stored the key IDs and web sites they belonged to. I'm having trouble understanding how this is usefully different than a CA. Current scenario: you do something to persuade a CA to sign your cert. Then browsers say you're OK, which is a problem if the CA is sloppy. New improved scenario: you do something to persuade a directory to list your key ID. Then some manual or automatic process makes your web site appear OK, which is a problem if the directory managers are sloppy. What am I missing here? This all boils down to the introduction problem, how do you persuade one party that a second party who they don't know yet is OK. It's always the weak link in any security model which has a perimiter with nice people inside and unknown or nasty people outside. R's, John ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Bitcoin, was Nirvana
> You mention a commodity backed system but the reasons for it failing > are not the fact that it's commodity based. It was that, being a metal-based currency there was no central bank (other than, perhaps, JP Morgan) to provide liquidity in a crunch. I've found that it's a waste of time to try to teach economics to Bitcoin true believers, so I'll stop now. R's, John ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Bitcoin, was Nirvana
>The gold standard was fine as far as I know, as long as the gold flow >was steady. Um, no. This isn't the place for a historic treatise, but the 18th and 19th centuries were one boom and bust after another, with lots of inflation and deflation, and not just because of new gold mines. The reason the US created the Federal Reserve in 1913 is that unlike its European trading partners, we had a metal based currency and no central bank, which meant that the dollar was so unstable that trading partners refused to use it, and all foreign had to be denomated in pounds, francs, and occasionally marks. The Fed was created in response to demand from the business and banking community to make the dollar more stable. > If you have any reason people should not use an unchanging coin > without central authority or requirement for trust, I'd REALLY like > to hear it. I can't force you to learn economic history if you don't want to. R's, John PS: Be sure not to confuse the stuff from the Ron Paul crowd with actual history. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Bitcoin, was Nirvana
>> Yet Bitcoin, nonetheless, works. > >How's BitCoin doing? As well as ever. If you want an economy based on pet rocks, which is what bitcoins are, it works fine. If you want an economy where people do the kinds of transactions they do with real money, not so great. Bitcoin's problems aren't the crypto, which as far as I can tell is quite sound. Bitcoin has all the economic problems an 18th c. gold standard has, except that it's a lot easier to steal bitcoins than to steal gold bars. R's, John ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Nirvana
> Also, what if we had real cryptographic money, with anonymity? In > other words: the payments system cannot be the trusted third party > for everything. Then malware would steal the crypto wallets. See Bitcoin. The fact that most financial systems can unwind bogus transactions is a feature, not a bug. R's, John ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Nirvana
>> And further, you should have a client app on your computer for dealing with >> shared secrets, which is only capable of attempting a visa payment with an >> entity trusted by Visa. I don't see how to do that in a useful way without non-programmable hardware. We've seen PC-based malware do pretty much any MITM attack you can imagine. R's, John PS: I was impressed by the malware that redrew images in which the bank had put a text representation of the transaction to be approved. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] [OT]: SQL injection blamed for widespread DNS hack
>While PKI has many shortcomings, DigiNotar has shown the industry can
>effectively kill off a deficient CA. Are there any measures in place
>to keep a deficient registrar out of DNS? Or will NetNames still be
>serving up records with a promise to do better?
Interesting question. For registars for names managed by ICANN
(generic TLDs such as .com), there is a registrar accreditation
agreement which sets out minimum performance standards. But I just
read it and they seem to have forgotten to requires that the registrar
shall use adequate security to maintain registrant data. In any
event, ICANN is notoriously bad at enforcing any part of the registrar
agreement other than the part about getting paid.
For .UK domains, the Nominet registrar contract requires ("you" is the
registrar):
You promise us that in respect of every Transaction request you make:
2.7.1. you have the authority of the Registrant to make that request
and (if applicable) enough authority from the registrant to fully
commit them to all the terms of the contract or obligations
connected with that request; ...
2.8. If you break any of the promises in clause 2.7 and we or our
staff (including contractors or agents) or directors later suffer
loss caused in whole or in part upon our reliance on those promises,
you will pay us back for those losses, including any damage to our
reputation, and the reasonable costs of any investigation,
litigation or settlement. If you are only partly responsible, you
would only have to pay your fair share.
So they're in breach of contract if they allow bogus transactions, but
I have no idea whether Nominet has ever tried to enforce that.
So the short answer to your question is "maybe". At least security
failures at registrars only screw up the info for their own customers,
as opposed to CA failures which can screw up the info for anyone.
R's,
John
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] PKI "fixes" that don't fix PKI (part III)
>Wasn't there a paper on the underground economy that investigated such >things by monitoring drop zones? And they found CC numbers, I thought? I >could be wrong. I can't remember the title, but Thorsten Holz was one of >the authors (no, not a relative of mine). "Learning More About the Underground Economy: A Case-Study of Keyloggers and Dropzones," by Thorsten Holz, et al., Dec 2008. I read that and asked around. There is indeed some PC malware that collects card numbers along with other stuff, but it still seems to be far from a priority. In that paper, which is now three years old, their underground market table lists 10,775 bank accounts, 78,359 Full identities, 149,000 email passwords, and only 5682 credit cards. I asked around, eastern European gangs have vast numbers of stolen card numbers in inventory, one estimate was 1/4 of all North American cards. Plain card numbers are useless, you need at least expiration date, preferably also cardholder's name and adddress and the CVV code, which would be easier to collect from a compromised web browser where it can look at the fieldnames, but even better from a payment processor hat has all that in spades. So, anyway, really, there's no reason to believe that TLS on individual web sessions has any effect on stolen credit cards or other credentials. It's way easier to steal them other ways than to try to reconstruct them from packet streams. Re dealing with phishing, I don't see any plausible solutions that don't involve non-programmable hardware, e.g., a dongle with a little screen that sets up its own secure session back to the bank and displays a summary of the transaction with a verification code you type in. R's, John ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] PKI "fixes" that don't fix PKI (part III)
>Do you have any data to support your assertion that malware isn't >stealing credit card numbers from individual PCs? I talk to malware researchers a lot, and don't ever remember it coming up. Let me check and report back. R's, John ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] PKI "fixes" that don't fix PKI (part III)
>You're missing my point. Let's take the definition of "threat" from the >National Academies study "Trust in Cyberspace": an adversary that is >motivated and capable of exploiting a vulnerability. There are three >keywords, "motivated", "capable", and "vulnerability". No argument there, except that I see no evidence that they're motivated to steal card numbers in transit, or one at a time anywhere, and no reason to think that anything will change that in the forseeable future. Google for "malware credit card sniffer" and you'll find stories about stuff that steals numbers in bulk from cash registers and payment processors, not individually from user PCs. >Thought experiment: suppose that SSL or other generally-effective >encryption did not exist. What is the likelihood that today's generic >malware would contain a credit-card sniffing module as well as keystroke >loggers, account/password stealers, etc? But Steve, generic malware runs on your PC or in your browser. If they wanted to steal card numbers, they'd steal card numbers today, from the browser or by key logging, before the numbers got TLS-ed. Since they don't do it now, I don't see any reason to think they'd do it if it were easier to steal them other places. Once again, I agree that as a matter of general hygiene it makes sense to encrypt traffic, but arguing that it's to protect credit card numbers is looking for your keys under the lamppost. R's, John ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] PKI "fixes" that don't fix PKI (part III)
>This makes no sense whatsoever. Credit card numbers are *universally* >encrypted; of course there's no interception of them. There's a fair amount of low-level ecommerce by e-mail. They don't seem to be intercepted there, either. >In 1993, there was interception of passwords on the Internet. This strikes me as another example of "make your password totally obscure and change it every week", advice that was specific to a long ago environment that's been passed along as received wisdom. In the early 1990s there was still a fair amount of coax Ethernet, and twisted pair was usually connected to hubs rather than switches, so it was easy for a bad guy on your network or intermediate networks to snoop on the traffic. These days, the only shared media are hotel and coffee shop wifi. While we've certainly seen evidence that bad guys snoop on open wifi, it's not my impression that they're particularly looking for credit cards, more often passwords to accounts they can steal. The price of stolen credit cards in the underground economy is very low, so there's no point. The chokepoint to using stolen cards isn't getting the card numbers, it's to find cashers or money mules. So while I agree that it's a good idea in general to encrypt your traffic, I don't see any evidence that card numbers are at particular risk. R's, John ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Thawte
>Thawte is part of Verisign, that is a spin-off from RSA Security. They were an independent company in South Africa with operations in the US and other places. Verisign bought them in 2000. I never heard of them having any connection to RSA, which has always been in the US. I presume that Verisign sold them to Symantec along with the rest of the SSL business. R's, John ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Bitcoin observation
>> My impression is that it's not a problem, since I don't think there >> are any significant governments so ignorant of macroeconomics to >> confuse Bitcoins, which are commodities, with money. >I seem to recall a problem with derivatives in the past, and we still >have them. Sorry, I have no idea what this complete nonsequitur is supposed to mean. We've had a problem with E.Coli in bean sprouts, and we still have those, too. > I believe if wall street could figure out a way to make money on > BitCoins, they would be legitimized and macroeconomics would be set > aside again. Bitcoins are way too small a market to be interesting to Wall St. Really, they're pet rocks, worth a few dollars to anyone who thinks they're cute. Once you understand that, all of the "surprising" characteristics become obvious. R's, John ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Bitcoin observation
>It is my intuition that nation states of all stripes aren't going to >like them. Some set of them would be happy to let the banks and >speculators take care of it. Some of them would engage in actual >hacking to hurt the currency, and the interesting property that >destroying a bitcoin is a worthwhile attack makes it even more >interesting. My impression is that it's not a problem, since I don't think there are any significant governments so ignorant of macroeconomics to confuse Bitcoins, which are commodities, with money. Recall that Liberty Dollars only got into trouble because they claimed they were dollars. Nobody cares about the price of a novelty commodity. R's, John ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Bitcoin observation
> Did you know that if a Bitcoin is destroyed, then the value of all > the other Bitcoins goes up slightly? That's incredible. It's amazing > and leads to some emergent properties Let's imagine that there was an artist who we'll call Aldi. He made a lot of signed prints, which are worth whatever they're worth, with their value set by specialist businesses that will exchange his prints for some amount of normal money. (If I may introduce a little technical jargon, these businesses are called "art dealers.") Let's also imagine that Aldi signed 100,000 blank pieces of art paper, which are sitting in warehouses and could be turned into signed prints by printing a copy of one of his works on them. The total supply of Aldi prints is fixed (he's dead now), but the price of the prints is held down by the knowledge that there's a whole lot of hoarded potential prints whose owners could flood the market. Now let's imagine that someone takes a match and burns up one of those pieces of signed paper. What happens to the value of the rest of them? Wow, the value of all of the other Aldi prints goes up slightly. That's incredible, not. Like any other commodity they're subject to hoarding, cornering the market, and all of the other abuses that regulators like the CFTC exist to prevent, for the commodities that anyone cares about. The most amazing thing to me about bitcoins is that so many otherwise sensible people are willing to believe that they are money, when they so obviously are nothing like money. They're pet rocks. R's, John ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Is Bitcoin legal?
Bitcoins aren't securities, because they don't act like securities. There's no promise to pay, no nominal value, and you don't have a claim on some part of something else. Earlier I said that bitcoins are digital tulip bulbs, but now that I think about it, they're really digital pet rocks. They have no inherent utility or value, only novelty value. Like pet rocks, they're worth what some other collector is willing to pay for them. Just because someone is willing to swap you a beer in exchange for two pet rocks doesn't make them money. I suppose there could be tax implications if people swap stuff for bitcoins, but that's no different than any other barter transaction. R's, John ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Digital cash in the news...
>> Now I find I can exchange a little over five bitcoins for >> a �50 Amazon gift certificate that Amazon seems happy to >> credit to my account. >Your example is about two actors: Amazon and BitCoin, acting within small >amounts of goods, services and issued currency. No, it's not. There's someone who will trade you Amazon gift certificates for bitcoins. He prices the bitcoins at the market rate, planning to make his profit from the Amazon affiliate commission, and presumably whatever price increase he gets so long as the bitcoin bubble continues to inflate. Amazon neither buys nor sells bitcoins. I still am not aware of anything you can actually buy for bitcoins (as opposed to trading them for various kinds of real and fake money) other than drugs. R's, John ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Nothing to do with digital cash in the news...
> ... I don't think it's fair to blame private financial institutions >for the ill-effects of an ill-advised government plan to subsidize >housing ownership by individuals. Without Frannie, CRA, or anything >of the sort I don't think we'd have seen the degree of >financialization of housing that we saw, meaning that we wouldn't >have seen the home mortgage credit growth that drove the housing >bubble, thus neither the bubble nor the crash. Sigh. This is both unrelated to crypto, and just plain factually wrong (although it is considered gospel in some political circles.) Until very late in the bubble, Fanny and Freddy bought only conventional prime fixed rate loans, so it was roaring along without their help, and the CRA has been around since 1977, so if it had caused a bubble, it would have been during the Reagan administration. The housing bubble was due to the complete abdication of responsibility by the bank regulators and the rating agencies, allowing amoral banks to make mortgages with no realistic chance of repayment, and then to repackage that garbage into allegedly AAA derivatives, and to issue ever more highly leveraged Nth degree derivatives of derivatives. See, for example, Brad Delong in 2008: http://delong.typepad.com/sdj/2008/09/the-cra-and-the.html I suppose the lesson here for cybercurrencies is a reminder that the track record of unregulated financial markets is consistently terrible. Look at the economic history of the pre-federal reserve US if you don't believe me. Perhaps this would be a good time to bring this thread to an end, so we can talk about something cryptographic for a change. Regards, John Levine, jo...@iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. http://jl.ly ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Digital cash in the news...
>We can therefore see that someone has to make that "worth" mean >something, so for this we need an "issuer" sometimes known as Ivan. >It's beyond the scope of a crypto list to discuss this in depth, but >typically Ivan would deposit $1 for every issued electronic dollar in >some bank account somewhere. You're right, for a crypto currency to be credible in the long term, it needs to be convertible into Real Money(tm), i.e., something you can use to pay your taxes. (That's the actual working definition of money, by the way.) But that really has nothing to do with the crypto part. You can have crypto out the wazoo, and it's worth nothing unless there's an issuer in meatspace who will accept your crypto coins, cancel them, and hand you the agreed amount of money. Or think about the ETF model I suggested a few years ago, which provides a close approximation to convertibility without requiring that the issuer be able to redeem every individual coin on demand. Regards, John Levine, jo...@iecc.com, First Unitarian Society of Ithaca NY Between 200 and 500 members, depending on who's counting PS: For anyone who wants a crypto currency backed by gold, that's functionally equivalent to a gold ETF, of which there are several, such as ticker symbols IAU, GLD, GTU, SGOL, and AGOL. They do what they do perfectly adequately, but they are in no sense currency. Bubble sceptics can trade put options on them. Too bad there's no options on bitcoins. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Digital cash in the news...
>Unlike fiat currencies, algorithms assert limit of total volume. >And the mint and transaction infrastructure is decentral, so there's >no single point of control. These both are very useful properties. Useful for something, but not useful for money. I can't help but note that the level of economic knowledge in the digital cash community is pitifully low, and much of what people think they know is absurd. (Anyone who thinks that a gold standard is better than what we have now, or that the supply of gold is fixed in any but a purely hypothetical sense, is either ignorant of economic history or shilling for gold speculators.) Anyone who's interested in this stuff should study the economic history of the US, because we've tried everything, from gold to bimetalism, to bimetalism plus private paper to bimetalism plus public paper to a central bank with a formal gold standard, a central bank with an implicit gold standard, and the current central bank with no formal backing. The greatest impetus for the creation of the Federal Reserve in 1913 was that US business interests found themselves at a disadvantage in international trade because, due to no central bank, our currency was so flaky that nobody in other countries would write contracts in it, demanding pounds or francs instead. ObCrypto: it would be interesting to figure out how to create a digital currency that has the characteristics of real money. One possibility is to set up a sufficiently credible central bank that can manage the supply, but I doubt that would work unless that central bank was a national central bank, which would make the digital money fully convertible with real money. Another interesting model is ETFs, exchange traded mutual funds. They are tradable in arbitrarily small quantities, but only convertible to and from the underlying assets in large chunks by parties who have to register with the issuer. The trades are close to anonymous, fully so if you use an offshore bank, the conversions are not. The idea is that the conversions are done by arbitrageurs who track the prices of the asset and the ETF and buy or sell when they are sufficiently out of line. This works pretty well, and other than in chaotic markets it is quite rare for the values to get more than a fraction of a percent apart. The underlying asset can be anything with an easily determinable price such as a single currency or a basket of currencies. Regards, John Levine, jo...@iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. http://jl.ly PS: If you think that the fixed supply of bitcoins is a good idea, look at closed end mutual funds, which issue a fixed number of shares that can never increase. They are as much a payment system as bitcoins are, since there are parties known as "stockbrokers" who stand ready to convert them into a form usable for third party payments at any time, at a price you won't know until you try it. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Digital cash in the news...
>Finally an analogy I can use to explain bitcoin to the masses (well, assuming >they know about the tulip mania). I've been using Bartercard, which is a good >analogy but somewhat limited in international recognition. Read the full rant: http://jl.ly/Money/bitcoin.html R's, John ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Digital cash in the news...
In article <021ccba9-9203-4896-8412-481b94595...@cs.columbia.edu> you write: >http://gcn.com/articles/2011/06/09/bitcoins-digital-currency-silk-road-charles-schumer-joe-manchin.aspx?s=gcndaily_100611 I wouldn't call bitcoins digital cash. They're more like digital tulip bulbs, or bearer shares of theglobe.com. Whatever they are, it's a self limiting problem since the bubble will burst soon enough. R's, John ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] patents and stuff (Re: NSA's position in the dominance stakes)
>If these guys could tell shit from beans, why does the one click patent >stand despite prior art? > >Presumably an "expert" testified ... I would point out that no one-click case has gone to trial, so no expert has testified about anything, but why bother? Facts clearly don't matter here. R's, John ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] patents and stuff (Re: NSA's position in the dominance stakes)
>Patent lawyers are quite smart and knowledgeable. But there is no such >thing as a patent judge or a patent jury and never has been. The CAFC sure looks like patent judges to me. I agree that their decisions do not always please me, but they are bound by laws and precedents that they did not set. By the way, what does all this semi-informed ranting about patents have to do with cryptography? R's, John ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] NSA's position in the dominance stakes
>In order to understand the plaintiff's patent or the defendant's >code, you have to know programming, and a bit of public key >cryptography. Few judges know programming, none know cryptography, >and any juror who knew programming would be thrown off the jury for >being dangerously smart. I am increasingly getting the impression that you've never been involved in actual patent litigation. The process is messy, but the assumption that judges, particularly Federal judges, are stupid and are unable to understand and interpret expert testimony is, shall we say, counterfactual. Perhaps this would be a good time to declare this particular horse beating party to be concluded. R's, John ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] NSA's position in the dominance stakes
>> Go to >> http://docs.justia.com/cases/federal/district-courts/texas/txedce/2:2007cv00216/103383/112/ >> and read the document. It says that the case is being dismissed >> because the parties have settled. It says nothing about why either >> party chose to settle. Having been involved in a fair number of patent suits, I can tell you it's much more venal. Certicom: You're infringing our patents. Sony: They're junk. Certicom: Prove it. See you in court. Sony, to their lawyers: How much will this cost? Lawyers: This case is pretty simple, about $100K/yr for three years. Sony: Yow! Sony, to Certicom: If we pay you $100K, will you go away? Certicom: Deal! I don't know whether Certicom's intention was to do patent trolling, but this is what trolls do, sue with weak patents in the knowledge that it's cheaper for defendants to settle than to fight. R's, John ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] A real case of malicious steganography in the wild?
>It will be interesting to see how this develops in court. We'll never know. They pled guilty, and yesterday were swapped for four of our spies on the tarmac at the Vienna airport, in classic cold war style. R's, John ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
