Re: [cryptography] code signing a nuisance?

[Chris Palmer]

Please look into how code signing on Android works and what it means. It's
not what you think — there are no CAs. By making their signing key public,
if that's what they do, Cyanogen out their users at huge risk: any third
party app can take any System or SystemOrSignature permission, or
impersonate the system directly.
On Sep 20, 2011 11:52 PM, "M.R."  wrote:
> On 20/09/11 21:48, Peter Gutmann wrote:
>> ...to sign their code.
>> ...I get the impression they see
>> security as a nuisance to be bypassed rather than a real requirement.
>>
> I'd like to assure you that code signing and the associated need
> to buy a certificate service from a third party is viewed as a
> "nuisance to be bypassed" by a great majority of independent
> software vendors.
>
> Nobody is happy to see ~his~ product, which he ~knows~ presents
> no threat to his customer, encumbered in both the construction and
> the distribution to such a level in order to protect the buying
> public from ~someone else's bad product~. It's "business 101" really.
> And like always, the smaller the product, the more of a nuisance
> this becomes. And like always, "the regulator" just wouldn't
> admit that the regulation is an ill-conceived measure, which
> encumbers the producer and does not really solve the problem that
> was used as an excuse to introduce it in the first place, mostly
> for the hidden "fringe benefits" that it brings to the regulator.
>
> Mark R.
> ___
> cryptography mailing list
> cryptography@randombit.net
> http://lists.randombit.net/mailman/listinfo/cryptography
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] code signing a nuisance?

[M.R.]

On 20/09/11 21:48, Peter Gutmann wrote:

...to sign their code.
...I get the impression they see
security as a nuisance to be bypassed rather than a real requirement.


I'd like to assure you that code signing and the associated need
to buy a certificate service from a third party is viewed as a
"nuisance to be bypassed" by a great majority of independent
software vendors.

Nobody is happy to see ~his~ product, which he ~knows~ presents
no threat to his customer, encumbered in both the construction and
the distribution to such a level in order to protect the buying
public from ~someone else's bad product~. It's "business 101" really.
And like always, the smaller the product, the more of a nuisance
this becomes. And like always, "the regulator" just wouldn't
admit that the regulation is an ill-conceived measure, which
encumbers the producer and does not really solve the problem that
was used as an excuse to introduce it in the first place, mostly
for the hidden "fringe benefits" that it brings to the regulator.

Mark R.
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] SSL is not "broken by design"

[Eitan Adler]

> It has been a very long time since I had virus or trojan on my home
> computers.  The only time my website was hacked, someone had socially
> engineered my email password out of microsoft.
>
> So it is not apparent to me that the node is the problem.

http://www.rickwash.com/papers/rwash-homesec-soups10-final.pdf

Different people perceive security differently and react to threats
differently. Often times educating people doesn't change any action of
the individual. In order words: Security is increased by designing for
the way humans actually behave instead of getting people to behave in
a different way.

>  My wife knows
> nothing about computers.
> ...

Anecdotes are not evidence. There are have been many studies which
show that user education of this form rarely works.




> ___
> cryptography mailing list
> cryptography@randombit.net
> http://lists.randombit.net/mailman/listinfo/cryptography
>



-- 
Eitan Adler
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] DigiNotar SSL Hack Diagram | Cyber Chatter

[lodewijk andré de la porte]

Mobile phones are mostly toys, and as such don't require solid security.
Until you use them to check you bank account that is. I doubt they'd ignore
that. The signing processes is likely only to have it be swallowed by
whatever 'secure execution' mechanism might be in place. I could be wrong
and they just figured the risks were negligible. They usually are, terms of
service usually include extensive non-liability.

Lewis

2011/9/20 Peter Gutmann 

> Marsh Ray  writes:
>
> >Those are the Cyanogen guys. Android modders.
>
> The same people who used a "publicly available private key" to sign their
> code.  Which, being publicly available to anyone, was promptly used by
> malware
> authors to sign *their* code.
>
> Reading through some of the Cyanogen threads, I get the impression they see
> security as a nuisance to be bypassed rather than a real requirement.
>
> Peter.
> ___
> cryptography mailing list
> cryptography@randombit.net
> http://lists.randombit.net/mailman/listinfo/cryptography
>
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] SSL is not "broken by design"

[ianG]

On 21/09/11 03:32 AM, Jeffrey Walton wrote:

On Tue, Sep 20, 2011 at 1:09 PM, ianG  wrote:

On 18/09/11 20:02 PM, M.R. wrote:

On 18/09/11 08:59, James A. Donald wrote:


If we acknowledge that SSL is not secure, then need
something that is secure.

Nothing is either "secure", or "not secure". Any engineering
system is either secure for the purpose it was designed for,
or it is not. SSL is secure, since it is secure for the
purpose it was designed and implemented for.

That's bad engineering.  Any system that is designed for protecting humans
has to base itself on risks.  Either it has a reasonable chance of
addressing the risks at a good level, or it addresses the risks at a less
than good level.

It is only cryptographers that insist that security is binary -- perfect or
not there at all. Too my knowledge, no other engineering discipline falls to
this hubris [0].  They achieve this remarkable feat by drawing the boundary
of security so narrow as to be typically irrelevant to most purposes.

This can be seen in the original design of SSL.  It was designed to protect
the wire, because it was theorised that the wire was where the threat was.
  Eavesdropping, MITMs and the like.  Not the node.

But, if you read carefully between the lines, there was no evidence of that
statement.  In fact, it turns out, the reason that the threat was taken to
be the wire and not the node was that (a) there was a military cryptography
model that supported wire threats as important, and (b) there was an exotic
and sexy cryptography design that could defeat it.

In other words, they did it because they could [1].

In practice it was the reverse:  in commercial threats, the node is the
problem.  It's always been far greater of a problem than the wire [1].  This
is why SSL is often considered to be a fashion accessory, not a serious
indicator of security; it didn't solve the real problem, but it itself
wasn't much of an issue until attackers started embarrassing it by invading
its design space with attacks.

It seems to me that both the network and the endpoints are at risk. By
what degree the endpoint exceeds the network is an open question for
me since (in my observations) most folks and organizations don't boast
like ComodoHacker. Sadly, I suspect its 'epidemic vs pandemic' and not
'rare/isolated vs occasional'.


Right, so the question is a judgement call.  But it can be an informed 
one.  You can come up with "low risk" and "high risk" ... design for 
high risk, and accept low risk.


The point in general was that SSL v2 especially treated a very low 
theoretical risk as a high risk, and this had the consequence of raising 
its cost dramatically.  In the event, from almost costless to almost 
undeployable.  Thus it reduced its cost-effectiveness, eventually 
reducing its impact to the point where it reduced security overall.


In contrast, SSH was informed by its evidence of risks, so it got them 
right - at a good cost that all were happy to afford.

Network attacks are not an isolated incident (recall Tunisia and
Facebook?), not to mention chronic problems with Cisco gear in the
network, and the cheap cable/dsl broadband routers and home networking
equipment that rarely gets updated.


Sure.  But what was the security requirement again?  Credit cards over 
the net.  Between people who hadn't met.


This is sooo far away from Tunisia and Facebook that really, it 
doesn't count. And, local routing didn't really emerge as a threat to 
credit cards.  Even though we were all watching and waiting, watching 
and waiting.


So, in short, the predicted threat never really materialised, because 
the cost of SSL caused an easier attack to open up - bypass/downgrade to 
HTTP.  Since the original analysis, SSL has migrated outside its 
business space and into new areas.  Maybe the original threat model is 
holding us up?  Maybe we need a new business model which will tell us 
what threats to worry about, instead of repeating the doctrine that MITM 
must be protected even if it is killing us?


Clearly, something has to give.  What is it?

iang
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] DigiNotar SSL Hack Diagram | Cyber Chatter

[Peter Gutmann]

Marsh Ray  writes:

>Those are the Cyanogen guys. Android modders. 

The same people who used a "publicly available private key" to sign their
code.  Which, being publicly available to anyone, was promptly used by malware
authors to sign *their* code.

Reading through some of the Cyanogen threads, I get the impression they see
security as a nuisance to be bypassed rather than a real requirement.

Peter.
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] DigiNotar SSL Hack Diagram | Cyber Chatter

[Jeffrey Walton]

On Tue, Sep 20, 2011 at 4:54 PM, Marsh Ray  wrote:
> On 09/20/2011 03:21 PM, Jeffrey Walton wrote:
>>
>> Google's smart phone position
>> (http://code.google.com/p/cyanogenmod/issues/detail?id=4260): "Why
>> would we remove the root certificate?  DigiNotar hasn't been revoked
>> as a CA... MITM attacks are pretty rare." (Sep 1, 2011). On Sept 2,
>> 2011 the issue was closed. On Sept 10, 2011 they took partial action
>> (apparently, the project maintainers were getting tired of folks
>> re-opening the issue).
>
> Those are the Cyanogen guys. Android modders. I heard that one of them was
> employed by Samsung, but AFAICT they are not speaking for Google.
>
> People who run Cyanogen will probably get the fix faster than I will get one
> for my non-modded Google Nexus S phone though. :-/
My apologies.
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] DigiNotar SSL Hack Diagram | Cyber Chatter

[Marsh Ray]

On 09/20/2011 03:21 PM, Jeffrey Walton wrote:


Google's smart phone position
(http://code.google.com/p/cyanogenmod/issues/detail?id=4260): "Why
would we remove the root certificate?  DigiNotar hasn't been revoked
as a CA... MITM attacks are pretty rare." (Sep 1, 2011). On Sept 2,
2011 the issue was closed. On Sept 10, 2011 they took partial action
(apparently, the project maintainers were getting tired of folks
re-opening the issue).


Those are the Cyanogen guys. Android modders. I heard that one of them 
was employed by Samsung, but AFAICT they are not speaking for Google.


People who run Cyanogen will probably get the fix faster than I will get 
one for my non-modded Google Nexus S phone though. :-/


- Marsh
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] Data sets: certificates that are different from two scanning locations

[Ralph Holz]

Hi,

On 09/20/2011 12:02 PM, Ben Laurie wrote:
> Where's the paper?

From what I understand, it seems we are allowed to send it to
individuals and publish it on our homepage if we cite the DOI. I am
currently verifying that and waiting for the DOI, and will then upload
it to our site.

Ralph


> On Mon, Sep 19, 2011 at 11:18 PM, Ralph Holz  > wrote:
> 
> Good day,
> 
> We have just uploaded the following data sets we mention in our IMC
> paper.
> 
> Certificates found different between location China-1 and TUM, Apr 2011
> Certificates found different between location China-2 and TUM, Apr 2011
> Certificates found different between location Moscow and TUM, Apr 2011
> Certificates found different between location UCSB and TUM, Apr 2011
> 
> All from university networks (PlanetLab). The data sets contain host
> name, cert as seen from remote location, cert as seen from TUM.
> 
> The download location is:
> 
> http://pki.net.in.tum.de/
> 
> We did not have the time to go through the many hosts and certs,
> although we did take a thorough sample (and found nothing clearly
> suspicious).
> 
> We have promised in the paper to offer these data sets to other
> researchers so they can have a look. I thought this list is a good place
> to start.



signature.asc
Description: OpenPGP digital signature
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] DigiNotar SSL Hack Diagram | Cyber Chatter

[Jeffrey Walton]

On Tue, Sep 20, 2011 at 10:37 AM, el GaTo mAlO  wrote:
> I am a n00b so be nice. I wrote this post about the Diginotar hack and I
> kid of mind-map it. Any comments would be welcomed.
>
> http://uscyberlabs.com/blog/2011/09/16/diginotar-ssl-hack-diagram/
> Timeline of DigiNotar SSL Hack. | Chronological Order of DigiNotar
> SSL-CA Hack
> http://uscyberlabs.com/blog/2011/09/12/timeline-diginotar-ssl-hack/
Apple patched 10.6.8 and 10.7 desktops and servers on Sept 09,
iDevices , and other desktops and servers are still vulnerable.
http://support.apple.com/kb/HT4920.

Microsoft smart phones might still be vulnerable.
http://www.pcworld.com/businesscenter/article/239607/diginotar_certificates_are_pulled_but_not_on_smartphones.html

Google's smart phone position
(http://code.google.com/p/cyanogenmod/issues/detail?id=4260): "Why
would we remove the root certificate?  DigiNotar hasn't been revoked
as a CA... MITM attacks are pretty rare." (Sep 1, 2011). On Sept 2,
2011 the issue was closed. On Sept 10, 2011 they took partial action
(apparently, the project maintainers were getting tired of folks
re-opening the issue).

Recall that Marsh pointed out that folks thought they were being
MITM'd at least 6 days earlier
(https://www.google.com/support/forum/p/gmail/thread?tid=2da6158b094b225a&hl=en).

Apparently, Google does not want to disrupt e-commerce in the western
hemisphere at the expense of folks in the eastern hemisphere. +1 to
Google.

Jeff
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] SSL is not "broken by design"

[James A. Donald]

On 2011-09-21 3:32 AM, Jeffrey Walton wrote:

It seems to me that both the network and the endpoints are at risk. By
what degree the endpoint exceeds the network is an open question for
me since (in my observations) most folks and organizations don't boast
like ComodoHacker. Sadly, I suspect its 'epidemic vs pandemic' and not
'rare/isolated vs occasional'.


It has been a very long time since I had virus or trojan on my home 
computers.  The only time my website was hacked, someone had socially 
engineered my email password out of microsoft.


So it is not apparent to me that the node is the problem.  My wife knows 
nothing about computers.  I taught her not to click on anything that 
comes in email, that email is untrustworthy, that you should trust your 
own bookmarks rather than other people's links, and just don't download 
stuff unless you are sure where it comes from.  She stopped getting 
viruses.   Every so often she gets one of those scams "It is an 
emergency, click here", and she panics thinking it really is an 
emergency, but she does not click there.

___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] SSL is not "broken by design"

[Jeffrey Walton]

On Tue, Sep 20, 2011 at 1:09 PM, ianG  wrote:
> On 18/09/11 20:02 PM, M.R. wrote:
>>
>> On 18/09/11 08:59, James A. Donald wrote:
>>
>>> If we acknowledge that SSL is not secure, then need
>>> something that is secure.
>>
>> Nothing is either "secure", or "not secure". Any engineering
>> system is either secure for the purpose it was designed for,
>> or it is not. SSL is secure, since it is secure for the
>> purpose it was designed and implemented for.
>
> That's bad engineering.  Any system that is designed for protecting humans
> has to base itself on risks.  Either it has a reasonable chance of
> addressing the risks at a good level, or it addresses the risks at a less
> than good level.
>
> It is only cryptographers that insist that security is binary -- perfect or
> not there at all. Too my knowledge, no other engineering discipline falls to
> this hubris [0].  They achieve this remarkable feat by drawing the boundary
> of security so narrow as to be typically irrelevant to most purposes.
>
> This can be seen in the original design of SSL.  It was designed to protect
> the wire, because it was theorised that the wire was where the threat was.
>  Eavesdropping, MITMs and the like.  Not the node.
>
> But, if you read carefully between the lines, there was no evidence of that
> statement.  In fact, it turns out, the reason that the threat was taken to
> be the wire and not the node was that (a) there was a military cryptography
> model that supported wire threats as important, and (b) there was an exotic
> and sexy cryptography design that could defeat it.
>
> In other words, they did it because they could [1].
>
> In practice it was the reverse:  in commercial threats, the node is the
> problem.  It's always been far greater of a problem than the wire [1].  This
> is why SSL is often considered to be a fashion accessory, not a serious
> indicator of security; it didn't solve the real problem, but it itself
> wasn't much of an issue until attackers started embarrassing it by invading
> its design space with attacks.
It seems to me that both the network and the endpoints are at risk. By
what degree the endpoint exceeds the network is an open question for
me since (in my observations) most folks and organizations don't boast
like ComodoHacker. Sadly, I suspect its 'epidemic vs pandemic' and not
'rare/isolated vs occasional'.

Network attacks are not an isolated incident (recall Tunisia and
Facebook?), not to mention chronic problems with Cisco gear in the
network, and the cheap cable/dsl broadband routers and home networking
equipment that rarely gets updated.

Jeff
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] SSL is not "broken by design"

[ianG]

On 18/09/11 20:02 PM, M.R. wrote:

On 18/09/11 08:59, James A. Donald wrote:


If we acknowledge that SSL is not secure, then need
something that is secure.


Nothing is either "secure", or "not secure". Any engineering
system is either secure for the purpose it was designed for,
or it is not. SSL is secure, since it is secure for the
purpose it was designed and implemented for.


That's bad engineering.  Any system that is designed for protecting 
humans has to base itself on risks.  Either it has a reasonable chance 
of addressing the risks at a good level, or it addresses the risks at a 
less than good level.


It is only cryptographers that insist that security is binary -- perfect 
or not there at all. Too my knowledge, no other engineering discipline 
falls to this hubris [0].  They achieve this remarkable feat by drawing 
the boundary of security so narrow as to be typically irrelevant to most 
purposes.


This can be seen in the original design of SSL.  It was designed to 
protect the wire, because it was theorised that the wire was where the 
threat was.  Eavesdropping, MITMs and the like.  Not the node.


But, if you read carefully between the lines, there was no evidence of 
that statement.  In fact, it turns out, the reason that the threat was 
taken to be the wire and not the node was that (a) there was a military 
cryptography model that supported wire threats as important, and (b) 
there was an exotic and sexy cryptography design that could defeat it.


In other words, they did it because they could [1].

In practice it was the reverse:  in commercial threats, the node is the 
problem.  It's always been far greater of a problem than the wire [1].  
This is why SSL is often considered to be a fashion accessory, not a 
serious indicator of security; it didn't solve the real problem, but it 
itself wasn't much of an issue until attackers started embarrassing it 
by invading its design space with attacks.




iang


[0] that's a bit of a misnomer, even cryptographers warn the builders of 
crypto tools that on-off security doesn't exist.
[1] So, SSL is broken by requirements.  It meets its requirements well, 
but they weren't so useful to society.
[2] with notable exception of SSH, which had a proven eavesdropping 
problem so put in place an eavesdropping solution :)

___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] SSL is not "broken by design"

[ianG]

On 20/09/11 01:53 AM, Andy Steingruebl wrote:
SSL wasn't designed to stop phishing, if sites don't deploy it with 
mutual-auth it can't possibly do so.


Yes, it was.  SSL was upgraded in v2 to provide a complete solution to 
the MITM.  This is evident in v2's addition of certificates, and the use 
of browser UI elements in the original beta Netscape 1.0.  The whole 
design was holistic.  The elements to cover the phishing possibility -- 
CA branding -- were stripped out for the final [0].



Saying it is a failure because it doesn't stop that ignores the 
problem it is designed to solve, or at least some it could credibly 
claim to solve.


What is going on here is an adroit dancing between different meanings of 
the word SSL. There are two different meanings available to the promoter.


SSL at the protocol level only does a secure connection.  SSL at the 
architectural level provides a complete system to solve secure ecommerce 
between parties who haven't met each other as yet.


Which meaning do you want to use?  For all of this discussion, only the 
second is relevant.  It's the architecture that is broken, not the protocol.


SSH doesn't solve phishing either. Is it a total failure also? I don't 
think so. SSL is used for a lot more than HTTPS. Any proposal to "fix" 
it *must* take that into account. - Andy


Irrelevant, because SSH at the architectural level and SSH at the 
protocol level are aligned and in balance.  There is no discord because 
SSH was never really taken out of its intended design framework.  That's 
arguably because the designer wasn't facing the political forces of the 
times, which the designers of SSL drowned in.  For whatever reasons, we 
can skip that and look at the results:  SSH was pretty much always used 
in accordance with its original design-assumptions, whereas SSL was 
pretty much never used in accordance with its original design-assumptions.


iang


[0] This of course is the problem with designing for a problem you 
haven't any evidence of existance ;-) By the time you need the solution, 
it's been modified beyond recognition, and no longer works.

___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

[cryptography] DigiNotar SSL Hack Diagram | Cyber Chatter

[el GaTo mAlO]

I am a n00b so be nice. I wrote this post about the Diginotar hack and I
kid of mind-map it. Any comments would be welcomed.

http://uscyberlabs.com/blog/2011/09/16/diginotar-ssl-hack-diagram/
Timeline of DigiNotar SSL Hack. | Chronological Order of DigiNotar
SSL-CA Hack
http://uscyberlabs.com/blog/2011/09/12/timeline-diginotar-ssl-hack/

Thanks,
gato

-- 
This electronic mail message is intended exclusively for the individual or 
entity to which it is addressed. This message, together with any attachment, 
may contain confidential and privileged information. Any views, opinions or 
conclusions expressed in this message are those of the individual sender and do 
not necessarily reflect the views of USCyberLabs Inc. or its affiliates. Any 
unauthorized review, use, printing, copying, retention, disclosure or 
distribution is strictly prohibited. If you have received this message in 
error, please immediately advise the sender by reply email message to the 
sender and delete all copies of this message. Thank you.

___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

[cryptography] [OT]: End of the road for DigiNotar as bankruptcy declared

[Jeffrey Walton]

http://nakedsecurity.sophos.com/2011/09/20/end-of-the-road-for-diginotar-as-bankruptcy-declared/

DigiNotar, the Dutch certificate authority which hackers compromised
and used to generate hundreds of bogus web security certificates, has
filed for bankruptcy.

The announcement that DigiNotar has filed for voluntary bankruptcy was
made today by its US parent company VASCO Data Security International.
...
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] Math corrections

[Jeffrey Walton]

On Mon, Sep 19, 2011 at 7:31 PM, Benjamin Kreuter  wrote:
> On 09/18/2011 05:11 PM, Marsh Ray wrote:
>> B. If your threat model considers as an adversary government A, then
>> you're in good company with governments B through Z. So all the comments
>> on "won't save you from The Government", while true, are also
>> potentially writing off your biggest ally.
>
> Unless, of course, we continue to use the system as it exists today,
> where any trusted CA can sign a certificate for anyone.  If a particular
> government supports a CA that is "cooperative" with that government,
> then either nobody in the world would be safe, or the system will
> fracture and we will not have a global PKI.
If 'global PKI' == 'insecure', why is that a bad thing?

>> C. At the end of the day, governments need to log into their VPNs and
>> check their MS Outlook Web Access email remotely just like everybody
>> else. Now consider that this applies to process engineers at power
>> plants and chemical facilities too. When you hear US DHS people talking
>> about "national infrastructure vulnerable to cyber attack" they are
>> sincerely concerned about this type of exposure.
>
> So the only trustworthy CAs will be the ones that sign certificates for
> power companies or other "national security" related entities?  We need
> a system that can be used and trusted (to a reasonable degree) by
> everyone, not just big or "important" organizations.
>
>> At some point, the influence of people on the defense side will outweigh
>> those who benefit from the attack side.
>
> I doubt this will happen any time soon.  Consider this official (and
> apparently still current) FAQ from the Department of Justice:
>
> http://www.justice.gov/criminal/cybercrime/cryptfaq.htm
>
> Yes, that was issued over a decade ago, but "key recovery" -- which we
> are meant to believe is not the same as key escrow -- remains the DOJ's
> goal when it comes to cryptography.  There is also the more recent push
> by the Obama administration to create a system that allows law
> enforcement agencies to more easily hijack domain names.
Its a chronic problem, and its getting progressively worse. When a
person has a chronic, progressive disease (such as cancer), they
usually dies sooner than latter. This problems will not die - they
need to be solved by engineers, security architects, and
cryptographers who don't bend to political pressures.

>> Now that the cat's out of the bag about PKI in general and there's an
>> Iranian guy issuing to himself certs for www.*.gov seemingly at will, I
>> think the current PKI system will not escape the black hole at this
>> point, it crossed the event horizon sometime earlier this year.
>
> I doubt it.  The cat has been out of the bag on how easily email can be
> forged for decades now, but how often do you receive digitally signed
> email?  The cat has been out of the bag about running out of IPv4
> addresses for many years, but IPv6 deployment has been sluggish.
> Without a strong incentive, these things will not change, and the PKI is
> no different.  I doubt that the current PKI will be gone by the end of
> this decade -- criminal MITM attacks are just not in-your-face enough to
> generate a public outcry, and governments are not terribly interested in
> thwarting their own law enforcement agencies.
All the more reason the security folks should model government as a
threat. It does not matter which government - US, UK, Iran, Libya,
North Korea, Tunisia, etc. They are all trying to restrict or remove
privacy, and some consequences are dire. What good is a written
security policy that carries an indemnity to a dead dissident?

Jeff
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] Data sets: certificates that are different from two scanning locations

[Ben Laurie]

Where's the paper?

On Mon, Sep 19, 2011 at 11:18 PM, Ralph Holz  wrote:

> Good day,
>
> We have just uploaded the following data sets we mention in our IMC paper.
>
> Certificates found different between location China-1 and TUM, Apr 2011
> Certificates found different between location China-2 and TUM, Apr 2011
> Certificates found different between location Moscow and TUM, Apr 2011
> Certificates found different between location UCSB and TUM, Apr 2011
>
> All from university networks (PlanetLab). The data sets contain host
> name, cert as seen from remote location, cert as seen from TUM.
>
> The download location is:
>
> http://pki.net.in.tum.de/
>
> We did not have the time to go through the many hosts and certs,
> although we did take a thorough sample (and found nothing clearly
> suspicious).
>
> We have promised in the paper to offer these data sets to other
> researchers so they can have a look. I thought this list is a good place
> to start.
>
> Ralph
>
>
> ___
> cryptography mailing list
> cryptography@randombit.net
> http://lists.randombit.net/mailman/listinfo/cryptography
>
>
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] SSL is not "broken by design"

[Ben Laurie]

On Tue, Sep 20, 2011 at 8:48 AM, Peter Gutmann wrote:

> Nico Williams  writes:
>
> >For a desktop I'd say: [...]
> >
> >For smartphones and tablets I'd say: [...]
>
> You can't do UI design like this, because chances are it's not going to
> work.
> By this I mean that we have 10-15 years of statistics showing that this
> approach doesn't work, so when I say "chances are" I mean "existing
> statistics
> say ...".  You need to look back at the 15 years of statistics and research
> and see what goes wrong, and in what way, and then build something based on
> that.  I give one example in the talk that I've referenced several times
> now,
> which is based on a great many user studies on what does and doesn't work.
>  We
> can (probably) do effective UI for this by turning the attackers' tactics
> against them, but you need to understand the environment in which you're
> operating rather than simply proposing a solution.
>

Well, don't tease. How?
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] SSL is not "broken by design"

[Ben Laurie]

On Tue, Sep 20, 2011 at 4:09 AM, James A. Donald  wrote:

> On Tue, Sep 20, 2011 at 12:42 AM, James A. Donald**
> wrote:
>
>> The user expects a login screen.  Login screens are *not* traditionally
>>>
>>> full screen, even on cell phones.  Therefore, if we take login out of the
>>> web page, if the user ceases to expect or perceive login as happening out
>>> there on the web, but instead perceives it as happening locally, the user
>>> will not expect a full screen login page.
>>>
>>
> On 2011-09-20 12:20 PM, Ben Laurie wrote:
>
>> That is not the issue. The issue is that if an app can be full screen it
>> can
>> fake whatever a login window looks like.
>>
>
> Which is why I said that the logon screen should rearrange other windows on
> the desktop so as to always be overlapping.
>
> When you launch your true login app, nothing that an adversary might be
> able to control should be allowed to be full screen.  If your browser is up,
> showing a web page, it will be moved and resized so that the login screen
> partially overlaps it.
>
>
> That is why I earlier said:
>It has a colorful and irregular non rectangular window that
>differs from one user to the next, and it always positions
>itself and other windows so that it overlaps both the web
>
>page, and the desktop or whatever non web apps happen to
>be there.
>
> Thus if the user sees the login page seemingly wholly on top of a web page,
> this will look funny.
>

So how do you stop the full screen app from simulating all this?

Note that relying on the user to notice the screen isn't "as expected" has
already been shown not to work, at least for many cases of "as expected".
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] SSL is not "broken by design"

[Peter Gutmann]

Nico Williams  writes:

>For a desktop I'd say: [...]
>
>For smartphones and tablets I'd say: [...]

You can't do UI design like this, because chances are it's not going to work.
By this I mean that we have 10-15 years of statistics showing that this
approach doesn't work, so when I say "chances are" I mean "existing statistics
say ...".  You need to look back at the 15 years of statistics and research
and see what goes wrong, and in what way, and then build something based on
that.  I give one example in the talk that I've referenced several times now,
which is based on a great many user studies on what does and doesn't work.  We
can (probably) do effective UI for this by turning the attackers' tactics
against them, but you need to understand the environment in which you're
operating rather than simply proposing a solution.

Peter.
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography