Re: [Cryptography] PRISM-Proofing and PRISM-Hardening

2013-09-19 Thread Max Kington
On 19 Sep 2013 19:11, Bill Frantz fra...@pwpconsult.com wrote:

 On 9/19/13 at 5:26 AM, rs...@akamai.com (Salz, Rich) wrote:

 I know I would be a lot more comfortable with a way to check the mail
against a piece of paper I

 received directly from my bank.

 I would say this puts you in the sub 1% of the populace.  Most people
want to do things online because it is much easier and gets rid of paper.
 Those are the systems we need to secure.  Perhaps another way to look at
it:  how can we make out-of-band verification simpler?


 Do you have any evidence to support this contention? Remember we're
talking about money, not just social networks.

 I can support mine. ;-)

 If organizations like Consumers Union say that you should take that
number from the bank paperwork you got when you signed up for an account,
or signed up for online banking, or got with your monthly statement, or got
as a special security mailing and enter it into your email client, I
suspect a reasonable percentage of people would do it. It is, after all a
one time operation.

As with other themes though, one size does not fit all. The funny thing
being that banks are actually extremely adept at doing out of band paper
verification. Secure printing is born out of financial transactions,
everything from cheques to cash to PIN notification.

I think it was Phillip who said that other trust models need to be
developed. I'm not as down on the Web of trust as others are but I strongly
believe that there has to be an ordered set of priorities. Usability has to
be right up there as a near-peer with overall system security. Otherwise as
we've seen a real attack in this context is simply to dissuade people to
use it and developers, especially of security oriented systems can do that
of their own accord.

If you want to get your systems users to help with out of band verification
get them 'talking' to each other. Perry said that our social networks are
great for keeping spam out of our mailboxes yet were busy trying to cut out
the technology that's driven all of this.

Out of band for your banking might mean security printing techniques and
securing your email, phoning your friends.


 Cheers - Bill

 ---
 Bill Frantz| If the site is supported by  | Periwinkle
 (408)356-8506  | ads, you are the product.| 16345 Englewood Ave
 www.pwpconsult.com |  | Los Gatos, CA 95032


 ___
 The cryptography mailing list
 cryptography@metzdowd.com
 http://www.metzdowd.com/mailman/listinfo/cryptography
___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography

Re: [Cryptography] End to end

2013-09-18 Thread Max Kington
On 18 Sep 2013 07:44, Christoph Gruber gr...@guru.at wrote:

 On 2013-09-17 Max Kington mking...@webhanger.com wrote:


 [snip]
  Hence, store in the clear, keep safe at rest using today's archival
mechanism and when that starts to get dated move onto the next one
en-masse, for all your media not just emails.
 [snip]

 I would tend to agree for environments with very high regulations, where
the need to comply with regulations is more important than the need to keep
data confidential.
 I would suggest to balance that for every organisation. The risk to
disclosure is much higher if data is stored unprotected. Any admin with
access to the file system is able to read it.
 Maybe this could be a cultural difference between US and Europe, the
regulative pressure in US is higher, in Europe the privacy is more
important or more protected.
 I agree that both ways may be the right implementation for an
organisation, but this has to be a management decision, balancing the needs.

I was referring to the UK :-)

I'm not saying it isn't important to consider how data is made available in
the cases where you have end to end security but a future standard wants to
be permissive of a solution even if it's out of scope for the RFC rather
than prohibitive by including it as mandatory, could/can vs should/must.

That said now there appears to be evidence that side channel attacks that
force lesser security where it's an option are being actively exploited.
Previously we'd have all assumed that the main benefit of those was in
interoperability but now not so much. So there is an argument to use 'must'
more in standards concerning security.

By making archival a separate concern you also reduce the complexity of
many deployments. As you say, for environments with very high regulation,
my personal mailbox, isn't, my work one, is.

Max


 Best regards

 --
 Christoph Gruber
 If privacy is outlawed, only outlaws will have privacy. Phil Zimmermann

___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography

Re: [Cryptography] End to end

2013-09-17 Thread Max Kington
On 17 Sep 2013 15:47, Christoph Gruber gr...@guru.at wrote:

 On 2013-09-16 Phillip Hallam-Baker hal...@gmail.com wrote:
 [snip]

 If people are sending email through the corporate email system then in
many cases the corporation has a need/right to see what they are
sending/receiving.

 [snip]

 Even if an organisation has a need/right to look into people's email, it
is necessary to protect the communication on transport and storage. Of
course a certain way of key recovery has to be in place.

 Just my 2 cents

I intend to reply in more detail to the draft there's lots of very
interesting work there.

The most common approach to ILM for email in highly regulated sectors I've
seen is to divorce the storage and transport mechanism and associated
security from the long term storage. In a corporate environment the message
is captured pre encryption and transmission and stored.

Whilst key escrow mechanisms do exist the risk is that what gets escrowed
isn't what was sent if you maliciously want to tunnel data (imagine not
being able to decrypt a message at the request of the SEC or FSA because
the key you were sent is wrong by the desktop app, or conversely having to
decrypt everything first to check). You have the added issue of having to
store all the associated keys and in 7 years (the typical retention period
over here for business now regarded as complete, let alone long running
contracts still in play) still have software to decrypt it.

Hence, store in the clear, keep safe at rest using today's archival
mechanism and when that starts to get dated move onto the next one
en-masse, for all your media not just emails.

Hence for the purposes of your RFC perhaps view that as a problem that
doesn't require detailed specification.

M


 --
 Website: http://hallambaker.com/

 ___
 The cryptography mailing list
 cryptography@metzdowd.com
 http://www.metzdowd.com/mailman/listinfo/cryptography


 ___
 The cryptography mailing list
 cryptography@metzdowd.com
 http://www.metzdowd.com/mailman/listinfo/cryptography
___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography

Re: [Cryptography] Summary of the discussion so far

2013-09-14 Thread Max Kington

On 13 Sep 2013, at 21:46, Nico Williams wrote:

 On Fri, Sep 13, 2013 at 03:17:35PM -0400, Perry E. Metzger wrote:
 On Thu, 12 Sep 2013 14:53:28 -0500 Nico Williams
 n...@cryptonector.com wrote:
 Traffic analysis can't really be defeated, not in detail.
 
 What's wrong with mix networks?
 
 First: you can probably be observed using them.  Unless too many people
 use mix networks you might just end up attracting unwanted attention:
 more passive surveillance, maybe even active attacks (at the limit very
 physical attacks).

I do wonder what the problem with being observed using it is though.  I
understand the problem and the want to not have traffic analysis done
on your communications but what's the practical effect on your communications
if they are?

If I think about what I'm bothered about.  I do work part-time for an arm of 
government.  I don't like the idea that someone is out there with a big 
ear-trumpet
recording all my communications.  I like to be able to discuss the rights 
wrongs of mass surveillance but at the same time I don't want to be labelled
a dangerous subversive.  I like to have a moan about things I dislike but 
I don't want those to re-appear at some meeting where I'm called in for
a meeting, hat on, without coffee.  At least not where I've not been compelled
to produce them (at least I know what's coming!).  So privacy on the messages 
is important to me but not
necessarily is it of *equal* importance that my communications partners are 
hidden.  I might swap emails
with Ben, Ben likes a good moan too, we both work for the same branch. 
The fact that I work with Ben and talk to him is neither here nor there.

For example, Hemlis is taking on the problem of obscuring traffic with regards
to the 'who' you're talking to and not just the 'what'.  I wonder how important
that is, really, especially when they're talking about centralised control of 
user information to ensure security, but haven't addressed what happens 
when they're compelled to help people game their own system (the it's ok, we'll
go to prison before we help the spooks I always find a bit weak, what if they
turn up with a car battery and a pair of pliers?) It's not clear how they're 
going to do 
any of this yet.  All in all they seem to have good intentions but I fear 
they're falling
into the trap of trying to solve the 'interesting' problems as a priority 
without having
a consistant plan.

I'm sure they'll come up with some sort of mix network.


 
 Second: I suspect that to be most effective the mix network also has to
 be most inconvenient (high latency, for example).  That probably means
 mix networks won't be popular enough to help with the first problem.

As Perry points out in his August posts, latency is less important although
for instant messaging traffic people do kind of want 'instant' for a low enough
value of latency.  The latency though is only of massive importance if it's 
critical
that who you talk to be obscured as well.  If you have *some* idea
of the people in a network who are communicating with each other there
also needs to be enough bandwidth to hide your messages in, as you're 
probably already observing the traffic close (or fairly close) to the endpoint
it's being delivered to.  

I took an approach in the system that I built of batching messages together
inside an encrypted bundle and padding them with junk so that you got a 
message every x minutes or x seconds and it was always at least y 
size regardless of if there was anything in it for you of 
interest or not.  If messages were over y size, they split and queued up for 
the next interval.

 
 Third: the mix network had better cross multiple jurisdictions that are
 not accustomed to cooperating with each other.  This seems very
 difficult to arrange.

Specifically on the jurisdictional point:

I've looked into this, I did some research into cloud providers in different 
jurisdictions.  After all if it's going to scale you're unlikely to be building 
data 
centres on the way to the system becoming successful.  It is possible that
you don't actually need to go to the extremes of routing stuff via Russia, China
Egypt and Pakistan.  I've got another discussion on another list about what
entities that are allowed to co-opoerate can actually do on behalf of each 
other. 
It turns out there is an interesting disconnect between Irish law and the UK law
(I picked Irish law because Amazon's european operations are in Ireland)

You have to decide if you are worried about co-operation as allowed by law 
or not for the jurisdiction you're in, i.e. are you going to go to prison or 
not.

The main instrument of cooperation here is a thing called an MLAT, a mutual
legal assistance treaty and they're signed with an awesome number of countries.

They only enable cooperation to the extent that local law allows and have 
different
rules about support that allows evidence that can be admissible in court and 
other
kinds of support.

So it comes back to 

Re: [Cryptography] prism proof email, namespaces, and anonymity

2013-09-14 Thread Max Kington
On Fri, Sep 13, 2013 at 10:12 PM, Perry E. Metzger pe...@piermont.comwrote:

 On Fri, 13 Sep 2013 16:55:05 -0400 John Kelsey crypto@gmail.com
 wrote:
  Everyone,
 
  The more I think about it, the more important it seems that any
  anonymous email like communications system *not* include people who
  don't want to be part of it, and have lots of defenses to prevent
  its anonymous communications from becoming a nightmare for its
  participants.  If the goal is to make PRISM stop working and make
  the email part of the internet go dark for spies (which definitely
  includes a lot more than just US spies!), then this system has to
  be something that lots of people will want to use.
 
  There should be multiple defenses against spam and phishing and
  other nasty things being sent in this system, with enough
  designed-in flexibility to deal with changes in attacker behavior
  over tome.

 Indeed. As I said in the message I just pointed Nico at:
 http://www.metzdowd.com/pipermail/cryptography/2013-August/016874.html

 Quoting myself:

Spam might be a terrible, terrible problem in such a network since
it could not easily be traced to a sender and thus not easily
blocked, but there's an obvious solution to that. I've been using
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.


The keys. This to me is the critical point for widespread adoption, key
management. How do you do this in a way that doesn't put people off
immediately.

There are two new efforts I'm aware if trying to solve this in a user
friendly way are https://parley.co/#how-it-works and http://mailpile.is.

Parley's approach does at least deal with the longevity of the private key
although it does boil security down to a password, if I can obtain their
packet and the salt I can probably brute force the password.
I've exchanged mails with the mailpile.is guys and I think they're still
looking at the options.

Max
___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography

Re: [Cryptography] Books on modern cryptanalysis

2013-09-11 Thread Max Kington
On 11 Sep 2013 18:37, Bernie Cosell ber...@fantasyfarm.com wrote:

 The recent flood of discussions has touched on many modern attacks on
 cryptosystems.   I'm long out of the crypto world [I last had a crypto
 clearance *before* differential cryptanalysys was public info!].  Attacks
 that leak a bit at a time strike me as amazing.  I remember reading about
 attacks that involved running chips at lower voltage than they were
 supposed to have and that somehow allowed them to be compromised, etc.

 Anyhow, are there any (not *too* technical) books on the modern
 techniques for attacking cryptosystems?

How modern is modern? :-)

I have modern cryptanalysys by Christopher Swenson (or at least did have
before it was loaned and I moved) and it was an excellent book and
crucially was very accessible. Also available in kindle format now. It is 5
years old now though.

Regards
Max


   Thanks.   /bernie\

 --
 Bernie Cosell Fantasy Farm Fibers
 mailto:ber...@fantasyfarm.com Pearisburg, VA
 --  Too many people, too few sheep  --



 ___
 The cryptography mailing list
 cryptography@metzdowd.com
 http://www.metzdowd.com/mailman/listinfo/cryptography
___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography

Re: [Cryptography] In the face of cooperative end-points, PFS doesn't help

2013-09-08 Thread Max Kington
This space is of particular interest to me.  I implemented just one of
these and published the protocol (rather than pimp my blog if anyone wants
to read up on the protocol description feel free to email me and I'll send
you a link).

The system itself was built around a fairly simple PKI which then allowed
people to build end-to-end channels.  You hit the nail on the head though,
control of the keys.  If you can game the PKI you can replace someone's
public key and execute a MITM attack.  The approach I took to this was that
the PKI publishes peoples public keys but then allows other users to verify
your public key.  A MITM attack is possible but as soon as your public key
is rotated this is detected and the client itself asks if you'd like to
verify if out of band (this was for mobile devices so it lends itself to
having other channels to check keys via, like phone your friend and ask
them).  The much more likely thing is where someone tries to do a MITM
attack for just a particular user but as the channels are tunnelled end to
end they need to essentially ask the PKI to publish two duff keys, i.e. one
in each direction, Alice's key as far as Bob is concerned and Bob's key as
far as alice is concerned..  In turn the two people who's traffic the
attacker is trying to obtain can in turn ask someone else to double check
their.  It means that you need to publish an entirely fake PKI directory to
just two users.  The idea was the alarm bells go off when it transpires
that every person you want to get a proxy verification of a public key via
has 'all of a sudden' changed their public key too.  It's a hybrid model, a
PKI to make life easy for the users to bootstrap but which uses a web of
trust to detect when the PKI (or your local directory) has been attacked.
 Relationships become 'public' knowledge at least in so far as you ask
others in your address book to verify peoples public keys (all be it via
uuids, you could still find out if your mate Bill had 'John's' public key
in his address book because he's asked you to verify it for him).  So for
those who want to protect the conversational meta data it's already
orthogonal to that.

Group chat semantics are quite feasible in that all users are peers but you
run into difficulty when it comes to signing your own messages, not that
you can't sign them but that's computationally expensive and the eats
battery life.  Again, you are right though, what do you want to achieve?

I certainly built a protocol that answered the main questions I was asking!

As for multiple devices, the trick was always usability.  How do you
securely move an identity token of some description from one node to
another.  I settled on every device having its own key pair but you still
need an 'owning' identity and a way to 'enrol' a new key pair because if
that got broken the attacked just enrols their own 'device'
surreptitiously.  You then get into the realms of passwords through salted
hashing algorithms but then you're back to the security of a password being
brute forced.  If you were really paranoid I proposed a smart card
mechanism but I've yet to implement that (how closed a world are smart
cards with decent protection specifications?! but that's another
conversation), the idea being that you decrypt your device key pair using
the smart card and ditch the smart card if needs be, through a typical
office shredder.

Silent Circle was one of the most analogous systems but I'm an amateur
compared to those chaps.  As interesting as it was building, it kept
boiling down to one thing: Assuming I'd done a good job all I had done was
shift the target from the protocol to the device.

If I really wanted to get the data I'd attack the onscreen software
keyboard and leave everything else alone.

Max


On Sun, Sep 8, 2013 at 7:50 PM, Jerry Leichter leich...@lrw.com wrote:

 On Sep 7, 2013, at 11:16 PM, Marcus D. Leech wrote:
  Jeff Schiller pointed out a little while ago that the crypto-engineering
 community have largely failed to make end-to-end encryption easy to use.
  There are reasons for that, some technical, some political, but it is
 absolutely true that end-to-end encryption, for those cases where end to
 end is the obvious and natural model, has not significantly materialized
 on the Internet.  Relatively speaking, a handful of crypto-nerds use
 end-to-end schemes for e-mail and chat clients, and so on, but the vast
 majority of the Internet user-space?  Not so much.
 I agree, but the situation is complicated.  Consider chat.  If it's
 one-to-one, end-to-end encryption is pretty simple and could be made simple
 to use; but people also want to chat rooms, which are a much more
 complicated key management problem - unless you let the server do the
 encryption.  Do you enable it only for one-to-one conversations?  Provide
 different interfaces for one-to-one and chat room discussions?

 Even for one-to-one discussions, these days, people want transparent
 movement across their hardware.