Re: link-layer encryptors for Ethernet?

[Chris Kuethe]

http://www.gdds.com/company/portfolio.html#ias
http://www.gdc4s.com/Products/sectera.htm

Maybe one of these nifty looking  general dynamics widgets is what you're after?

-- 
GDB has a 'break' feature; why doesn't it have 'fix' too?

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

Re: A cool demo of how to spoof sites (also shows how TrustBar preventsthis...)

[Adam Shostack]

On Wed, Feb 09, 2005 at 07:22:05PM +, Ian G wrote:
| Adam Shostack wrote:
| 
| >Have you run end-user testing to demonstrate the user-acceptability of
| >Trustbar?
| > 
| >
| 
| Yes, this was asked over on the cap-talk list.
| Below is what I posted there.  I'm somewhat
| sympathetic as doing a real field trial which
| involves testing real responses to a browser
| attack raises all sorts of heisenberg uncertainty /
| experimental method issues.  Off the top of
| my head, I think this is a really tricky problem,
| and if anyone knows how to test security
| breaches on ordinary users, shout!

There's an HCIsec group at YahooGroups: 

http://groups.yahoo.com/group/hcisec/

Most of the smart people who care about these issues hang out there.  

Adam

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

Re: A cool demo of how to spoof sites (also shows how TrustBar preventsthis...)

[Ian G]

Taral wrote:
On Wed, Feb 09, 2005 at 07:41:36PM +0200, Amir Herzberg wrote:
 

Why should I trust you? Filtering xn--* domains works for me, and
doesn't require that I turn my browser over to unreviewed, possibly
buggy code.
 

I understand this is a theoretical question, but
here is an answer:
The plugin is downloadable from a MozDev site,
and presumably if enough attention warrants it,
Amir can go to the extent of signing it with a
cert in Mozilla's code signing regime.
Also, as Amir is a relatively well known name in
the world of crypto I suppose you could consider
his incentives to be more aligned with delivering
good code than code that would do you damage.
iang
--
News and views on what matters in finance+crypto:
   http://financialcryptography.com/
-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: A cool demo of how to spoof sites (also shows how TrustBar preventsthis...)

[Taral]

On Wed, Feb 09, 2005 at 07:41:36PM +0200, Amir Herzberg wrote:
> Want to protect your Mozilla/FireFox from such attacks? Install our 
> TrustBar: http://TrustBar.Mozdev.org
> (this was the first time that I had a real reason to click the `I don't 
> trust this authority` button...)
> 
> Opinions?

Why should I trust you? Filtering xn--* domains works for me, and
doesn't require that I turn my browser over to unreviewed, possibly
buggy code.

-- 
Taral <[EMAIL PROTECTED]>
This message is digitally signed. Please PGP encrypt mail to me.
A: Because it fouls the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?


pgpD70vfE5JMp.pgp
Description: PGP signature

Re: A cool demo of how to spoof sites (also shows how TrustBar preventsthis...)

[Ian G]

Adam Shostack wrote:
Have you run end-user testing to demonstrate the user-acceptability of
Trustbar?
 

Yes, this was asked over on the cap-talk list.
Below is what I posted there.  I'm somewhat
sympathetic as doing a real field trial which
involves testing real responses to a browser
attack raises all sorts of heisenberg uncertainty /
experimental method issues.  Off the top of
my head, I think this is a really tricky problem,
and if anyone knows how to test security
breaches on ordinary users, shout!
Ka-Ping Yee wrote:
1. TrustBar: Protecting (even Naive) Web Users from Spoofing and
Phishing Attacks, Amir Herzberg and Ahmad Gbara
http://www.cs.biu.ac.il/~herzbea//Papers/ecommerce/spoofing.htm
  

I've read that paper.  What they did is not a user study at all;
it was merely a questionnaire.  It's certainly better than nothing,
but it is not a user study.  For the results to be applicable, the
tests should take place while users are actually interacting with
a browser normally.
 

I agree it wasn't much.  But it was a bit more than
just a multiple choice:
 "The second goal of the third question was to evaluate whether the use 
of TrustBar is likely to improve the ability of users to discern between 
unprotected sites, protected sites and spoofed (fake) sites. For this 
purpose, we gave users a very brief explanation on the TrustBar security 
indicators, and then presented three additional screen shots, this time 
using a browser equipped with TrustBar. Again, the screen shots are 
presented in Appendix B, and each was presented for 10 to 15 seconds, 
taken using Mozilla in the Amazon web site. We leave it as a simple 
exercise to the reader to identify the protected, unprotected and 
spoofed (fake) among these three screen shots.

 "The results provide positive indication supporting out belief that 
the use of TrustBar improves the ability of (naïve) web users to discern 
between protected, unprotected and fake sites. Specifically, the number 
of user that correctly identified each of the three sites essentially 
doubled (to 21, 22 and 29).

That would rate as a simulation rather than
a field trial, I guess.
--
iang
--
News and views on what matters in finance+crypto:
   http://financialcryptography.com/
-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: A cool demo of how to spoof sites (also shows how TrustBar preventsthis...)

[Steven M. Bellovin]

In message <[EMAIL PROTECTED]>, Amir Herzberg writes:
>Want to see a simple, working method to spoof sites, fooling 
>Mozilla/FireFox/... , even with an SSL certificate and `lock`?
>
>http://www.shmoo.com/idn/
>
>  See also:
>
>   http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=3866526512
>
>Want to protect your Mozilla/FireFox from such attacks? Install our 
>TrustBar: http://TrustBar.Mozdev.org
>(this was the first time that I had a real reason to click the `I don't 
>trust this authority` button...)
>

Actually, both Trustbar and checking the certificate are "working" 
because the code isn't right yet -- those sections of code (in Firefox) 
don't understand IDN yet, and they need to.  Sure, they're catching a 
problem here, but they're catching the problem for those network users 
who are expecting and reading ASCII characters.  But think of, say, the 
Japanese user who would like to see that the certificate really was 
issued to , and instead sees the IDN encoding?  
That's less than helpful -- he or she would have no way whatsoever of 
verifying the certificate.

--Prof. Steven M. Bellovin, http://www.cs.columbia.edu/~smb



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

Re: A cool demo of how to spoof sites (also shows how TrustBar preventsthis...)

[Adam Shostack]

On Wed, Feb 09, 2005 at 07:41:36PM +0200, Amir Herzberg wrote:
| Want to see a simple, working method to spoof sites, fooling 
| Mozilla/FireFox/... , even with an SSL certificate and `lock`?
| 
| http://www.shmoo.com/idn/
| 
|  See also:
| 
|   http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=3866526512
| 
| Want to protect your Mozilla/FireFox from such attacks? Install our 
| TrustBar: http://TrustBar.Mozdev.org
| (this was the first time that I had a real reason to click the `I don't 
| trust this authority` button...)
| 
| Opinions?

Just because you can demonstrate that you're pre-emptively and
pro-actively blocking attacks that the beat the current system doesn't
mean 

I can't go on.  My head would explode.

Have you run end-user testing to demonstrate the user-acceptability of
Trustbar?

Adam



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

Re: A cool demo of how to spoof sites (also shows how TrustBar preventsthis...)

[SK]

How can Trustbar help me if the site in question is not even SSL
based.  Homograph based attacks are imo a different class of its own.

SK


On Wed, 09 Feb 2005 19:41:36 +0200, Amir Herzberg
<[EMAIL PROTECTED]> wrote:
> Want to see a simple, working method to spoof sites, fooling
> Mozilla/FireFox/... , even with an SSL certificate and `lock`?
> 
> http://www.shmoo.com/idn/
> 
>   See also:
> 
>http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=3866526512
> 
> Want to protect your Mozilla/FireFox from such attacks? Install our
> TrustBar: http://TrustBar.Mozdev.org
> (this was the first time that I had a real reason to click the `I don't
> trust this authority` button...)
> 
> Opinions?
> 
> Best, Amir Herzberg

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

A cool demo of how to spoof sites (also shows how TrustBar preventsthis...)

[Amir Herzberg]

Want to see a simple, working method to spoof sites, fooling 
Mozilla/FireFox/... , even with an SSL certificate and `lock`?

http://www.shmoo.com/idn/
 See also:
  http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=3866526512
Want to protect your Mozilla/FireFox from such attacks? Install our 
TrustBar: http://TrustBar.Mozdev.org
(this was the first time that I had a real reason to click the `I don't 
trust this authority` button...)

Opinions?
Best, Amir Herzberg
-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: link-layer encryptors for Ethernet?

[Anne & Lynn Wheeler]

Steven M. Bellovin wrote:
Yup.  Often, large corporations had policies requiring them, because of 
how frequently a transoceanic fiber would be cut and the circuits 
rerouted to satellite.
how 'bout microwave terrestrial ... remember all the press about the 
consulate in san fran that supposedly had clear shot at the mci 
microwave antenna complex?

san jose south valley complex had T3 collins digital radio between the 
main plant site (roof of bldg. 12) and stl/bldg.90. i've heard comments 
from people driving the stretch of 87 having their radar detectors go 
off when they are in the straight line between bldg. 12 and the 
repeating tower on top of the hill going to bldg.90.

a similar setup went to the lsg/bldg.29 (los gatos lab) ... with a 
repeating tower on the hill above san jose dump.

my hsdt project had some of the circuits
http://www.garlic.com/~lynn/subnetwork.html#hsdt
and also put in a tdma system that ran off a transponder on sbs4. had 
4.5meter dish in the back parking lot of bldg.29 with tail circuits to 
the main plant site, a 4.5meter dish out behind yorktown research, and a 
7meter dish on the austin plant site.

i got tired of paying all the money for the link encrypters ... and got 
involved in designing a board that was a lot more powerful and orders of 
magnitude cheaper ... which caused some churn.

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

Re: link-layer encryptors for Ethernet?

[John Denker]

Steven M. Bellovin wrote:
Are there any commercial link-layer encryptors for Ethernet available?  
I know that Xerox used to make them, way back when, but are there any 
current ones, able to deal with current speeds (and connectors)?
Several people have made suggestions involving IPsec,
which were not immediately accepted.
Let me try to kick the discussion downfield a little ways.
I don't know what application Steve has in mind, but
there exists a wide range of applications for which I
would seriously consider the following approach:
  GRE over IPsec transport.
This would not in the narrowest sense be encrypting the
layer-2 traffic, but it would look like that to the
applications.
To say the same thing in more detail:  As you know, the
IPsec RFC covers two main subjects:
 A) the layout of the packets, and
 B) the SPDB (security policy database)
If we temporarily neglect part (B), to a decent approximation
we can describe IPsec tunnel mode in terms of IPsec transport
mode, as follows:
  IPIP over IPsec transport.
The analogy to GRE over IPsec transport should now be clear.
You can call it GREsec or L2sec.
The SPDB issues can now be stirred back in.  In the
implementation of IPsec that I am most famililar with
(OpenS/WAN, descended from FreeS/WAN) the SPDB was
  a) never 100% implemented, but
  b) what was implemented was pretty much orthogonal
   to the packet-formatting business,
so you don't AFAICT lose anything important by using GRE
instead of IPIP encapsulation.
=
I would argue that for most applications, GREsec is better
than genuine strict link-layer encryption, because it
can, if you want, be transported across routers, whereas
anything at the genuine link layer cannot.
I realize that there remain some issues that I have not
addressed, notably processes that live in the gray area
between layer two and layer three, such as arp, dhcp,
and neighbor discovery.
=
If this is barking up the wrong tree, please explain why.
Please tell us the real requirements in more detail.
-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: link-layer encryptors for Ethernet?

[Steven M. Bellovin]

In message <[EMAIL PROTECTED]>, Anne & Lynn Wheeler writes:
>the internal network was larger than the arpanet/internet just about the 
>whole time up until about mid-85. all the links leaving physical premise 
>had to be encrypted ... there was the claim that over half of all 
>encrypters in the world were on the internal network (and put at least 
>one of the major products/companies into business). lots of random 
>comments about about the internal network
>http://www.garlic.com/~lynn/subtopic.html#internalnet
>
>small sample posting about the internal net passing 1000 nodes not long 
>after internet passed 255 nodes.
>http://www.garlic.com/~lynn/internet.htm#22
>
>one of the big issues in part of this period was getting encrypters on 
>links that cross national boundaries.
>

Yup.  Often, large corporations had policies requiring them, because of 
how frequently a transoceanic fiber would be cut and the circuits 
rerouted to satellite.

--Prof. Steven M. Bellovin, http://www.cs.columbia.edu/~smb



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

Re: link-layer encryptors for Ethernet?

[Anne & Lynn Wheeler]

the internal network was larger than the arpanet/internet just about the 
whole time up until about mid-85. all the links leaving physical premise 
had to be encrypted ... there was the claim that over half of all 
encrypters in the world were on the internal network (and put at least 
one of the major products/companies into business). lots of random 
comments about about the internal network
http://www.garlic.com/~lynn/subtopic.html#internalnet

small sample posting about the internal net passing 1000 nodes not long 
after internet passed 255 nodes.
http://www.garlic.com/~lynn/internet.htm#22

one of the big issues in part of this period was getting encrypters on 
links that cross national boundaries.

Joseph Tardo wrote:
DEC used to make one (the DESNC), I don't remember the Xerox product. 
Cylink used to make one, and may even still (as Safe-Net).

FWIW, IEEE has working group 802.1ae doing Ethernet MAC layer 
encryption. But then, they had 802.10 (only implementation I know of was 
the DESNC) for many years before retiring it.

The market for these kinds of devices has been notoriously small. May I 
ask what your use case is?

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

Tester claims 90% of VPNs open to hackers

[R.A. Hettinga]

Printed from ComputerWeekly.com

IT Management: Security

by Antony Savvas
Tuesday 8 February 2005
Tester claims 90% of VPNs open to hackers
Security testing company NTA Monitor has claimed that 90% of virtual
private networks are open to hackers.

 Over a three-year period of testing VPNs at large companies, NTA Monitor
said 90% of remote access VPN systems have exploitable vulnerabilities,
even though many companies, including financial institutions, have in-house
security teams.

 Flaws include "user name enumeration vulnerabilities" that allow user
names to be guessed through a dictionary attack because they respond
differently to valid and invalid user names.

 Roy Hills, NTA Monitor technical director, said, "One of the basic
requirements of a user name/password authentication is that an incorrect
log-in attempt should not leak information as to whether the user name or
password is incorrect. However, many VPN implementations ignore this rule."

 The fact that VPN user names are often based on people's names or e-mail
addresses makes it relatively easy for an attacker to use a dictionary
attack to recover a number of valid user names in a short period of time,
said Hills.

 Passwords can also be made harder to crack by deploying a mixture of
characters and numbers. Hills said a six-character password can be cracked
in about 16 minutes using standard "brute force" cracking software.
However, a six-character password combining letters and numbers could take
two days to crack.


-- 
-
R. A. Hettinga 
The Internet Bearer Underwriting Corporation 
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]

Hold the Phone, VOIP Isn't Safe

[R.A. Hettinga]

Wired News


Hold the Phone, VOIP Isn't Safe 
By Elizabeth Biddlecombe?

Story location: http://www.wired.com/news/technology/0,1282,66512,00.html

02:00 AM Feb. 07, 2005 PT

In recognition of the fact that new technologies are just as valuable to
wrongdoers as to those in the right, a new industry group has formed to
look at the security threats inherent in voice over internet protocol.

 The VOIP Security Alliance, or VOIPSA, launches on Monday. So far, 22
entities, including security experts, researchers, operators and equipment
vendors, have signed up. They range from equipment vendor Siemens and phone
company Qwest to research organization The SANS Institute.


 They aim to counteract a range of potential security risks in the practice
of sending voice as data packets, as well as educate users as they buy and
use VOIP equipment. An e-mail mailing list and working groups will enable
discussion and collaboration on VOIP testing tools.

 VOIP services have attracted few specific attacks so far, largely because
the relatively small number of VOIP users doesn't make them a worthwhile
target. (A report from Point Topic in December counted 5 million VOIP users
worldwide.)

 But security researchers have found vulnerabilities in the various
protocols used to enable VOIP. For instance, CERT has issued alerts
regarding multiple weaknesses with SIP (session initiation protocol) and
with H.323.

 Over the past year, experts have repeatedly warned that VOIP abuse is
inevitable. The National Institute of Standards and Technology put out a
report last month urging federal agencies and businesses to consider the
complex security issues often overlooked when considering a move to VOIP.
NIST is a member of VOIPSA.

 "It is really just a matter of time before it is as widespread as e-mail
spam," said Michael Osterman, president of Osterman Research.

 Spammers have already embraced "spim" (spam over instant messaging), say
the experts. Dr. Paul Judge, chief technology officer at
messaging-protection company CipherTrust, says 10 percent of
instant-messaging traffic is spam, with just 10 to 15 percent of its
corporate clients using IM. "It is where e-mail was two and a half years
ago," said Judge.

 To put that in perspective, according to another messaging-protection
company, FrontBridge Technologies, 17 percent of e-mail was spam in January
2002. It put that figure at 93 percent in November 2004.

 So the inference is that "spit" (spam over internet telephony) is just
around the corner. Certainly, the ability to send out telemarketing
voicemail messages with the same ease as blanket e-mails makes for
appealing economics.

 Aside from the annoyance this will cause, the strain on network resources
when millions of 100-KB voicemail messages are transmitted, compared with
5- or 10-KB e-mails, will be considerable.

 But the threat shouldn't be couched solely within the context of unlawful
marketing practices. Users might also see the audio equivalent of phishing,
in which criminals leave voicemails pretending to be from a bank, said
Osbourne Shaw, whose role as president of ICG, an electronic forensics
company, has led him to try buying some of the goods advertised in spam.

 In fact, according to David Endler, chairman of the VOIP Security Alliance
and director of digital vaccines at network-intrusion company TippingPoint,
there are many ways to attack a VOIP system. First, VOIP inherits the same
problems that affect IP networks themselves: Hackers can launch distributed
denial of service attacks, which congest the network with illegitimate
traffic. This prevents e-mails, file transfers, web-page requests and,
increasingly, voice calls from getting through. Voice traffic has its own
sensitivities, which mean the user experience can easily be degraded past
the point of usability.

 Furthermore, additional nodes of the network can be attacked with VOIP: IP
phones, broadband modems and network equipment, such as soft switches,
signaling gateways and media gateways.

 Endler paints a picture in which an attack on a VOIP service could mean
people would eavesdrop on conversations, interfere with audio streams, or
disconnect, reroute or even answer other people's phone calls. This is a
concern to the increasing number of call centers that put both their voice
and data traffic on a single IP network. It is even more of a concern for
911 call centers.

 But Louis Mamakos, chief technology officer at broadband telephony
provider Vonage, says he and his team "spend a lot of time worrying about
security" but the problems the company has seen so far have centered on
"more pedestrian" threats like identity theft.

 Vonage has not yet signed up for the VOIP Security Alliance, said Mamakos,
and employees already spend a lot of time working on security issues with
technology providers.

 "I'm not sure if (VOIPSA) is a solution to a problem we don't have yet,"
he said. "We need to judg

Re: Can you help develop crypto anti-spoofing/phishing tool ?

[Jerrold Leichter]

| Jerrold Leichter wrote:
| > "N-version programming" - which is what you are proposing here - can
| > increase
| > your level of trust against random errors[2], but its of no use at all
| > against
| > a deliberate attack. 
| 
| I heartly disagree. If the N-outputs are continuously verified for
| coherence, any difference readily stands out. The number N and the cost of
| always using those N-outputs should, of course, be outweighed against the
| cost of failure to detect an attack. Theoretically, however, there is always
| a finite number N that can make the probability of such an attack _ as small
| as you please_.
| 
| The mathematical basis for this result was proven by Shannon more than 50
| years ago; the practical intuition for this result was demonstrated during
| the Mogul period in India (more than 500 years ago), who are known to have
| used at least three parallel reporting channels to survey their provinces
| with some degree of reliability, notwithstanding the additional efforts to
| do so.
All you've again proved is that you're misapplying the results.

Consider again the attack we are discussing:  There is one very particular
"magic" input that produces special, pre-determined results.  In the case of
the ACM paper, a particular input program produces slightly different code.
But let's take a simpler example:  A password-checking program that has a
magic passcode that, when entered, is always accepted.

Since you weren't clear how you were going to use your N versions, let's try
two models:

- You use your N versions for some huge number of rounds of testing,
making sure they all produce the same result.  (Let's use the
password checker, since it that case "same result" is easy to
determine.)  The chance of your ever trying the single magic
password is obviously vanishingly small.  N is irrelevant.

  This is the model you *seemed* to be talking about, but perhaps not.

- You use all N versions together in production, and watch for any
errors.  For the password application, that actually does
work - though any value of N > 2 requires a rather bizarre
threat model involving multiple coordinated attackers.  It's
hard to come up with any real-world situation in which you
are concerned about up to, say, 10 people conspiring together
against you but you can be certain that no 11 people will
conspire.

If we do indeed assume the second model, things get more difficult for the 
compiler.  What do you verify?  The object code from the N compilers all 
differ.  You can't verify anything useful at that level.  Maybe you have some 
kind of symbolic execution environment, and get use it for checking.  Do you 
trust *it*?  What compiler was *it* built with?  In practice, you have to keep 
the N versions of each of your input programs all compiled by the N different 
compilers running in parallel forever, and compare their outputs.  (And 
how many different linkers do you have?  Run-time loader?  Presumably you 
don't keep around N^2 or N^3 or N^4 versions - somehow you pick a representa-
tive set.  How?  Doesn't sound easy, against an intelligent attack.)

Anyway, suppose you've chosen your redundant set and can afford to run all the 
copies indefinitely.  For something like a password checker, you have Boolean 
outputs and can easily compare.  But let's try something more complex, say an 
implementation of a signature algorithm like DSA.  You have N different 
versions which have to be different "all the way down" - including their 
random number generators.  No two of your programs *ever* produce the same 
output for identical inputs.  What will you compare?  What does it mean to say 
that one of them produced an "incorrect" result?

| > (Recall the conversation here a couple of months ago
| > about how difficult - to the point of impossibility - it would be to use
| > external testing to determine if a crypto-chip had been "spiked".)
| 
| Aren't we talking about different things? A covert channel, looking at
| the crypto-chip by itself, is demonstrably impossible to detect with
| certainty. However, what I was talking about is NOT this situation.
| You are looking at *one* crypto-chip, a single source of information, a single
| trusted source, when you have no correction channel available.  I am
| looking at N outputs, N sources of information (each one as independent as
| possible but not necessarily 100% independent). You have no reference for
| detecting a "spike", I have N-1.
As noted above, if randomization is used, the "spike" might be there but not
be detectable even in principle.

Even without randomization, many programs can produce all kinds of 
"equivalent" outputs.  Compilers producing different by "acts the same" object 
are an expected example - but see Les Hatton's classic paper on errors

Group Aims to Make Internet Phone Service Secure

[R.A. Hettinga]

The Wall Street Journal

  February 9, 2005

 TELECOMMUNICATIONS


Group Aims to Make
 Internet Phone Service Secure
Alliance of Tech Companies Looks for Ways
 To Head Off Attacks by Hackers, Viruses

By RIVA RICHMOND
DOW JONES NEWSWIRES
February 9, 2005; Page D4


A group of more than 20 technology companies and computer-security
organizations has gone on the offensive to protect the burgeoning Internet
telephone service from hackers, viruses and other security problems.

The VOIP Security Alliance, which was announced earlier this week, will
focus on uncovering security problems and promoting ways to reduce the risk
of attack for voice over Internet protocol, or VOIP, technology.

The group, known as VOIPSA, includes companies such as 3Com Corp., Alcatel
SA, Avaya Inc., Siemens AG, Symantec Corp. and Ernst & Young LLP. Other
members include the National Institute of Standards and Technology, a
federal government agency; the SANS Institute, a research organization for
network administrators and computer-security professionals; and several
universities.

The group's goal is to help make VOIP as secure and reliable as traditional
telephone service. VOIP breaks voice into digital information and moves it
over the Internet. That can make phone service much cheaper, but it also
opens the door to the kind of security woes that have come to plague the
Internet.

VOIP enthusiasts worry that security and privacy problems could hamper
adoption of the technology.

"VOIP has a lot of great value propositions, but in order for it to be
successful, it has to be secured" and offer service quality that's on par
with the current phone system, said David Endler, chairman of the alliance
and an executive at TippingPoint, a security company that recently was
acquired by 3Com. "VOIPSA is a first step in doing that."

Internet telephone service is expected to be rolled out rapidly to
consumers and business customers, starting this year. Mr. Endler said many
network operators don't realize they need to alter their security
strategies when they add Internet phone service. For instance, traditional
firewalls cannot police VOIP traffic, he said, and so networks will need to
be upgraded with newer security technologies.

There's little understanding of what security problems VOIP might introduce
and what kind of defensive measures need to be taken. VOIPSA intends to
improve that situation by sponsoring research, uncovering vulnerabilities,
disseminating information about threats and security measures, and
providing open-source tools to test network-security levels.

Because VOIP will be dependent on the Internet, there's little hope that
security troubles can be avoided, said Alan Paller, director of research at
the SANS Institute, though early action by technology makers to address
problems is positive and welcome. "It's not a lightweight problem," he
said. "How well would you do with no phone?" If Internet attacks can
disrupt phone service, "you radically expand the number of victims," he
said.

"VOIP networks really inherit the same cyber-security threats that data
networks are today prone to, but those threats take greater severity in
some cases," Mr. Endler said.

For instance, a life-or-death emergency call to 911 might not get through
if a network is crippled by a hacker attack. Worse, a broad assault on the
phone system could become a national security crisis that causes economic
damage.


-- 
-
R. A. Hettinga 
The Internet Bearer Underwriting Corporation 
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]

RE: Canonical LAN Manager hash algorithm specification?

[Xunhua Wang]

Check http://davenport.sourceforge.net/ntlm.html 

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:owner-
> [EMAIL PROTECTED] On Behalf Of Dan Moniz
> Sent: Tuesday, February 08, 2005 8:38 PM
> To: cryptography@metzdowd.com
> Subject: Canonical LAN Manager hash algorithm specification?
> 
> Hi all,
> 
> Sorry to spam the list like this, but I was wondering if anyone had
> pointers to the canonical references for the various versions of the LAN
> Manager protocols and their respective hash algorithms. I've just
> re-read through RFCs 1994, 2433, and 2759 but have thus far been unable
> to find "the" specification for LAN Manager hash algorithms as used in
> the different revisions of the protocol.
> 
> Any pointers would be much appreciated.
> 
> 
> --
> Dan Moniz <[EMAIL PROTECTED]> [http://www.pobox.com/~dnm/]
> 
> 
> -
> The Cryptography Mailing List
> Unsubscribe by sending "unsubscribe cryptography" to
> [EMAIL PROTECTED]


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

TrustBar: an open-source crypto anti-spoofing/phishing toolbar forFireFox

[Amir Herzberg]

Ed Gerck (responded to me)^2:

 Can you trust what trustbar shows you? 
This trust translates to:
-- Trusting the TrustBar code (which is open source so can be 
validated by tech-savvy users / sys-admin)
-- Trusting that this code was not modified (same as for any other 
aspect of your machine)
-- Trusting the CA - well, not exactly; TrustBar allows users to 
... ...
In other words, if trustbar can be verified it can be trusted.
This is one method of verifying, but probably not very useful for naive 
users... Instead, such users would base their trust on trusted 
evaluations of TrustBar by independant experts (like, hopefully, people 
on this list), or by receiving TrustBar from someone they trust (e.g. 
when Mozilla or Microsoft or other reputable company provide TrustBar 
functionality in the browser).
Redundancy is useful to qualify trust in information. Trusting the trustbar
code might be hard to qualify by itself (ie, source code verification) but
redundancy helps here [1]. Trust increases if the two channels trustbar and
browser CA status [2] agree with each other. Trustbar can become a trusted
verifier after positively checking with the browser CA status.
I think the most useful redundency here is the availability of 
_multiple_ (redundant) reviews of the code by independant experts.
..
[1] This is also my solution to the famous trust paradox proposed by Ken
Thompson in his " Reflections of Trusting Trust". Trust is earned, not
given. To trust Ken's code, I would first ask two or more programmers (who
I choose) to code the same function and submit their codes to tests. If 
they
provide the same answers for a series of inputs, including random inputs,
I would have a qualification for trusting (or not) Ken's code. This works
even without source code. Trust is not in the thing, it's how the thing 
works.
Unfortunately, this test is neither feasible nor secure.
It is not feasible since you assume that the programs implement a 
(deterministic) function, while in reality programs are (usually) 
non-deterministic and often are also interactive processes (not a single 
function from input to output).

It is insecure since a program can fail only on a negligibly small 
fraction of the inputs, which will be invoked by the attacker. Namely, 
even if the programs are supposed to simply implement a (deterministic) 
function, e.g. AES_k(m), a rogue implementation could output AES_k(m) 
for all m except a special input e.g. "trapdoor", and output k when 
given m="trapdoor". The probability that your test will include the 
string "trapdoor" is negligible. QED
[2] Mozilla already shows the signing CA name when the mouse is over the 
lock symbol in SSL. This is more readily visible than clicking with the 
right-button and reading the cert.
This is very good; I don't know if this change was motivated to any 
extent by TrustBar, but clearly our goals is exactly to introduce 
sufficiently secure solution into the browsers.

Unfortunately, our usability surveys provide clear evidence, that these 
improvements are still not enough to protect (most/naive) users... In 
fact, I doubt that many users are even aware of this feature and/or of 
what it means. Furthermore, currently, this information - as other info 
displayed by browsers - can be spoofed in different ways, as explained 
in our paper and in some of the previous works we cite.

Best, Amir Herzberg
-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: link-layer encryptors for Ethernet?

[james hughes]

This is not _just_ an IPsec box. They also have a protocol that  
predates IPsec. This was presented to the "then forming" IPsec group in  
1994 but it was passed over.

From the admin guide at:
	http://blueridgenetworks.com/support/pdf/ 
VPNRemote%20AccessAdminGuide.pdf

Blue Ridge VPN uses a recognized approach to network connectivity  
called Layer 2 Tunneling. This general technique
is used by sophisticated network switching gear such as VLAN products  
and Layer 2 switches to make one physical
“Ethernet” logically appear to be composed of desktops, servers, and  
office LAN’s that may physically be in separate
locations.
I believe they do use protocol 50 (even though they are not IPSEC).

On Feb 8, 2005, at 7:36 PM, Steven M. Bellovin wrote:
In message <[EMAIL PROTECTED]>, james hughes  
writes:
The following device is a layer 2 tunneling device that has 256 bit  
AES
at up to 400Mb/s.

http://blueridgenetworks.com/products/index.htm
http://blueridgenetworks.com/support/borderguard_vpn__serv_res_ctr.htm
Layer 2?  It seems to be an IPsec box.  At the least, their
Administrator's Guide talks about using IP Protocol 50.
--Prof. Steven M. Bellovin, http://www.cs.columbia.edu/~smb


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

Re: link-layer encryptors for Ethernet?

[Joseph Tardo]

DEC used to make one (the DESNC), I don't remember the Xerox product. 
Cylink used to make one, and may even still (as Safe-Net).

FWIW, IEEE has working group 802.1ae doing Ethernet MAC layer encryption. 
But then, they had 802.10 (only implementation I know of was the DESNC) for 
many years before retiring it.

The market for these kinds of devices has been notoriously small. May I ask 
what your use case is?

Thanks,
--Joe
At 03:11 PM 2/7/2005 -0500, Steven M. Bellovin wrote:
Are there any commercial link-layer encryptors for Ethernet available?
I know that Xerox used to make them, way back when, but are there any
current ones, able to deal with current speeds (and connectors)?
--Prof. Steven M. Bellovin, http://www.cs.columbia.edu/~smb

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

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

Re: Can you help develop crypto anti-spoofing/phishing tool ?

[Ed Gerck]

Jerrold Leichter wrote:
"N-version programming" - which is what you are proposing here - can increase
your level of trust against random errors[2], but its of no use at all against
a deliberate attack. 
I heartly disagree. If the N-outputs are continuously verified for 
coherence,
any difference readily stands out. The number N and the cost of always using 
those
N-outputs should, of course, be outweighed against the cost of failure to
detect an attack. Theoretically, however, there is always a finite number N
that can make the probability of such an attack _ as small as you please_.
The mathematical basis for this result was proven by Shannon more than 50 years
ago; the practical intuition for this result was demonstrated during the Mogul
period in India (more than 500 years ago), who are known to have used at least 
three
parallel reporting channels to survey their provinces with some degree of 
reliability,
notwithstanding the additional efforts to do so.
(Recall the conversation here a couple of months ago
about how difficult - to the point of impossibility - it would be to use
external testing to determine if a crypto-chip had been "spiked".)
Aren't we talking about different things? A covert channel, looking at
the crypto-chip by itself, is demonstrably impossible to detect with
certainty. However, what I was talking about is NOT this situation.
You are looking at *one* crypto-chip, a single source of information, a single
trusted source, when you have no correction channel available.  I am
looking at N outputs, N sources of information (each one as independent as
possible but not necessarily 100% independent). You have no reference for
detecting a "spike", I have N-1.
Cheers,
Ed Gerck
-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Canonical LAN Manager hash algorithm specification?

[Dan Moniz]

Hi all,
Sorry to spam the list like this, but I was wondering if anyone had 
pointers to the canonical references for the various versions of the LAN 
Manager protocols and their respective hash algorithms. I've just 
re-read through RFCs 1994, 2433, and 2759 but have thus far been unable 
to find "the" specification for LAN Manager hash algorithms as used in 
the different revisions of the protocol.

Any pointers would be much appreciated.
--
Dan Moniz <[EMAIL PROTECTED]> [http://www.pobox.com/~dnm/]
-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: link-layer encryptors for Ethernet?

[Steven M. Bellovin]

In message <[EMAIL PROTECTED]>, james hughes writes:
>The following device is a layer 2 tunneling device that has 256 bit AES 
>at up to 400Mb/s.
>
>http://blueridgenetworks.com/products/index.htm
>http://blueridgenetworks.com/support/borderguard_vpn__serv_res_ctr.htm
>

Layer 2?  It seems to be an IPsec box.  At the least, their 
Administrator's Guide talks about using IP Protocol 50.

--Prof. Steven M. Bellovin, http://www.cs.columbia.edu/~smb



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

Re: link-layer encryptors for Ethernet?

[james hughes]

The following device is a layer 2 tunneling device that has 256 bit AES 
at up to 400Mb/s.

http://blueridgenetworks.com/products/index.htm
http://blueridgenetworks.com/support/borderguard_vpn__serv_res_ctr.htm
Hope this helps
On Feb 8, 2005, at 11:29 AM, Russell Nelson wrote:
Steven M. Bellovin writes:
Are there any commercial link-layer encryptors for Ethernet available?
I know that Xerox used to make them, way back when, but are there any
current ones, able to deal with current speeds (and connectors)?
Given the price of gigE, it's hard to say that a 100Mbps adapter is
"current", but Intel has one with 3DES.  I recently went through my
collection and threw out about a hundred antique (ISA / MCA) Ethernet
cards, but I kept all the PCI ones.  With sufficient inducement I
could go grovelling through the Intel ones to get you a part number.
--
--My blog is at angry-economist.russnelson.com  | The laws of physics 
cannot
Crynwr sells support for free software  | PGPok | be legislated.  
Neither can
521 Pleasant Valley Rd. | +1 315-323-1241 cell  | the laws of 
countries.
Potsdam, NY 13676-3213  | +1 212-202-2318 VOIP  |

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

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

Re: Can you help develop crypto anti-spoofing/phishing tool ?

[Jerrold Leichter]

| [1] This is also my solution to the famous trust paradox proposed by Ken
| Thompson in his " Reflections of Trusting Trust". Trust is earned, not
| given. To trust Ken's code, I would first ask two or more programmers (who
| I choose) to code the same function and submit their codes to tests. If they
| provide the same answers for a series of inputs, including random inputs,
| I would have a qualification for trusting (or not) Ken's code. This works
| even without source code. Trust is not in the thing, it's how the thing works.
The code Thompson describes would produce equivalent outputs[1] for all but a
very small number of specially-selected strings.  If this test caused you to
change your level of trust in the code ... it did you a great disservice.
"N-version programming" - which is what you are proposing here - can increase
your level of trust against random errors[2], but its of no use at all against
a deliberate attack.  (Recall the conversation here a couple of months ago
about how difficult - to the point of impossibility - it would be to use
external testing to determine if a crypto-chip had been "spiked".)

[1]  Since Thompson was talking about a compiler, the mapping from inputs to
outputs is a partial function.  Just because two compilers produce different
sets of bytes doesn't mean either one is wrong.  Determining the equivalence
of two programs is a very hard problem; in fact, even *defining* the equiva-
lence seems intractable.  Suppose the only difference is that the "spiked"
compiler introduces enough data-dependent speed variation to leak information
through a timing channel?

[2] BTW, test have shown that the "random error" model for bugs isn't a very
good one.  Certain kinds of code are just more likely to contain errors - and
the errors produced by completely independent programmers are often quite
strongly correlated.  So the simple-minded analysis that says that if one
program fails with probability p then the chance that of of n different
versions fail with probability p^n is way off.

-- Jerry


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