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

2003-09-26 Thread Guus Sliepen
Hello Peter Gutmann and others,

Because of its appearance on this mailing list and the Slashdot posting
about Linux's answer to MS-PPTP, and in the tinc users' interest, we
have created a section about the current security issues in tinc, which
currently contains a response to Peter Gutmann's writeup:

http://tinc.nl.linux.org/security

I want to emphasize for the cryptography community here that certain
tradeoffs have been made between security and efficiency in tinc. So
please read the response as why we think we need to do/used to do it
this way instead of why we think tinc is still as secure as anything
else. Comments are welcome. 

-- 
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-26 Thread martin f krafft
also sprach Ian Grigg [EMAIL PROTECTED] [2003.09.25.2253 +0200]:
  I wouldn't put all of the blame on Microsoft, Schneier said,
  the problem is the monoculture.
 
 On the face of it, this is being too kind and not striking at the
 core of Microsoft's insecure OS.  For example, viruses are almost
 totally a Microsoft game, simply because most other systems aren't
 that vulnerable.

Yes and no. First, I think that viruses will surface were e.g. Linux
to take top position, albeit they may have to employ totally new
paradigms to subvert the more advanced security architecture of
UNIX.

But I believe Schneier is right for the following reason: Microsoft
is a monopolist who, despite enjoying bad press for the past four
years, is managing to keep its sales going up each quarter. If you
are in business, what do you care for? The steep sales curve, or the
quality of your product?

As long as Microsoft has the monopoly on the desktop, as long as new
computers come with Windows per default, and as long as people stop
complaining and actually take action against the crap that Redmond
ships by switching to other systems in bulk, Microsoft has no reason
to invest any money in a code rework.

 So, in the market for server platform OSs, is there any view as to
 which are more secure, and whether that insecurity can be traced
 to the OS?

The defacement archive[1] has some statistics. But don't let
yourself be fooled as one should not forget that while Windows
usually comes with one web-, one mail-, one DNS server, there are
like 27 and up in each category for UNIX. So theoretically, when
comparing those categories, you need to include a factor of 27.

  1. http://defaced.alldas.org/

-- 
martin;  (greetings from the heart of the sun.)
  \ echo mailto: !#^.*|tr * mailto:; [EMAIL PROTECTED]
 
invalid/expired pgp subkeys? use subkeys.pgp.net as keyserver!
 
women love us for our defects.
 if we have enough of them,
 they will forgive us everything,
 even our gigantic intellects.
-- oscar wilde


pgp0.pgp
Description: PGP signature


Re: Can Eve repeat?

2003-09-26 Thread Greg Troxel
  That's pretty much what I was talking about when I said that it may be
  possible to clone an arbitrarily large proportion of photons - and that
  Quantum Cryptography may not actually be secure.

A key point is the probability that the measurement/cloning operation
has of disturbing the original state.  Errors at the receiver are
assumed to be the result of eavesdropping.  The current canoncial
paper on how to calculate the number of bits that must be hashed away
due to detected eavesdropping and the inferred amount of undetected
eavesdropping is Defense frontier analysis of quantum cryptographic
systems by Slutsky et al:

  http://topaz.ucsd.edu/papers/defense.pdf

(I don't want to take a position on whether cloning is or isn't
possible - that's way out of my area of expertise!)

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


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

2003-09-26 Thread Victor . Duchovni
On Thu, 25 Sep 2003, Ian Grigg wrote:

 On the face of it, this is being too kind and not
 striking at the core of Microsoft's insecure OS.  For
 example, viruses are almost totally a Microsoft game,
 simply because most other systems aren't that vulnerable.


While part of the security problems in Windows are Microsoft specific, in
my view a large part is inherited from earlier graphiscal desktop designs,
and is almost universal in this space. Specifically, when a user clicks
(or double-clicks) on an icon there is not a clear distinction between
Run and View. Instead we have the polymorphic Open.

If files always opened in a safe viewer, (e.g. clicking on a .pl file
fired up an editor, not the ActiveState Perl interpreter) a good part of
the security problem with Graphical desktops, Microsoft's, Apple's,
RedHat's, ... would be solved. The bizarre advice we give users to not
open message attachments would be largely unnecessary (one also needs to
close the the macro invocation problem, but this is not insurmountable).

It is my contention that so long as activating an icon does not
distinguish between Run and View all Graphical Shells will be
insecure.

-- 
Victor Duchovni
IT Security,
Morgan Stanley

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


The Right Touch

2003-09-26 Thread R. A. Hettinga
http://www.forbes.com/forbes/2003/1013/050_print.html

Forbes




OutFront 
The Right Touch 
Elizabeth Corcoran, 10.13.03 


We're spending billions for new voting machines that may not be any better than punch 
cards 
Three weeks before California was set to vote on Governor Gray Davis' recall, a 
federal appeals court postponed the election because of worries about flawed 
punch-card voting systems. The technology that could replace it may not be any better. 

Touch-screen voting systems, which look like automated teller machines, are easy to 
use, but they make recounts next to impossible--because, unlike ATMs, they produce no 
independent paper trail. That worries experts who insist they can be hacked, just like 
any computer. It's very, very hard to make these machines secure, says David Dill, a 
computer science professor at Stanford who has studied computer voting. 

The companies that make the new voting systems are steaming at these accusations. 
They're suggesting something magically happens between what you see on the screen and 
what's stored in the machine,says Thomas Swidarski, president of Diebold Election 
Systems. 

Voting technology became big business following Florida's swinging-chad fiasco in 
2000. Last year Congress voted to dish out $3.8 billion to the states to upgrade 
voting booths and train poll workers. The dollars are going to a handful of firms, 
including Diebold, Sequoia Voting Systems and Election Systems  Software. Diebold, 
the $2 billion (revenues) maker of safes and automated teller machines, has placed 
47,000 voting machines, which cost as much as $3,500 apiece, in Georgia, Maryland, 
California, Virginia, Texas and Indiana. Ohio is reviewing a half-dozen bids to equip 
11,614 precincts. One-third of California voters are supposed to be using touch 
screens to vote in March (most of the rest will be optically scanned). A state 
commission is still reviewing whether to recommend adding receipts to the machines. 

Touch-screen voting machines don't have keyboards, Internet connections or even ports 
that hackers could exploit. Votes are stored in duplicate, in a removable card locked 
inside the voting machine and in built-in semiconductor memory. The only way in is 
through the smart cards handed out at the polls. The system is supposed to be 
idiot-proof--voters cannot pick too many candidates. 

But what about security? In late July Johns Hopkins computer scientist Avi D. Rubin 
released a paper criticizing computer code discovered on the Internet that was an 
excerpt of the programming in Diebold's touch-screen machines. Rubin argued the 
cryptographic protection was so poor that a hacker could easily make illegal smart 
cards and register multiple votes. The paper prompted Maryland to delay awarding a $56 
million contract for 11,000 machines to Diebold. 

Diebold countered that the code was out of date and out of context. Election workers, 
for instance, help combat fraud by taking precautions such as matching the number of 
card users to the votes registered. Diebold also issued a press release outing Rubin 
as an adviser to an Internet election technology company, VoteHere. He has since quit. 

But Diebold earned itself a black eye when its chairman, Walden O'Dell, sent a 
fundraising letter in August to Ohio Republicans, pledging that he is committed to 
helping Ohio deliver its electoral votes to the president next year. 

Accidents happen. Officials in Florida's Miami-Dade County are weighing the cost and 
benefits of retrofitting 7,200 voting machines with printers after voters there had 
trouble with touch-screen systems built by ESSfor the 2002 elections. Some voters 
reported that the machines registered a vote for a different candidate than the one 
they picked. 

Undetectable problems worry computer scientists even more. Software could shape the 
outcome of a surprise election--and we'll never know, says Dill. 



Sidebars 
Stacking The Deck 
-



-- 
-
R. A. Hettinga mailto: [EMAIL PROTECTED]
The Internet Bearer Underwriting Corporation http://www.ibuc.com/
44 Farquhar Street, Boston, MA 02131 USA
... however it may deserve respect for its usefulness and antiquity,
[predicting the end of the world] has not been found agreeable to
experience. -- Edward Gibbon, 'Decline and Fall of the Roman Empire'

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


efficiency?? vs security with symmetric crypto? (Re: Tinc's response to Linux's answer to MS-PPTP)

2003-09-26 Thread Adam Back
What conceivable trade-offs could you have to make to get acceptable
performance out of symmetric crypto encrypted+authenticated tunnel?
All ciphers you should be using are like 50MB/sec on a 1Ghz machine!!

If you look at eg cebolla (more anonymity than VPN, but it's a nested
forward-secret VPN related thing) it's even possible to do pretty
immediate forward secrecy every second or something at minimal CPU
cost.  (I'll read the writeup but that trade-off argument sounds very
wrong.)

Adam

On Fri, Sep 26, 2003 at 12:12:03PM +0200, Guus Sliepen wrote:
 Hello Peter Gutmann and others,
 
 Because of its appearance on this mailing list and the Slashdot posting
 about Linux's answer to MS-PPTP, and in the tinc users' interest, we
 have created a section about the current security issues in tinc, which
 currently contains a response to Peter Gutmann's writeup:
 
 http://tinc.nl.linux.org/security
 
 I want to emphasize for the cryptography community here that certain
 tradeoffs have been made between security and efficiency in tinc. So
 please read the response as why we think we need to do/used to do it
 this way instead of why we think tinc is still as secure as anything
 else. Comments are welcome. 
 
 -- 
 Met vriendelijke groet / with kind regards,
 Guus Sliepen [EMAIL PROTECTED]

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


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

2003-09-26 Thread Bill Frantz
At 6:47 AM -0700 9/26/03, [EMAIL PROTECTED] wrote:
While part of the security problems in Windows are Microsoft specific, in
my view a large part is inherited from earlier graphiscal desktop designs,
and is almost universal in this space. Specifically, when a user clicks
(or double-clicks) on an icon there is not a clear distinction between
Run and View. Instead we have the polymorphic Open.

If files always opened in a safe viewer, (e.g. clicking on a .pl file
fired up an editor, not the ActiveState Perl interpreter) a good part of
the security problem with Graphical desktops, Microsoft's, Apple's,
RedHat's, ... would be solved. The bizarre advice we give users to not
open message attachments would be largely unnecessary (one also needs to
close the the macro invocation problem, but this is not insurmountable).

It is my contention that so long as activating an icon does not
distinguish between Run and View all Graphical Shells will be
insecure.

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.

See:
http://www.combex.com/tech/edesk.html
http://www.combex.com/papers/darpa-review/index.html
http://www.combex.com/papers/darpa-report/index.html

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: Tinc's response to Linux's answer to MS-PPTP

2003-09-26 Thread Joseph Ashwood
And a response. I have taken the liberty of copying the various portions of
the contents of the webpage to this email for response. I apologize for the
formatting confusion which may mistake Peter Gutmann's comments with those
of the semi-anonymous misinformed person under scrutiny.

I would have CC'd the author of the response page, but it fails to mention
an author, in spite of the Comments are welcome statement at the
beginning.

 On September the 15th Peter Gutmann contacted us and showed us part of a
writeup which he
 posted to a cryptography mailing list on the 22th. In this writeup he
identifies several security issues
 in CIPE, VTun and tinc. Below we will examine his findings and explain why
some flaws or
 weaknesses Peter Gutmann found are in fact not a problem at all for a VPN
daemon like tinc.
 As a reader you are ultimately left to draw your own conclusions, I
encourage you to read all the
 arguments from both sides and, if possible, verify them by reading the
documentation and source
 code of tinc. Comments are welcome.

 Predictable IV
Proposed solution: provide the option of a full IV and move the sequence
number out of the ciphertext, note that this is an _option_, instead of the
necessary for security always.

 Truncated MAC
 tinc will continue to use only the first 32 bits by default.
Simply put this is unacceptable from a security standpoint. The view taken
is that the extra 128 bits represents a significant overhead in the
communication. So I did the math, sending the extra 128 bits over a 52kbs
would take 0.002 seconds, and over a T1 the time cost is an absolutely
enormous 0.8 seconds. The other consideration is the potentially the
computation time argument, but SHA-1 is used regardless, the computation
time is identical. There is no justification in even a dialup environment
for not using the full HMAC.

 Use of RSA
 Tinc uses RSA encryption only once, during authentication.
sarcasm Yeah authentication is such a minor thing that major flaws are
completely aceptable./sarcasm

 A message is sent which has the same length as the RSA key, and is
 completely filled . . .using real random data (OpenSSL's RAND_bytes()).

I really wish people would actually read documentation *before* making
stupid claims like this, in fact to quote the OpenSSL docs These functions
implement a cryptographically secure pseudo-random number generator (PRNG).
 Any claim that OpenSSL implements a real random number generator are
completely false.

 So, the message does not have low entropy and doesn't contain predictable
 bits.

Read the docs, the message has 0 entropy (actually marginally above 0, but
these are simple rounding errors), that's what a pseudo-random number
generator means.

 However, there is no guarantee that the message was encrypted using the
 correct public key or that noone has tampered with it. This is of no
concern
 for tinc though.

There goes that authentication doesn't matter problem again, remind is tinc
supposed to have any sembalnce of security? or is it just a stupid toy
designed for young children to keep they're even younger siblings out of
their personal matters?

 Part of the message is used as the key for the symmetric cipher that is
used
 by the sender of this key to encrypt the rest of the messages it will
send. A
 challenge-response exchange right after exchanging the RSA encrypted
 messages is done to ensure that both the sender of the symmetric cipher
key
 has the right public key, the recipient has the right corresponding
private
 key, and the message was not tampered with (because that would change the
 symmetric cipher key).

Whoever designed and stated this has no idea about cryptographic security.
Using a part of a shared secret, generated by a pRNG on only one side,
introduces horrific flaws in the protocol. Pretending that poorly done RSA
encryption magically solves the problem will only risk everything that has
ever been encrypted using tinc.

 Authentication protocol
 First of all, we assume Mallet does not know the private keys of Bob and
 Alice (Bob and Alice are not compromised), and Bob and Alice do not know
 Mallet at all (they don't trust Mallet, otherwise he could've made a
 connection without having to resort to a cryptographic attack).
Good luck keeping that assumption true, with the oracle attack listed above
that won't stay true very long at all.

 First, keys for the
 symmetric cipher encryption are exchanged. Mallet cannot decrypt keys he
 gets from Bob and Alice, because he doesn't have their private keys.
But he does, he spoofed each connection and acted as initiator for both, now
it's a simple matter of resending. Your entire model is based on a
misunderstanding of what RSA does and does not offer.

What you're missing is that the connection iniator sets all the keys and can
determine all the keys (assuming the uncontested simplified message flow is
correct). Mallet can very easily perform a complete man-in-the-middle attack

 Configuration

Re: A different Business Model for PKI (was two other subjects related to the demise of Baltimore)

2003-09-26 Thread Peter Gutmann
Ed Reed [EMAIL PROTECTED] writes:

2) PKI vendors looked at that and must have said - gee, if we can get
$100-$150/yr/user for managing identity around PKI certificates, why
shouldn't we?  

Actually it's even better than that, the companies using the managed service
are still expected to act as the RA (registration authority) for certs, so
they do all the hard work (verifying users, etc etc).  Verisign just give them
access to a cert-management engine and collect the fees (OK, there's a bit
more work to it than that, but still, the Verisign beancounters must be like
pigs in clover over it).

3) the standards groups, PKIX in particular, still haven't addressed the cert
life cycle management issues, and neither has the market place, in any
coherent, interoperable fashion 

That's my perpetual gripe with PKIX, they're frantically busy distracting
themselves with interesting (to them) but ultimately pointless and irrelevant
additional standardisation of features so obscure that you need 15 pages of
diagrams just to explain to users why they might be useful, while ignoring the
fact that most people can't use even the most rudimentary parts of what's
already there.  This is presumably why the IETF finally shut them down, they
realised they'd just keep endlessly churning out RFCs until the sun goes out
(I'm not sure whether just leaving them alone to do that in perpetuity
wouldn't have been the better option).

After some research, it appears to me that there's a tidy little business
possible for someone to break the mold.

Can't be done.  SPKI tried it, designing an eminently workable PKI (for the
task they were trying to solve) and no-one was interested because it wasn't
X.509.  Certainly if you throw out all the X.500 baggage that we know doesn't
work (X.500 DNs, directories, CRLs, etc etc, which is what SPKI did) you can
build a very workable, usable, scalable PKI, but OSI digital ancestor-worship
requirements say that you're not allowed to do that.

Anyone care to make a go of it? 

Please, go ahead.  I'll stand over here and watch.

It's a vicious circle, X.509 doesn't work/doesn't do what people want, but
anything that does work isn't X.509 and therefore won't be accepted by the
market.  SPKI was a heroic effort to break out of the cycle, but despite a lot
of work and input from some very clever people, it ultimately failed for that
reason.  And unlike the OSI experience in the 1980s (which X.509 is a direct
repeat of), for PKI there isn't any DARPA-spawned white knight to come in and
fix things when it fails.

To some extent this is computer darwinism in action.  With networking
protocols, some alternative to OSI (that is, a relatively functional set of
networking protocols) had to evolve at some point, because computers had to
communicate somehow.  There was intense market pressure to get something that
worked, and eventually it was the IP protocol suite.  With PKI on the other
hand no such pressure exists, since it's pretty much irrelevant for most
people.  Sure, your marketing folks can come up with all sorts of neat
hypothetical scenarios where PKI would make things so much better, but in
reality people and companies can do their banking, tax filing, buying and
selling, share trading, and every other use that might justify a PKI,
perfectly well without it.  As a result there's no pressure on the people
involved in PKI standardisation to create anything that meets any real-world
requirement, allowing them instead to spend their time building great gothic
cathedrals of infinite complexity whose sole purpose seems to be to strike awe
and terror into the masses.

What's left to vendors is a few niche markets, generally the same groups who
are still trying to make a go of using X.400 (government departments/the
military, a few large corporates, a few banks) who will keep struggling with
X.509 for a number of years.  That's a pretty small market to peddle your
wares into, as companies like Baltimore, Entrust, and a number of other PKI
vendors have found out.

Peter (who probably now officially qualifies as a PKI curmudgeon).

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