Re: Tinc's response to Linux's answer to MS-PPTP

2003-09-28 Thread Eric Rescorla
M Taylor [EMAIL PROTECTED] writes:
 On Fri, Sep 26, 2003 at 06:26:16PM -0700, Joseph Ashwood wrote:
   Both SSL and SSH have had their security
   problems . . , as perfect as Peter Gutmann would let us believe.
  They may not be perfect but in neither case can Mallet do as much damage as
  easily, even the recent break in OpenSSH did not allow a compromise as big
  as even the smallest of the problems briefly explored in tinc.
 
 Oh, and they fixed their flaws. SSHv1 is not recommended for use at all,
 and most systems use SSHv2 now which is based upon a draft IETF standard. 
 SSL went through SSLv1, SSLv2, SSLv3, TLSv1.0, and TLSv1.1 is a draft IETF
 standard.

Nitpicking alert:
Draft Standard is the technical term for the second tier of
IETF standardization. (Proposed, Draft, Full). The term for
something that has not yet been approved and given an RFC #
is Internet Draft. SSHv2 and TLSv1.1 are Internet Drafts.

-Ekr
 
-- 
[Eric Rescorla   [EMAIL PROTECTED]
http://www.rtfm.com/

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


Re: Reliance on Microsoft called risk to U.S. security

2003-09-28 Thread Paul Walker
On Sat, Sep 27, 2003 at 01:51:52PM -0400, Jeroen C.van Gelderen wrote:

 Are you familiar with the KeyKOS and EROS operating systems and/or
 Stiegler's CapDesk, a secure desktop in Java? They are all based on the

Without wishing to belittle the authors (EROS is definitely impressive; I'm
not familiar with the others), I suspect one reason that they don't have
many problems is because very few people use them. If they started to become
more widely used, I wonder how long before compromises would creep in.

-- 
Paul

I discovered I scream the same way whether I'm about to be devoured by a
Great White or if a piece of seaweed touches my foot. -- Axel Rose

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


Re: Reliance on Microsoft called risk to U.S. security

2003-09-28 Thread William Allen Simpson
Jeroen C.van Gelderen wrote:
 
 On Saturday, Sep 27, 2003, at 15:48 US/Eastern,
 [EMAIL PROTECTED] wrote:
 
  You have not met my users!
 
 Indeed, but I'm here to learn :)
... 
 something is wrong. Why would she click YES?
... 
 Because I'm an optimist I believe that Alice will read the dialog and
 err on the side of caution. Maybe that isn't realistic. ...
 
 I agree that such composition must be intuitive or we cannot expect it
 to work. I think that CapDesk is a nice publicly available prototype of
 a workable capability desktop. It would be very interesting to see your
 assessment on whether a CapDesk approach would be workable for your
 users. And if it isn't, why not. I hope you can lend your experience.
 
OK, I'll lend mine.  With my ISP hat on, the vast majority of support 
calls have to do with users ignoring the content of M$ dialog boxes,  
hitting YES or OK, then calling when things don't work.  Admittedly, 
the text in those dialog boxes isn't particularly useful.  But this 
costs us a lot of good old hard cash.

Or with my personal hat, my 15-year-old niece had an infected machine.  
Actually a multiply infected machine.  Took me several hours to clean up.  
And then I watched her check her yahoo mail, and click yes on the very 
next Norton/McAfee dialog box, reinfecting her Comcast connected machine 
before my very eyes. 

Why, I asked?  I just spent a lot of time fixing your machine, and 
explained what had gone wrong.  She says, That message came from my 
best friend at school.  

Of course it didn't.  But it probably came from another friend with 
them both in the address book.  And social engineering is a lot more 
powerful than any amount of training, no matter how very recent!

The answer to a technical problem is _not_ depending on user caution!
-- 
William Allen Simpson
Key fingerprint =  17 40 5E 67 15 6F 31 26  DD 0D B9 9B 6A 15 2C 32

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


A quick question...

2003-09-28 Thread Paul Walker
Hi,

Apologies in advance for the vagueness of the question...

Talking to a friend the other day, he was telling me about a potential
loophole with SHA-1 hashes protected by an RSA signature. Basically, he
seemed to think that with an SHA hash of a suitable length (say, 2^20), the
hash could be cubed and still not 'fail', since it was below the key
modulus. If you change the hash length, this problem doesn't occur.

I'm unconvinced for a number of reasons - this sounds very strange to me.
Not least because, even if cubing the hash does work (why cubing?), since
it's infeasible to create a binary which produces a given hash it still
doesn't help. 

Could someone help shed some light on this? Either pointing me at a paper
documenting the hole, or confirming that it's gibberish (at which point I'll
go back to work and ask him for more details :).

Thanks,

-- 
Paul

The ability to quote is a serviceable substitute for wit.
 -- W. Somerset Maugham

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


Re: Reliance on Microsoft called risk to U.S. security

2003-09-28 Thread Zooko

 Jeroen C. van Gelderen [EMAIL PROTECTED] wrote:

 There is no way around asking the user because he is the ultimate 
 authority when it comes to making trust decisions. (Side-stepping the 
 issues in a (corporate) environment where the owner of the machine is 
 entitled to restrict its users in any way he sees fit. The point is 
 that the software agent cannot make trust decisions.)

... but you don't always have to *ask* the user, if instead you can infer from 
actions that the user already performs.

I used to think that a capability desktop would be severely hobbled by the 
requirement that the user state a plethora of privilege rules, until I saw 
Marc Stiegler's CapDesk demo at the second O'Reilly Emerging Technologies 
conference.

In that demo, a perfectly familiar desktop with File - Open and 
File - Save As dialogs also serves as a Least-Privilege-enforcing access 
control system which protects even a naive and lazy user from a malicious text 
editor.

See also Ping Yee's research in secure Human Interface.

Regards,

Zooko O'Whielacronx

http://zooko.com/log.html

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


Re: Reliance on Microsoft called risk to U.S. security

2003-09-28 Thread Jeroen C . van Gelderen
On Saturday, Sep 27, 2003, at 20:31 US/Eastern, Zooko wrote:

 Jeroen C. van Gelderen [EMAIL PROTECTED] wrote:
There is no way around asking the user because he is the ultimate
authority when it comes to making trust decisions. (Side-stepping the
issues in a (corporate) environment where the owner of the machine is
entitled to restrict its users in any way he sees fit. The point is
that the software agent cannot make trust decisions.)
... but you don't always have to *ask* the user, if instead you can 
infer from
actions that the user already performs.
Oops, I didn't mean to imply that you'd have to ask as much as happens 
at present! Automatically inferring is pretty much required if Alice is 
to be able to do a whole day's worth of work without seeing any popups 
in the steady case. You only ask Alice when you cannot otherwise 
reliably infer her intentions; That will be necessary at some point. 
The remaining questions that do get asked then are meaningful and do 
not condition towards a knee-jerk Click-Yes reaction.

I used to think that a capability desktop would be severely hobbled by 
the
requirement that the user state a plethora of privilege rules, until I 
saw
Marc Stiegler's CapDesk demo at the second O'Reilly Emerging 
Technologies
conference.

In that demo, a perfectly familiar desktop with File - Open and
File - Save As dialogs also serves as a Least-Privilege-enforcing 
access
control system which protects even a naive and lazy user from a 
malicious text
editor.
And you can even download and try it for yourself as all of CapDesk is 
freely available. If that is too much, just download Marc's video 
demonstration [1]:

 http://www.erights.org/talks/skynet/index.html

I truly don't know how much more helpful one can get in order to dispel 
the perpetuation of these security myths?

See also Ping Yee's research in secure Human Interface.
http://www.sims.berkeley.edu/~ping/sid/

-J

[1] I don't know why the video is available in M$ proprietary format 
only though :(

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


Re: Tinc's response to Linux's answer to MS-PPTP

2003-09-28 Thread Guus Sliepen
On Sat, Sep 27, 2003 at 07:58:14PM +0100, M Taylor wrote:

 Perhaps a HMAC per chunk, rather than per the payload of a single UDP
 datagram. I suspect per every 5 UDP datagrams, roughly ~7000 bytes of 
 payload may work. This will increase latency.

That would not work either. It would have the same problems as a packet
that has been split into 5 fragments: if one of the fragments gets lost,
the whole packet will be discarded. Fragment reassembly is also
something that is not completely trivial, in the past there have been
some simple DoS attacks for various operating systems that did not
implement IP fragment reassembly correctly.

Each UDP packet must stand on its own, just like the network packet that has
been encapsulated within it.

 This should be redone from scratch, I would look at either using
 Diffie Hellman Key Exchange combined with digital signatures or the updated
 Needham Schroeder Public Key Protocol. Exchange two symmetric keys,
 one used for bulk data encryption, the other used for the HMAC
 authentication. 

I think I prefer the Diffie-Hellman key exchange; the Needham Schroeder
public key protocol needs more round trips and one more RSA
encryption/decryption step.

 I expect this is a reference to Why TCP Over TCP Is A Bad Idea
 http://sites.inka.de/~bigred/devel/tcp-tcp.html

Yes.

 If Guus Sliepen and Ivo Timmermans are willing to seriously rethink their
 high tolerance for unncessary weakness, I think tinc 2.0 could end up being
 a secure piece of software. I hope Guus and Ivo circulate their version 2.0 
 protocol before they do any coding, so that any remaining flaws can be easily 
 fixed in the paper design without changing a single line of code, saving time 
 and effort.

Those are the first encouraging words I've heard since Peter Gutmann's
writeup was posted on Slashdot, thank you! We do plan to get rid of all
the weaknesses, and once we know what we want and we have a draft, I'll
post it in this mailing list.

-- 
Met vriendelijke groet / with kind regards,
Guus Sliepen [EMAIL PROTECTED]


signature.asc
Description: Digital signature


Re: Reliance on Microsoft called risk to U.S. security

2003-09-28 Thread Jürgen Botz
On Sat, 27 Sep 2003, Jeroen C.van Gelderen wrote:
Could it not ask the user? My Apple regularly asks for decisions of
this sort, and remembers the results. So do (popular firewall)
products on the PC. Now, most of these questions are too technical in 
nature but point remains that asking question and remembering the
answer is possible.

I continue to believe that few users would grant an email message
access to both the Internet and the Address Book when they are asked
those two questions, provided that the user had not been conditioned to
clicking YES in order to get any work done at all.
[EMAIL PROTECTED] wrote:
You have not met my users! This is really rather naive. Users don't
understand pop dialogues, they raise their stress level, always clicking
yes makes the problem go away.
Yes... and it isn't that the users are stupid or ignorant.  Most
of the time it's /really hard/ to be 100% sure, unambiguously,
what the pop-up dialogue is talking about.  This is for several
reasons...
- Language.  It's hard to write a clear and unambiguous
  message, and since these are written by programmers they
  usually aren't even grammatically correct, never mind clear
  and unambiguous.
- Context.  The user often has multiple things going on, and
  often acts faster than the computer's stupid, slow, laggy,
  ugly GUI... now what did I do that caused this pop-up?  Was
  it my last click, or the other window that finally popped up
  from the link I clicked 2 minutes ago and which I had almost
  forgotten about?
- User mental state.  The pop-up may ask for permission to use
  a previously entered password, but the user can't remember what
  they previously entered... was that one of my throwaway,
  non-secure passwords, or was it the PIN for my bank account?
These uncertainties cause stress.  After stressing about it for
a while the user clicks one choice only to find later that that
was the wrong one, increasing the stress level even more the
next time.  They are likely to soon give up, but even if they do
persevere in paying attention and trying to make the right choices,
the percentage of errors is going to be very high, and since a single
error can critically compromise security this means it's basically
hopeless.
:j

--
Jürgen Botz   | While differing widely in the various
[EMAIL PROTECTED]   | little bits we know, in our infinite
  | ignorance we are all equal. -Karl Popper


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


Re: quantum hype

2003-09-28 Thread Peter Fairbrother
I promised some links about the 5/6 cloning figure. You've had a few
experimental ones, here are some theory ones.


Cloning machines:
http://www.fi.muni.cz/usr/buzek/mypapers/96pra1844.pdf

Theoretically optimal cloning machines:
http://www.gap-optique.unige.ch/Publications/Pdf/PRL02153.pdf

1/6 disturbance is theoretically optimal, both as a QC interception strategy
and it's an optimal cloning machine:
http://www.gap-optique.unige.ch/Publications/Pdf/PRA04238.pdf

A different approach to the 1/6 figure (2/3 cloned correctly, the 1/3
imperfectly cloned still has a 50% chance of being right):
http://arxiv.org/PS_cache/quant-ph/pdf/0012/0012121.pdf


That lot is pretty much indisputed...

...except for the optimal part; and that's a sideways argument anyway -
the math and physics theory are right as far as they go, just that they
didn't consider everything.

It may be possible to clone better than those optimal solutions,
especially in the classic QC case, or get more information like which
photons were cloned correctly, and perhaps to as near perfection as you
like, but that is in dispute. Actually it's a pretty friendly dispute,
people mostly say I don't know*. I'll post some more links on that later.


*unless someone mentions non-linear transformations. Which is a different
dispute really.
-- 
Peter Fairbrother

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


Re: quantum hype

2003-09-28 Thread Dave Howe
Peter Fairbrother wrote:
 I promised some links about the 5/6 cloning figure. You've had a few
 experimental ones, here are some theory ones.
has anyone with better number theory / probability skills than me taken a
stab at exactly *how* accurate cloning would have to be (and how many
clones you would need) to determine accurately both the bit and filter
values for a quantum key exchange photon? for a single pass (5/6 photons
output) it feels like the odds are stacked against getting a clean
reading; for two passes (25/36) it feels even worse.
how accurate would cloning need to be to get a better than 1/3 failure
rate?

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


Re: Tinc's response to Linux's answer to MS-PPTP

2003-09-28 Thread Ian Grigg
M Taylor wrote:

 Oh, and they fixed their flaws. SSHv1 is not recommended for use at all,
 and most systems use SSHv2 now which is based upon a draft IETF standard.
 SSL went through SSLv1, SSLv2, SSLv3, TLSv1.0, and TLSv1.1 is a draft IETF
 standard.


It is curious, is it not, that there has been no well
written protocol that became successful on its first
attempt?  And, contrariwise, all successful systems
started out with crypto that slept shamefully with
ROT13.


 If Guus Sliepen and Ivo Timmermans are willing to seriously rethink their
 high tolerance for unncessary weakness, I think tinc 2.0 could end up being
 a secure piece of software. I hope Guus and Ivo circulate their version 2.0
 protocol before they do any coding, so that any remaining flaws can be easily
 fixed in the paper design without changing a single line of code, saving time
 and effort.


This is the best thing written so far.  Even if Guus
and Ivo were not to distribute their designs for 2.0,
I would salute their efforts so far.

It is clear that they have users.  Hoorah! I say.  It
is clear that they have successfully enabled millions
of VPN connections.  There art we happy!  It is fair
to say that through their efforts, many hundreds or
thousands of Linux boxen have escaped becoming part
of the lamented and hacked 43,000.  A pack of blessings
light upon the backs of cryptographers!

The notion that Guus and Ivo have done anything in the
slightest sense, wrong, is mysterious to me.  It defies
explanation.  They built a product.  They protected users.

Now, later on, after *proving* the product meets the
needs of the market place, is the time to clean up the
stopgap home-brewed crypto.  It's not the most urgent
thing.  Only if the product is under sustained and
unavoidable attack by the bad guys - like HTTPS - is
it urgent to get in there and fix the security.

And from the absence of any commentary on actual attacks,
there seems all the time in Mantua to prepare a killer 2.0
crypto layer.

Or am I missing something?

iang

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


Re: Reliance on Microsoft called risk to U.S. security

2003-09-28 Thread Bill Frantz
At 8:12 AM -0700 9/27/03, [EMAIL PROTECTED] wrote:
On Fri, 26 Sep 2003, Bill Frantz wrote:

 The real problem is that the viewer software, whether it is an editor, PDF
 viewer, or a computer language interpreter, runs with ALL the user's
 privileges.  If we ran these programs with a minimum of privilege, most of
 the problems would just go away.


And what privileges should the Perl interpreter run with when I click on a
.pl file? How would the graphical shell know what privileges to assign
to each file?

Given a strange program that has just arrived on my machine, my current
policy is not to run it at all.

I might be willing to adopt a policy of giving it a small amount of memory,
CPU, and some space to render on the screen.  That would allow people to
exchange active amusements with a degree of safety.

If the program required more privilege (for example, a new version of a
utility from a co-worker), I would be happy to move it to an environment
where it had the resources it needs to run.


On the other hand a *trivial* privilege system: View (zero privs) vs.
Run (full privs) is viable, and is one of the pre-requisites for a more
secure UI, along with the previously discussed trusted path issues,
non-spoofing of the security interface, ...

Limiting the privilege of the View program would provide protection
against flaws in the viewer.  Given the number of flaws in very basic
software, such protection seems of have real value.

Cheers - Bill


-
Bill Frantz| There's nothing so clear as   | Periwinkle
(408)356-8506  | vague idea you haven't written | 16345 Englewood Ave
www.pwpconsult.com | down yet. -- Dean Tribble | Los Gatos, CA 95032


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


Re: A quick question...

2003-09-28 Thread Greg Rose
At 11:53 PM 9/27/2003 +0100, Paul Walker wrote:
Talking to a friend the other day, he was telling me about a potential
loophole with SHA-1 hashes protected by an RSA signature. Basically, he
seemed to think that with an SHA hash of a suitable length (say, 2^20), the
hash could be cubed and still not 'fail', since it was below the key
modulus. If you change the hash length, this problem doesn't occur.
I'm unconvinced for a number of reasons - this sounds very strange to me.
Not least because, even if cubing the hash does work (why cubing?), since
it's infeasible to create a binary which produces a given hash it still
doesn't help.
I think your friend has a very limited understanding of what's going on; 
he's right in some small sense, but wrong in practice.

Cubing is coming from the assumption that the public exponent is 3, which 
is possible for RSA but rare in practice; 17 or 2^16+1 are much more common 
values. It also relies on using some rawly implemented RSA, so that all 
that is in the RSA payload is the hash, and nothing else. This violates all 
the standards that specify that the payload should be padded with stuff 
that, among other things, guarantees that even with an exponent of three, 
the answer will have exceeded the modulus and been subject to modular 
reduction. So he's talking through his hat.

Could someone help shed some light on this? Either pointing me at a paper
documenting the hole, or confirming that it's gibberish (at which point I'll
go back to work and ask him for more details :).
So, here's the attack. Suppose you have a 160-bit SHA-1 hash of some 
document, and it just happens to be a perfect cube (integer-speaking). Then 
the cube root of that hash is a valid signature independent of the modulus, 
so long as the public exponent is 3. Adding (and checking) correct padding 
(eg. OAEP or PSS, see the PKCS standards) makes it extremely unlikely that 
there will be a cube root for the attack to work on.

Others may want to correct me or elaborate further, but I think that's correct.

regards,
Greg.
Greg Rose   INTERNET: [EMAIL PROTECTED]
Qualcomm Australia  VOICE:  +61-2-9817 4188   FAX: +61-2-9817 5199
Level 3, 230 Victoria Road,http://people.qualcomm.com/ggr/
Gladesville NSW 2111232B EC8F 44C6 C853 D68F  E107 E6BF CD2F 1081 A37C
-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: A quick question...

2003-09-28 Thread Paul Walker
On Mon, Sep 29, 2003 at 08:33:59AM +1000, Greg Rose wrote:

 common values. It also relies on using some rawly implemented RSA, so that
 all that is in the RSA payload is the hash, and nothing else. This
 violates all the standards that specify that the payload should be padded

The code which implements all of this has to run in 6KB of code space, so
it's entirely possible that they hacked together their own routines to deal
with it. Almost certain, in fact - I don't think there's a compiler
available, so any library would have to be rewritten in assembler anyway.

(Sorry I can't be more precise here, but I'm sure you can appreciate why.)

[snip explanation]
 Others may want to correct me or elaborate further, but I think that's 
 correct.

It certainly makes much more sense than the scrambled version I had before,
and fits with what cryptography I already knew. I still don't think it's a
particularly *practical* attack, but I could easily be wrong there, and it
only needs one. ;-)

Many thanks for your time!

Cheers,

-- 
Paul

  I'm not sure if this is a good or a bad thing.
  Probably a bad thing;  most things are bad things.
 -- Nile Evil Bastard

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