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

2005-02-09 Thread 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]


Re: link-layer encryptors for Ethernet?

2005-02-09 Thread 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: link-layer encryptors for Ethernet?

2005-02-09 Thread 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]


Canonical LAN Manager hash algorithm specification?

2005-02-09 Thread 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: Can you help develop crypto anti-spoofing/phishing tool ?

2005-02-09 Thread 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]


RE: Canonical LAN Manager hash algorithm specification?

2005-02-09 Thread 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]


Group Aims to Make Internet Phone Service Secure

2005-02-09 Thread R.A. Hettinga
http://online.wsj.com/article_print/0,,SB110790485798349353,00.html

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 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]


Hold the Phone, VOIP Isn't Safe

2005-02-09 Thread R.A. Hettinga
http://www.wired.com/news/print/0,1294,66512,00.html

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 judge what the 

Re: link-layer encryptors for Ethernet?

2005-02-09 Thread 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]


Re: link-layer encryptors for Ethernet?

2005-02-09 Thread 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?

2005-02-09 Thread 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]


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

2005-02-09 Thread 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?ViewItemitem=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: A cool demo of how to spoof sites (also shows how TrustBar preventsthis...)

2005-02-09 Thread 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?ViewItemitem=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: A cool demo of how to spoof sites (also shows how TrustBar preventsthis...)

2005-02-09 Thread 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?ViewItemitem=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...)

2005-02-09 Thread 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?ViewItemitem=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 some string of Kanji, 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...)

2005-02-09 Thread 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...)

2005-02-09 Thread 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...)

2005-02-09 Thread 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: link-layer encryptors for Ethernet?

2005-02-09 Thread 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]