Re: [Cryptography] Crypto Standards v.s. Engineering habits - Was: NIST about to weaken SHA3?
On Thursday, October 10, 2013, Salz, Rich wrote: > > TLS was designed to support multiple ciphersuites. Unfortunately this > opened the door > > to downgrade attacks, and transitioning to protocol versions that > wouldn't do this was nontrivial. > > The ciphersuites included all shared certain misfeatures, leading to the > current situation. > > On the other hand, negotiation let us deploy it in places where > full-strength cryptography is/was regulated. > > Sometimes half a loaf is better than nothing. The last time various SSL/TLS ciphersuites needed to be removed from webserver configurations when I managed a datacenter some years ago led to the following 'failure modes', either from the user's browser now warning or refusing to connect to a server using an insecure cipher suite, or when the only cipher suites used by a server weren't supported by an old browser (or both at once): 1) for sites that had low barriers to switching, loss of traffic/customers to sites that didn't drop the insecure ciphersuites 2) for sites that are harder to leave (your bank, google/facebook level sticky public ones [less common]), large increases in calls to support, with large costs for the business. Non-PCI compliant businesses taking CC payments are generally so insecure that customers that fled to them really are uppung their chances of suffering fraud. In both cases you have a net decrease of security and an increase of fraud and financial loss. So in some cases anything less than a whole loaf, which you can't guarantee for N years of time, isn't 'good enough.' In other words, we are screwed no matter what. -David Mercer -- David Mercer - http://dmercer.tumblr.com IM: AIM: MathHippy Yahoo/MSN: n0tmusic Facebook/Twitter/Google+/Linkedin: radix42 FAX: +1-801-877-4351 - BlackBerry PIN: 332004F7 PGP Public Key: http://davidmercer.nfshost.com/radix42.pubkey.txt Fingerprint: A24F 5816 2B08 5B37 5096 9F52 B182 3349 0F23 225B ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Other Backdoors?
Thursday, October 10, 2013, Phillip Hallam-Baker wrote: > > [Can't link to FIPS180-4 right now as its down] > For the lazy among us, including my future self, a shutdown-proof url to the archive.org copy of the NIST FIPS 180-4 pdf: http://tinyurl.com/FIPS180-4 -David Mercer -- David Mercer - http://dmercer.tumblr.com IM: AIM: MathHippy Yahoo/MSN: n0tmusic Facebook/Twitter/Google+/Linkedin: radix42 FAX: +1-801-877-4351 - BlackBerry PIN: 332004F7 PGP Public Key: http://davidmercer.nfshost.com/radix42.pubkey.txt Fingerprint: A24F 5816 2B08 5B37 5096 9F52 B182 3349 0F23 225B ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Opening Discussion: Speculation on "BULLRUN"
On Sat, Sep 7, 2013 at 2:19 AM, ianG wrote: > On 7/09/13 10:15 AM, Gregory Perry wrote: > > Correct me if I am wrong, but in my humble opinion the original intent >> of the DNSSEC framework was to provide for cryptographic authenticity >> of the Domain Name Service, not for confidentiality (although that >> would have been a bonus). >> > > > If so, then the domain owner can deliver a public key with authenticity > using the DNS. This strikes a deathblow to the CA industry. This threat > is enough for CAs to spend a significant amount of money slowing down its > development [0]. > > How much more obvious does it get [1] ? > > iang > I proposed essentially this idea around 10 years ago on the capabilities list, using custom TXT records and some hackish things that are/were sub-optimal due to DNSSEC being more of a pipedream then than it is now to deliver public keys for any arbitrary purpose. I only went so far as to kick around design ideas on and off-list back then under the tag-line of objectdns (as in being able to locate and connect to any arbitrary object via a public key crypto connection) and registering the domain objectdns.com. Things stalled out there due to my lack of copious free time. David Mercer - http://dmercer.tumblr.com IM: AIM: MathHippy Yahoo/MSN: n0tmusic Facebook/Twitter/Google+/Linkedin: radix42 FAX: +1-801-877-4351 - BlackBerry PIN: 332004F7 ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Opening Discussion: Speculation on "BULLRUN"
On Thursday, September 5, 2013, Jerry Leichter wrote: > [This drifts from the thread topic; feel free to attach a different > subject line to it] > > On Sep 5, 2013, at 4:41 PM, Perry E. Metzger wrote: > > 3) I would not be surprised if random number generator problems in a > > variety of equipment and software were not a very obvious target, > > whether those problems were intentionally added or not. > Random number generators make for a very interesting target. Getting > decent amounts of entropy on conventional machines is very difficult. > Servers have almost no random variation in their environments; desktops > somewhat more; modern laptops, yet more. Virtualization - now extremely > common on the server side - makes things even harder. But even laptops > don't have much. So we're left trying to distill "enough" randomness for > security - a process that's error-prone and difficult to check. > Virtual private servers are a very big problem. Virtual machine deployment systems at very large hosting providers have been found to use the same /dev/urandom initialization for many thousands of machines. It comes from not re-seeding from /dev/random on provisioning, and running with the same seed as was in the VM template when it was 'cut'. I know because I fixed it at places I worked as a contractor. I know at least one competitor had the issue. No knowledge if it was ever fixed there. Don't trust seeds you didn't generate. Think about Amazon AWS instances all spinning up on demand with the exact same init code and prng seed (this example is not the ones i dealt with, butnis perhaps a larger problem). You always have a window after startup where you can predicte the state of the kernel level prng. Not a big one, but it is real and in the wild. -David Mercer -- David Mercer - http://dmercer.tumblr.com IM: AIM: MathHippy Yahoo/MSN: n0tmusic Facebook/Twitter/Google+/Linkedin: radix42 FAX: +1-801-877-4351 - BlackBerry PIN: 332004F7 ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: Interesting bit of a quote
On 7/13/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: Phenomenon 1: Computerized records are malleable, and it's in general impossible to determine if someone has changed them, when they changed them, what the previous value was, and so on. Further, changing computer records scales easily - it costs about as much to change a million records as it does to change one record. Well yes, and no. Relational database systems preform replication by copying and loading trasaction logs, and WORM drives (and WORM tapes) are used by organizations that need to prove that things weren't altered (or to be able to audit when they are). It is of course quite a lot more expensive to do things that way compared to how the typical IT shop does things. -David Mercer - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: browser vendors and CAs agreeing on high-assurance certificates
On 12/23/05, Peter Gutmann <[EMAIL PROTECTED]> wrote: > PKI in browsers has had 10 > years to start working and has failed completely, how many more years are we > going to keep diligently polishing away before we start looking at alternative > approaches? There have been several long threads over on the cap-talk list the last few weeks about what to call (still not fully baked) web capability pointers such as WideWords and httpsy urls. The point in those discussions that I think is most relevant to this thread is the fact that there was only a very minor side discussion about the fact that all of these techniques for granting more fine grained permissions on the Web that are in the R&D stage use SSL/TLS, but not PKI, and would very often toss up a certificate warning if you didn't pay the "cert tax". The point was made that users have been so conditioned to ignore them or click on Ok in general, that that itself was not the biggest barrier to their (potential) future wide deployment, at least not in relation to other UI issues for their use. -David Mercer Tucson, AZ - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: browser vendors and CAs agreeing on high-assurance certificates
On 12/18/05, James A. Donald <[EMAIL PROTECTED]> wrote: > Even if the vendors do implement a policy that all new > urls must be significantly different from known high > value urls, which is not their stated policy, this is > not going to help much with such high value urls as: > "https://lb22.resources.hewitt.com"; > > Proving true names is not much help, because there are > too many names. Holy water indeed! As at least someone on this list doesn't seem to see that there is a 'too many true names' problem, here are some examples from the ssl sites I use (almost) daily. Second level domains changed to protect the guilty (and url's chopped for safety): 1) Bank number one: https://online.first-bank-of-lameness.com This looks ok at first, as the host name is always the same. However, if one goes right to this url by typing it in directly, you are directed back to www.first-bank-of-lameness.com, which is of course the perfect place to hijack things with a MITM attack. Also, the user visible url once logged in is always nice, short, and sweet, with all crypto-like parameters safely hidden from the users eyes in POST form parameters. 2) Bank number two: https://onlineeast3.the-other-lame-web-banking system.com/ This one may or may not have something different from onlineeast3, depending on, well, who can tell from where the user is sitting? But it also does not let one log in directly by typing in the url that is used in the secure part of the session, similarly to the normal merchant practice as poiinted out by [EMAIL PROTECTED] One would hope that the banks would close this hole for phishing, but alas in these cases, no. 3) Web mail number one: http://us.f509.mail.yahoo.com Of course trying to log into https://mail.yahoo.com gives a certificate error dialog box, although a user normally types in http://mail.yahoo.com for a 'normal' login. The ssl version of the same url redirects you to an https url that starts with something completely different. And while normall static for long periods, the f509 part merely indicates the mail store machine your box just coincidentally happens to be on. I have (once) seen that change for my account. When will that happen again, when they most my mailbox, or when I get subjected to a MITM attack? 4) https://mail.google.com also suffers from various "oh you typed in the https version of an otherwise valid hostname" certificate dialog boxes, but at least the hostnames don't change dynamically. Still cold comfort if I'm out in the wilds checking my mail from somewhere weird, as I don't carry the fingerprint of their genuine certs in my wallet or anything. Hm, maybe I should? I think that those examples pretty clearly demonstrate the limited value of any sort of 'true hostnames' in a web ssl context. Sorry for running off at the fingers without checking about this issue and ssh certs earlier, but these ssl examples are directly cut and pasted from live ssl sessions. What a mess, and again, holy water indeed! Ciao, -David Mercer Tucson, AZ - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Crypto and UI issues
On 12/15/05, Ben Laurie <[EMAIL PROTECTED]> wrote: > David Mercer wrote: > Thanks for the apology, but ... ssh is not my fault. Sorry, crosswired openssl and openssh in my brain! > I will agree that something better than just showing you the key would > be cool. Like maybe it could be signed by something so you can verify it > that way. Oh, wait. That's PKI, and we all know PKI is broken. Yeah, 'broken' is about the strongest language we'd want to use on a public list, huh? > > Horrible, horrible UI, and I'm not sure what's worse, that or trying > > to USE pgp (gpg, whatever) from a command line, or getting it > > integrated into a gui mail client. > > Two words: Thunderbird, enigmail. Sorry, I've become totally addicted to gmail and just can't imagine being tied down to a single desktop machine. Not that gmail is the end all be all of webmail or anything, and I'm not completely sure how far I trust them, but they are top dog right now for email in my book. -David Mercer Tucson, AZ - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Crypto and UI issues
(Hopefully this is sent as ascii, as I had previously set my gmail to
send in utf-8 encoding, as I often send email in french as well as
english. -djm)
On 12/11/05, James A. Donald <[EMAIL PROTECTED]> wrote:
> It is not my position that inability to sign means that
> the chairman of the board is stupid. It is that
> cryptographic signatures are too @#$%^&* hard and need
> to be made user friendly.
>
> First write software that is easy enough for your
> mother. Then we can work on making it easy enough for
> the marketing department.
And then we can work on making it easy enough for realtors!
Seriously, that long ago became my off the cuff usability test: they
seem to have a harder time figuring out user interfaces that my 75
year old grandmother, or the marketing folks for that reason. Sales
people are actually fairly easy to train on any given UI, so long as
you instill the proper fear into them ("if you don't do this right,
your competitor will steal your customer list, and there go all your
commisions").
It's harder to get marketing people on board like that, as they don't
have the same direct financial levels to attack with pavlovian fear
conditioning, and CEO's are really bad, as they are used to having
secretaries do everything 'hard' with their communications gear, even
in the pre-computer era, and also are accustomed to a coterie of
handlers and PR people going around and cleaning up any messes they
inadvertently make.
But realtors, that's been my personal acid test to see if a UI is
truly easy to use. Seriously.
And my appologies to Ben Laurie and friends, but why after all these
years is the UI interaction in ssh almost exactly the same when
accepting a key for the first time as overriding using a different one
when it changed on the other end, whether from mitm or just a
key/IP/hostname change?
Horrible, horrible UI, and I'm not sure what's worse, that or trying
to USE pgp (gpg, whatever) from a command line, or getting it
integrated into a gui mail client.
-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
