Re: OpenSparc -- the open source chip (except for the crypto parts)

2008-05-04 Thread Alexander Klimov
On Thu, 1 May 2008, zooko wrote:
 I would think that it also helps if a company publishes the source
 code and complete verification tools for their chips, such as Sun has
 done with the Ultrasparc T2 under the GPL.

To be sure that implementation does not contain back-doors, one needs
not only some source code but also a proof that the source code one
has is the source of the implementation. With open-source software one
can get such a proof by compiling the source themself (as far as they
trust their compiler toolchain), but I don't see any way to get such a
proof for non-FPGA hardware.

-- 
Regards,
ASK

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


Re: New result in predicate encryption: disjunction support

2008-05-04 Thread Ben Laurie

Scott Guthery wrote:
Those interested in predicate encryption might also enjoy 

Group Authentication Using The Naccache-Stern Public-Key Cryptosystem 


http://arxiv.org/abs/cs/0307059

which takes a different approach and handles negation.

A group authentication protocol authenticates pre-defined groups of
individuals such that: 
- No individual is identified 
- No knowledge of which groups can be successfully authenticated is known to
the verifier 


I don't understand this one, could you say it again with more words?

- No sensitive data is exposed 
The paper presents a group authentication protocol based on splitting the

private keys of the Naccache-Stern public-key cryptosystem in such a way
that the Boolean expression defining the authenticable groups is implicit in
the split

Shamelessly, Scott

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





--
http://www.apache-ssl.org/ben.html   http://www.links.org/

There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit. - Robert Woodruff

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


Re: User interface, security, and simplicity

2008-05-04 Thread Ben Laurie

Steven M. Bellovin wrote:

On Sat, 03 May 2008 17:00:48 -0400
Perry E. Metzger [EMAIL PROTECTED] wrote:


[EMAIL PROTECTED] (Peter Gutmann) writes:

I am left with the strong suspicion that SSL VPNs are easier to
configure and use because a large percentage of their user
population simply is not very sensitive to how much security is
actually provided.

They're easier to configure and use because most users don't want
to have to rebuild their entire world around PKI just to set up a
tunnel from A to B.

I'm one of those people who uses OpenVPN instead of IPSEC, and I'm one
of the people who helped create IPSEC.

Right now, to use SSH to remotely connect to a machine using public
keys, all I have to do is type ssh-keygen and copy the locally
generated public key to a remote machine's authorized keys file.
When there is an IPSEC system that is equally easy to use I'll switch
to it.

Until then, OpenVPN let me get started in about five minutes, and the
fact that it is less than completely secure doesn't matter much to me
as I'm running SSH under it anyway.


There's a technical/philosophical issue lurking here.  We tried to
solve it in IPsec; not only do I think we didn't succeed, I'm not at
all clear we could or should have succeeded.

IPsec operates at layer 3, where there are (generally) no user
contexts.  This makes it difficult to bind IPsec credentials to a user,
which means that it inherently can't be as simple to configure as ssh.

Put another way, when you tell an sshd whom you wish to log in as, it
consults that user's home directory and finds an authorized_keys file.
How can IPsec -- or rather, any key management daemon for IPsec -- do
that?  Per-user SPDs?  Is this packet for port 80 for user pat or user
chris?

I can envision ways around this (especially if we have an IP address
per user of a system -- I've been writing about fine-grained IP address
assignment for years), but they're inherently a lot more complex than
ssh.


I don't see why.

The ssh server determines who the packets are for from information sent 
to it by the ssh client.


The ssh client knows on whose behalf it is acting by virtue of being 
invoked by that user (I'll admit this is a simplification of the most 
general case, but I assert my argument is unaffected), and thus is able 
to include the information when it talks to the server.


Similarly, the client end of an IPSEC connection knows who opened the 
connection and could, similarly, convey that information. That data may 
not be available in some OSes by the time it gets to the IPSEC stack, 
but that's a deficiency of the OS, not a fundamental problem.


It seems to me there's no real difference between the two cases.

Cheers,

Ben.

--
http://www.apache-ssl.org/ben.html   http://www.links.org/

There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit. - Robert Woodruff

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


Re: User interface, security, and simplicity

2008-05-04 Thread Ray Dillinger
On Sat, 2008-05-03 at 23:35 +, Steven M. Bellovin wrote:

 There's a technical/philosophical issue lurking here.  We tried to
 solve it in IPsec; not only do I think we didn't succeed, I'm not at
 all clear we could or should have succeeded.
 
 IPsec operates at layer 3, where there are (generally) no user
 contexts.  This makes it difficult to bind IPsec credentials to a user,
 which means that it inherently can't be as simple to configure as ssh.

Let me restate things just to make sure I understand the problem.
You're talking about binding IPsec credentials to a user, but 
I want to look at it from the point of view of exactly what 
problems this causes, so is the following an accurate position?

The problem is that we're trying to have entities with different 
security needs share a common set of authentications.  When user 'pat' 
and user 'sandy' have different security needs (different authorized
or trustable communication partners, to start with) we can't give 
them IPSEC because IPSEC operates on channels between machines 
rather than on channels between trusting/trusted entities.   Even 
if 'pat' and 'sandy' both have a trusted/trusting entity on a given
remote machine from theirs, IPSEC fails them because it cannot
differentiate between the various entities (users, agents, services)
using that remote machine, when 'pat' and 'sandy' need it to.  
Similarly, it fails the entities on that remote machine because it 
cannot differentiate between 'pat', 'sandy' and any other entities 
using the local machine, when trust relationships might exist only
for some subset of those entities.

Bear


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


Re: User interface, security, and simplicity

2008-05-04 Thread Perry E. Metzger

Jacob Appelbaum [EMAIL PROTECTED] writes:
 Perry E. Metzger wrote:
 Until then, OpenVPN let me get started in about five minutes, and the
 fact that it is less than completely secure doesn't matter much to me
 as I'm running SSH under it anyway.
[...]
 I'm always curious to hear what designers of protocols actually use on a
 daily basis. I'm also really curious how said designers evaluate their
 choices.

 I really like OpenVPN. It's really smooth to setup, it's very easy to
 use on the Big Three Platforms.

 Have you read the source to OpenVPN? Do you think that it's
 cryptographically sound? Is it properly implemented?

 I've found some stuff I wonder about and I'm curious if anyone else has?

I can't claim to like the innards, and it seems bizarre to me that the
designers didn't simply use IPSec encapsulated in UDP as the
underlying protocol. (Were I writing such a thing today, I might use
DTLS.)

That said, in my usage pattern, I don't care much about the possible
security flaws. I would not recommend the package to clients, however.

It is obvious to anyone using modern IPSec implementations that their
configuration files are a major source of pain. In spite of this, the
designers don't seem to see any problem. The result has been that
people see IPSec as unpleasant and write things like OpenVPN when the
underlying IPSec protocol is just fine and it is the implementations
that are unpleasant.

-- 
Perry E. Metzger[EMAIL PROTECTED]

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


RE: New result in predicate encryption: disjunction support

2008-05-04 Thread Scott Guthery
A group member asked me to elaborate on:

 - No knowledge of which groups can be successfully authenticated is 
 known to the verifier

What this tries to say is that the verifier doesn't need to have a list of
all authenticable groups nor can the verifier draw any conclusions about
other authenticable groups based on authenticating one group.

One useful application of the Katz/Sahai/Waters work is a counter to traffic
analysis.  One can send the same message to everyone but ensure that only a
defined subset can read the message by proper key management.  What is less
clear is how to ensure that decrytion with the wrong key doesn't yield an
understandable (and actionable) message.

Cheers, Scott

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


RE: New result in predicate encryption: disjunction support

2008-05-04 Thread Jonathan Katz

On Sun, 4 May 2008, Scott Guthery wrote:


One useful application of the Katz/Sahai/Waters work is a counter to traffic
analysis.  One can send the same message to everyone but ensure that only a
defined subset can read the message by proper key management.  What is less
clear is how to ensure that decrytion with the wrong key doesn't yield an
understandable (and actionable) message.


This is actually pretty easy to do by, e.g., padding all valid messages 
with sufficiently-many 0s. Decryption with an incorrect key will result in 
something random that is unlikely to end with the requisite number of 0s 
(and so will be discarded).


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


Re: User interface, security, and simplicity

2008-05-04 Thread Thor Lancelot Simon
On Sat, May 03, 2008 at 07:50:01PM -0400, Perry E. Metzger wrote:
 
 Steven M. Bellovin [EMAIL PROTECTED] writes:
  There's a technical/philosophical issue lurking here.  We tried to
  solve it in IPsec; not only do I think we didn't succeed, I'm not at
  all clear we could or should have succeeded.
 
  IPsec operates at layer 3, where there are (generally) no user
  contexts.  This makes it difficult to bind IPsec credentials to a user,
  which means that it inherently can't be as simple to configure as ssh.
 
 I disagree. Fundamentally, OpenVPN isn't doing anything IPSEC couldn't
 do, and yet is is fairly easy to configure.

And yet there's no underlying technical reason why it is any easier to
configure than IPsec is; it is all a matter of the configuration interface
provided by your chosen SSL VPN (in this case, OpenVPN) or IPsec
implementation.

I find it amusing (but somewhat sad) that in fact one can find basically
the same set of flaws in each, but they're considered damning in IPsec
while they're handwaved away or overlooked in SSL VPNs.  Of course you
(Perry) or I can configure either IPsec or OpenVPN in a safe and sane way;
and, of course, there are some VPN packages of either type (IPsec or SSL
VPN) which have configuration interfaces so bad that we _couldn't_, in
fact, set them up safely -- because they prevent safe, sane configuration.

The problem is that whether you or I _can_ set software X up safely isn't
the question that matters.  The question that matters is _will_ a naive
user who does not understand the underlying security questions set software
X up securely.

And, in fact, most VPN software of any type fails this test.  My concern
is that an excessive focus on how hard is it to set this thing up? can
seriously obscure the important second half of the question and if you
set it up in the easiest possible way, is it safe?

Thor

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


Re: User interface, security, and simplicity

2008-05-04 Thread Ian G

Perry E. Metzger wrote:


It is obvious to anyone using modern IPSec implementations that their
configuration files are a major source of pain. In spite of this, the
designers don't seem to see any problem. The result has been that
people see IPSec as unpleasant and write things like OpenVPN when the
underlying IPSec protocol is just fine and it is the implementations
that are unpleasant.



Kerckhoffs' 6th, providing great entertainment for the 
security world, since 1883.


=
6. Finally, it is necessary, given the circumstances that 
command its application, that the system be easy to use, 
requiring neither mental strain nor the knowledge of a long 
series of rules to observe.

=



iang


PS:  Although his 6th is arguably the most important, his 
others are well worth considering:


https://www.financialcryptography.com/mt/archives/000195.html

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


Re: OpenSparc -- the open source chip (except for the crypto parts)

2008-05-04 Thread Marcos el Ruptor

To be sure that implementation does not contain back-doors, one needs
not only some source code but also a proof that the source code one
has is the source of the implementation.


Nonsense. Total nonsense. A half-decent reverse engineer does not  
need the source code and can easily determine the exact operation of  
all the security-related components from the compiled executables,  
extracted ROM/EPROM code or reversed FPGA/ASIC layout (see the recent  
Karsten Nohl's extraction of Crypto-1 code for example).


All this open-source promotion is a huge waste of time. Us crackers  
know exactly how all the executables we care about (especially all  
the crypto and security related programs) work. We do not always  
publish our results, but look, somehow RC4, SecurID, DST40, KeeLoq,  
Crypto1, Hitag2, etc. all got reverse engineered and published when  
people actually cared to do it. A lot more other closed-code ciphers,  
random number generators and other components have been reverse- 
engineered and thoroughly analysed without publishing the results  
just because those results were not interesting, could do more harm  
than good if published or if keeping them secret could benefit the  
cracker.


As a reverse engineer with over 20 years of experience, I can  
guarantee everyone on this list who is not familiar with this process  
that from the security evaluation point of view there is ABSOLUTELY  
NO BENEFIT in the open-source concept. It is actually much much  
easier to hide a backdoor in the C or especially C++ code from anyone  
reading it than it is in the compiled assembly code from a reverse  
engineer, even if it is highly obfuscated like Skype. High-level  
languages offer enough opportunities to hide and cover up some sneaky  
behind-the-scenes magic that no one will notice for years or ever at  
all unless they know exactly what to look for and where. I always  
compile the open-source code, then reverse engineer it and see what  
it is actually doing.


If you want a guarantee or a proof, better ask all the reverse  
engineers you know to take a closer look at the program and tell you  
if there is a backdoor, anything malicious or anything sneaky or  
suspicious. Don't trust your own eyes. I've seen too many open-source  
applications with well-concealed backdoors or unnoticeable security  
holes. Linux's endless exploitable vulnerabilities should be enough  
of a proof of that.


Best regards,
Marcos el Ruptor
http://www.enrupt.com/ - Raising the bar.

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


Re: User interface, security, and simplicity

2008-05-04 Thread Perry E. Metzger

Thor Lancelot Simon [EMAIL PROTECTED] writes:
 On Sat, May 03, 2008 at 07:50:01PM -0400, Perry E. Metzger wrote:
 I disagree. Fundamentally, OpenVPN isn't doing anything IPSEC couldn't
 do, and yet is is fairly easy to configure.

 And yet there's no underlying technical reason why it is any easier to
 configure than IPsec is;

Absolutely. There is no reason one couldn't build an easy to configure
IPSec. Indeed, OpenVPN could simply use IPSec if its authors wanted
to.

No one has created the easy to configure IPSec, however, so I don't
use IPSec for my own needs.

 I find it amusing (but somewhat sad) that in fact one can find basically
 the same set of flaws in each, but they're considered damning in IPsec
 while they're handwaved away or overlooked in SSL VPNs.

Myself, I don't handwave away said flaws. I don't recommend that
clients use OpenVPN, for example. On the other hand, most of my
clients can afford to pay admins to spend lots of time on this, and I
couldn't afford to spend the time myself.

 And, in fact, most VPN software of any type fails this test.  My concern
 is that an excessive focus on how hard is it to set this thing up? can
 seriously obscure the important second half of the question and if you
 set it up in the easiest possible way, is it safe?

Well, it is pretty easy to configure SSH safely. Set it to only use
public keys, copy your private key to the remote host in the
authorized_keys file, and you're more or less done. There is no reason
all the defaults can't be set up for a nice easy to use IPSec based
package in such a way that it requires a deliberate effort to make the
thing unsafe and it is more or less that easy to use.

Unfortunately, people just don't spend nearly the amount of time on
the UI for their IPSec systems that they do on the crypto, so they
spoil all the hard work they've done making the implementation sound
by making it impossible for ordinary people to understand.


-- 
Perry E. Metzger[EMAIL PROTECTED]

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


Re: OpenSparc -- the open source chip (except for the crypto parts)

2008-05-04 Thread Perry E. Metzger

Marcos el Ruptor [EMAIL PROTECTED] writes:
 To be sure that implementation does not contain back-doors, one needs
 not only some source code but also a proof that the source code one
 has is the source of the implementation.

 Nonsense. Total nonsense. A half-decent reverse engineer does not
 need the source code and can easily determine the exact operation of
 all the security-related components from the compiled executables,
 extracted ROM/EPROM code or reversed FPGA/ASIC layout

I'm glad to know that you have managed to disprove Rice's
Theorem. Could you explain to us how you did it? I suspect there's an
ACM Turing Award awaiting you.

Being slightly less sarcastic for the moment, I'm sure that a good
reverse engineer can figure out approximately what a program does by
looking at the binaries and approximately what an ASIC does given
good equipment to get the layout. What you can't do, full stop, is
know that there are no unexpected security related behaviors in the
hardware or software. That's just not possible.

 All this open-source promotion is a huge waste of time. Us crackers
 know exactly how all the executables we care about (especially all
 the crypto and security related programs) work.

With respect, no, you don't. If you did, then all the flaws in Windows
would have been found at once, instead of trickling out over the
course of decades as people slowly figure out new unintended
behaviors. Anything sufficiently complicated to be interesting simply
cannot be fully understood by inspection, end of story.

Now, the original poster was speaking about knowing that a piece of
hardware does exactly what it was originally spec'ed to do. Some of
that involves (among other things) knowing that the validation
information (which a reverse engineer has no access to) applies to the
resulting chip by virtue of knowing that what was compiled was
precisely what was originally validated. There is a valid concern
there.


Perry

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