Re: [Cryptography] Other Backdoors?

2013-10-10 Thread David Mercer
 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] Crypto Standards v.s. Engineering habits - Was: NIST about to weaken SHA3?

2013-10-10 Thread David Mercer
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] Opening Discussion: Speculation on BULLRUN

2013-09-07 Thread David Mercer
On Sat, Sep 7, 2013 at 2:19 AM, ianG i...@iang.org 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

2013-09-05 Thread David Mercer
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

2006-07-14 Thread David Mercer

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

2005-12-23 Thread David Mercer
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 RD 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

2005-12-18 Thread David Mercer
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

2005-12-16 Thread David Mercer
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

2005-12-13 Thread David Mercer
(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.
/ui rant

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]