Yahoo delivers "secure" email

[Eugene.Leitl]

Ian Brown writes:
 > Why don't they use SSL between sender and Yahoo?!

Because that would spoil the taste of the snake oil, obviously.

/. Yahoo delivers encrypted email

[Eugene.Leitl]

http://news.yahoo.com/h/cn/20001129/tc/yahoo_delivers_encrypted_email_1.html

Wednesday November 29 03:00 AM EST
Yahoo delivers encrypted email 

By Paul Festa, CNET News.com

Yahoo has quietly introduced a way for people to send scrambled messages through its
email service.

As first reported in August, Yahoo is providing its email encryption
option through a deal with Zixit, a Dallas-based email encryption
firm. Yahoo will rout encrypted email through Zixit's
SecureDelivery.com Web site.

Yahoo and Zixit representatives declined to comment on the public
availability of the service and would not say whether it was an
across-the-board launch or a temporary test.

In papers filed with the Securities and Exchange Commission, Zixit
disclosed that the service would launch in the fourth quarter.

Whatever its scope, the introduction of the service makes Yahoo the
first major Web portal to offer encrypted email. So far, data
scrambling has been the province of tech-savvy computer users willing
to use products that require a software download, such as Network
Associates' Pretty Good Privacy.

Yahoo's competition in the free, Web-based encrypted email arena comes
from smaller players including Hushmail and ZipLip.

Some analysts have questioned the value of a mass-market encryption
product, suggesting that the odds of an email message being
intercepted are infinitely smaller than the danger of compromising
sensitive data stored on a lost computer or on a hacked Web server.

Yahoo's free encryption option handles outgoing email messages in a
multi-step procedure that the portal warns is not foolproof.

"Please be aware that this is not an end-to-end secure service," reads
an explanation of the service posted by Yahoo. "This option only
avails your recipient of a certain level of security in accessing and
reading the email message you are sending. Before your email message
is encrypted by SecureDelivery.com it is still subject to the inherent
limitations of a standard TCP/IP connection."

Yahoo's new system works like this: Once a message is composed, it
travels, unencrypted, to Yahoo, which sends it through a secure
connection to SecureDelivery.com. There, the message and any
attachments are scrambled.

SecureDelivery then sends the recipient the address to a Web page,
secured by Secure Sockets Layer ( SSL) and hosted by
SecureDelivery.com, where the message can be picked up and descrambled
for up to seven days.

Recipients first have to verify that they hold the specified email
account. They then can choose a "pass phrase" that will automatically
give them access to future messages.

Under the terms of the deal, Zixit will pay Yahoo at least $5.7
million during the next two years. On top of that, Zixit will give
Yahoo a cut of revenues "associated with Yahoo users."

Zixit this month landed a second major client, Entrust, which will let
people using its Entrust/Express encryption product send messages
through the SecureDelivery service if their email recipient doesn't
have an Entrust certificate. Under that deal, Entrust and Zixit will
divide usage fees and advertising revenues.

Re: Is PGP broken?

[Eugene.Leitl]

Adam Back writes:
 
 > And lastly even if they had done it right, GPG went in and fucked it
 > up some more by sticking religiously to the "don't use patented
 > algorithms" free software mantra to the huge detriment of PGP
 > interoperability. 

You have to agree that the "not using patented algorithms" thing
solves the problem once and for all, if in a somewhat Gordian way
(partly breaking backwards compatibility). We would never had any
problems if not for PGP screwing it up -- by using potentially
problematic pieces of code. As PGP's track record went from "angelic"
to "distinctly tarnished", I stopped using it. Many other people I
know did as well. I've switched to GPG, which hasn't got any track
record so far, once it became stable. We'll wait and see how they do.

I don't think there is currently any alternative to GPG. (The king is
dead, long live the king). In fact I'm surprised this isn't as evident
as I expected, since it is being discussed here. Please tell me why I
should stop using GPG and go back to using PGP, any version of it.

[linux-elitists] International Kernel Patch

[eugene.leitl]

From: Don Marti <[EMAIL PROTECTED]>

That was fast. Anybody running a kernel with the IKP?

- Forwarded message from Alexander S A Kjeldaas <[EMAIL PROTECTED]> -

Date:   Tue, 3 Oct 2000 12:34:33 +0200
From: Alexander S A Kjeldaas <[EMAIL PROTECTED]>
Subject: 2.2.17.7
To: [EMAIL PROTECTED]
X-Orcpt: rfc822;[EMAIL PROTECTED]

2.2.17.7 is released with the AES cipher integrated.  

2000-10-03 Alexander Kjeldaas <[EMAIL PROTECTED]>

* International kernel patch 2.2.17.7 released.

* speed.c cleanups.

* The crypto API now compiles when proc support has been disabled.

* AES cipher added.  The AES cipher is implemented by the rijndael
module, but with a separate cipher id/name.

* Updated Rijndael implementation from Brian Gladman merged.

* ECB testvectors for rijndael from the AES submission added.

This patch is available from:

ftp.*.kernel.org:/pub/linux/kernel/crypto/v2.2/

astor

-- 
Alexander KjeldaasMail:  [EMAIL PROTECTED]
finger [EMAIL PROTECTED] for OpenPGP key.

Linux-crypto:  cryptography in and on the Linux system
Archive:   http://mail.nl.linux.org/linux-crypto/

- End forwarded message -

-- 
Don MartiThis email brought to you
[EMAIL PROTECTED]   by the number 67 and the 
http://zgp.org/~dmarti/  operator XOR.
whois DM683 Software patent reform now: http://burnallgifs.org/

___
linux-elitists 
http://zgp.org/mailman/listinfo/linux-elitists

Key Generation Security Flaw in PGP 5.0

[eugene.leitl]

From: [EMAIL PROTECTED]

   SECURITY FLAW IN PGP 5.0
   



  EXECUTIVE SUMMARY
  -

A flaw has been found in the randomness gathering code of PGP 5.

PGP 5 will, under certain well-defined circumstances, generate
public/private key pairs with no or only a small amount of
randomness. Such keys are insecure.

Chances are very high that you have no problem. So, don't panic.




  WHO IS AFFECTED?
  

The flaw has been found in the PGP 5.0i code base.  It is specific
to Unix systems such as Linux or various BSD dialects with a
/dev/random device.


Versions 2.* and 6.5 of PGP do NOT share this problem.

PGP versions ported to other platforms do NOT share this problem.


The problem does NOT manifest itself under the following
circumstances:

- You typed in a lot of data while generating your key, including
  long user ID and pass phrase strings.

- A random seed file PGP 5 could use existed on your system before
  you generated the key.


However, the problem affects you in the worst possible manner if you
started from scratch with pgp 5 on a Unix system with a /dev/random
device, and created your key pair non-interactively with a command
line like this one:

pgpk -g 



WHAT TO DO?
---

If you have generated your key non-interactively, you may wish to
revoke it, and create a new key using a version of PGP which works
correctly.



 DETAILS
 ---

In order to generate secure cryptographic keys, PGP needs to gather
random numbers from reliable sources, so keys can't be predicted by
attackers.

Randomness sources PGP generally uses include:

- a seed file with random data from previous sessions
- user input and input timing

Additionally, certain Unix systems such as OpenBSD, Linux, and others,
offer a stream of random data over a central service typically called
/dev/random or the like.  If present, this service is used by PGP
as a source of random data.

PGP 5.0i's reading of these random numbers does not work. Instead of
random numbers, a stream of bytes with the value "1" is read.

In practice, this implies two things:

1. PGP5 will generally overestimate the amount of randomness
   available.  We have not researched the effects of this in detail.

   However, we believe that the amount of randomness gathered from
   input data, timing information, and old random data will be
   sufficient for most applications.  (See below for a detailed
   estimate.)

2. In situations in which no other randomness sources are available,
   PGP relies on the /dev/random service, and thus uses predictable
   instead of random numbers. This is not a flaw of the random
   service, but of the PGP5 implementation.


One particular example of such a situation is non-interactive key
generation with a virgin PGP 5 installation, like described above.

Example:

  $ mkdir /tmp/pgp5test
  $ PGPPATH=/tmp/pgp5test
  $ pgpk -g RSA 1024 [EMAIL PROTECTED] 0 "passphrase string"

In fact, RSA keys generated this way are entirely predictable, which
can easily be verified by comparing key IDs and fingerprints.

When using DSA/ElGamal keys, the DSA signature key is predictable,
while the ElGamal encryption subkey will vary. Note that
fingerprints and key IDs of the predictable DSA keys depend on a
time stamp, and are themselves not predictable.

Proof of concept key rings generated with pgp 5.0i are available
from .



   GORY DETAILS
   

1. Code

Here's the flawed code from src/lib/ttyui/pgpUserIO.c:

 1314   static unsigned
 1315   pgpDevRandomAccum(int fd, unsigned count)
 1316   {
 1317   char RandBuf;
 1318   unsigned short i = 0;
 1319
 1320   pgpAssert(count);
 1321   pgpAssert(fd >= 0);
 1322
 1323   for(i = 0; i <= count; ++i) {
>1324   RandBuf = read(fd, &RandBuf, count);
 1325   pgpRandomAddBytes(&pgpRandomPool, (byte *)&RandBuf, sizeof(RandBuf));
 1326   pgpRandPoolAddEntropy(256);
 1327   }
 1328
 1329   return(i);
 1330   }

The count parameter is always set to the value 1 by the calling
code.  The byte read from the file descriptor fd into the RandBuf
buffer is subsequently overwritten with the read() function's return
value, which will be 1.  The actual random data are not used.

This can be fixed by replacing line 1324 by the following line of
code:

   read (fd, &RandBuf, 1);


2. "Random" data

A dump of random data gathered during an interactive key generation
session is available at .
This was dumped as passed to the pgpRandomAddByte() function, one
byte at a time.

Note the streams of bytes with th

Aladdin eToken 3.3.3.x Hardware USB Key Private Data Extraction

[eugene.leitl]

From: Kingpin <[EMAIL PROTECTED]>

  @Stake Inc.
  L0pht Research Labs
www.atstake.com www.L0pht.com


   Security Advisory


Advisory Name: eToken Private Information Extraction and
   Physical Attack
 Release Date: May 4, 2000
  Application: N/A
 Platform: Aladdin eToken USB Key 3.3.3.x
 Severity: An attacker can access all private information
   stored on the device without knowing the PIN number
   of the legitimate user.
   Author: Kingpin [[EMAIL PROTECTED]]
Vendor Status: Vendor contacted - response shown below
  Web: http://www.L0pht.com/advisories.html


Overview:

Aladdin Knowledge Systems' (http://www.ealaddin.com) eToken is a
portable USB (Universal Serial Bus) authentication device providing
complete access control for digital assets. eToken stores private keys,
passwords or electronic certificates in a hardware token the size of a
house key. The eToken makes use of two-factor authentication. Using the
legitimate user's PIN number ("what you know") and the physical USB key
("what you have"), access to the public and private data within the key
will be granted.

The attack requires physical access to the device circuit board
and will allow all private information to be read from the device without
knowing the PIN number of the legitimate user. By using any number of
low-cost, industry-standard device programmers to modify the unprotected
external memory, the User PIN can be changed back to a default PIN. This
will allow the attacker to successfully login to the eToken and access all
public and private data. A homebrew device programmer could be built for
under $10 and commercial device programmers are available from a number of
companies ranging in cost from $25 to $1000.

Users must be aware that the PIN number can be bypassed and should
not trust the security of the token if it is not always directly in their
possession. If a legitimate user loses their USB key, all data, including
the private information, needs to be considered to have been compromised.

The eToken device is also not tamper-evident. It is possible to open

the device housing without evidence of tampering, allowing the attacker to
gain physical access to the circuit board without the legitimate user's
knowledge. Epoxy encapsulation and other tamper hindering techniques should
be employed in the manufacturing of such hardware devices.


Detailed Description:

The legitimate user's PIN can be reset back to the default PIN by
simply copying a particular 8-byte string from one area of the
unprotected external memory to another. If necessary, the legitimate
user's original PIN can be copied back into the external memory after
the attack and no evidence of tampering will be apparent.

All data on the eToken USB key is stored in an external memory.
The 8KB flavor of the eToken uses an Atmel 25640 SPI Serial EEPROM
(http://www.atmel.com). Serial EEPROMs are extremely common in the
engineering industry and require minimal circuitry to read and write
to. They are also notoriously insecure and often do not provide any
type of security features. Due to the nature of Serial EEPROMs, it is
possible to attach a device programmer to the device, while it is still
attached to the circuit board, and read and write at will. Our
experiments were carried out using the Needham's Electronics EMP-30
(http://www.needhams.com) which cost $995, although a homebrew device
programmer could be built with a handful of components for under
$10. Other device programmers are available from a number of companies,
ranging in cost from $25 to $1000. A schematic of our findings can be
found at: http://www.L0pht.com/advisories/etoken_schematic.pdf

There are two PIN numbers associated with each eToken USB key,
allowing either User or Administrator access. User access has complete
control of the eToken file system, while Administrator is allowed to
initialize the key, but not access private data.

Both PINs, private data, and secret data are encrypted in some
manner before being stored into the EEPROM. The public data is stored
in plaintext and can be easily read by viewing the buffer of the
Serial EEPROM.

The 8-byte strings which determine the User and Administrator
PINs are stored at location $10 and $18, respectively. By copying the
8-byte string stored at $20 into either of those areas, we return the
PIN to its default state. The 8-byte string defining the encrypted
version of the default PIN is unique for each eToken.

Initial memory dump, with User PIN set to  and
Admininstrator PIN set to 87654321:

 User PINAdmin PIN
 /-\ /-\
0010 7235 BAA8 5778 DE97 B7DD

[RRE]I-Gear list cracked; privacy violations and error rate

[eugene.leitl]

From: Phil Agre <[EMAIL PROTECTED]>

[See also .
Reformatted to 70 columns.]

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
This message was forwarded through the Red Rock Eater News Service (RRE).
You are welcome to send the message along to others but please do not use
the "redirect" option.  For information about RRE, including instructions
for (un)subscribing, see http://dlis.gseis.ucla.edu/people/pagre/rre.html
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

Date: Wed, 1 Mar 2000 15:05:04 -0600
From: [EMAIL PROTECTED]
Subject: I-Gear list cracked; privacy violations and error rate

One week after our report on the decryption of X-Stop's blocked site
list, Peacefire has released a program that can decrypt the list of
437,000 sites blocked by I-Gear, another "censorware" program now
owned by Symantec.  The codebreaker program can be downloaded from:

 http://peacefire.org/censorware/I-Gear/igdecode/

(This page also has instructions on how to obtain I-Gear's encrypted
list without having to download and install I-Gear.)

We performed an experiment similar to our X-Stop test: we extracted
student pages in the ".edu" domain that were blocked in the "Sex/Acts"
category, looked at the first 50 URL's that were still working,
and found that 76% of the blocked pages were obviously errors!
This sounds ridiculously high, but I saw the blocked pages myself,
otherwise I wouldn't believe it.  The list of 50 examined sites is at:

 http://peacefire.org/censorware/I-Gear/igear-blocked-edu.html

We also discovered that when you install I-Gear, it scans in your real
name and company name from your computer and uploads this information
to Symantec.  Not the "real name" that you give the program during
the registration process -- your actual real name that you used to
register your copy of Windows.  (This is the name that shows up on
the "General" tab of the System applet in Control Panel.)  Symantec's
privacy policy, on the other hand, states:

http://www.symantec.com/legal/privacy.html

 "The choice of how much personally identifiable information
 you disclose to Symantec is completely at your discretion."

Again, we believe these discoveries will bear on the ongoing
debate over the Digital Millennium Copyright Act, UCITA (the law
strengthening the force of draconian "license agreements" that
prohibit users from examining products by reverse engineering) and
the DVD codebreaking court cases.  Reverse engineering I-Gear and
decrypting the list was the *only* way to obtain a reliable figure
for the error rate of their product, rather than just coming up with
a list of blocked sites.  Even the discovery that I-Gear retrieves
and uploads your real name to the manufacturer, was discovered through
reverse engineering.  If such reverse engineering becomes illegal,
it will become very difficult for third parties to criticize software
in general, other than the user interface and other aspects that are
visible without "looking under the hood".

 -Bennett

[EMAIL PROTECTED] http://www.peacefire.org
(425) 649 9024

Bluetooth gets more promoters

[eugene.leitl]

From: Gregory Alan Bolcer <[EMAIL PROTECTED]>

I like the encryption tagline.  Bluetooth developers conf is in
LA next week.  Anyone going ? 

http://www.pcworld.com/pcwtoday/article/0,1510,14098,00.html

Unlike the spec espoused by the Infrared Data Association,
  which has no security, Bluetooth uses 128-bit encryption,
  he notes. Bluetooth also supplies authentication, so a
  device identifies itself before transmitting information.

  But Bluetooth won't necessarily replace IrDA, which is more
  appropriate for direct connections such as business card
  exchanges and can transfer larger files, Ellis says.

  Other wireless technologies, like the Wireless Application
  Protocol, may prove complimentary to Bluetooth.

  "A WAP phone might use a Bluetooth link to connect to a
  PC," Ellis suggests.

-- 
Greg Bolcer
email: [EMAIL PROTECTED]
web: http://www.endtech.com
work: 714.505.4970
cell: 714.928.5476
fax: 603.994.0516

Re: [transhumantech] Re: Universal Quantum Computers

[eugene.leitl]

From: Michael Nielsen <[EMAIL PROTECTED]>

On Thu, 2 Dec 1999 [EMAIL PROTECTED] wrote:

> 
> From: dmolnar <[EMAIL PROTECTED]>
> 
> On 3 Dec 1999, lcs Mixmaster Remailer wrote:
> 
> > NTRU is a lattice based system.  Solving these systems involves some
> > linear algebra and matrix operations.  These are not known to be
> > accelerated by quantum computers.
> 
> This is true. It's also true that the problem of finding shortest 
> vectors in a lattice has recently been shown to be NP-complete. Also
> I've heard that there are arguments that quantum computers may not be
> "powerful enough" to decide all problems in NP. 

Well, sort of.  A result of Bennett, Bernstein, Brassard and Vazirani
(SIAM Journal on Computing, 1997) shows that there is a class of
approaches to solving NP-complete problems on quantum computers that
won't work. 

The class of problems is what might be called "naive search" algorithms.
This class of algorithms is defined in the following way: given an
instance of an NP-complete problem --- say, a graph which we wish
to test for the presence of a Hamiltonian cycle --- the algorithm is only
allowed to make use of information about the graph which is obtained by
querying an "oracle" which tells the algorithm whether a
particular candidate path around the graph is a Hamiltonian cycle for
that graph or not.  Bennett et al show that such an algorithm requires
exponential resources even on a quantum computer.

Obviously, this class of algorithms is quite restrictive, as such 
algorithms ignore a lot of potentially useful information about the 
problem instance.  Nevertheless, if you believe (as many people do)
that what makes the NP-complete problems hard is that there is essentially
no structure in the problems to make them amenable to solution, then this
result implies that quantum computers won't be able to solve NP-complete
problems efficiently.

Of course, it's quite possible that this belief is wrong, and perhaps
quantum computers can even solve NP-complete problems efficiently.  We'll
just have to wait and see.  (I'm not holding my breath, mind you...)

Michael Nielsen
Room 3,  East Bridge,  Mail Code 12-33,  Caltech,  Pasadena CA 91125 
Ph:  626 395 8431  Fax: 626 793 9506
http://theory.caltech.edu/~mnielsen/ [EMAIL PROTECTED]

--- ONElist Sponsor 

Essential Feynman Library for $7.99! (3 books/ 6 audio tapes -$97 value) 
Learn physics from the legenary Richard Feynman, renown for making
complex ideas easy to understand. Order NOW at Library of Science:
http://clickme.onelist.com/ad/dblselect5 ">Click Here


Community email addresses:
  Post message: [EMAIL PROTECTED]
  Subscribe:[EMAIL PROTECTED]
  Unsubscribe:  [EMAIL PROTECTED]
  List owner:   [EMAIL PROTECTED]

Shortcut URL to this page:
  http://www.onelist.com/community/transhumantech
Old archive:
  http://mail.planetx.com/transhumantech/

The Australian Parliament passes ASIO bill

[eugene.leitl]

From: "Harvey Newstrom" <[EMAIL PROTECTED]>

26/11/99 05:41

 The Australian Parliament passes ASIO bill
 William Maher, Newswire

 Parliament has passed laws that allow the Australian Security Intelligence
 Organisation (ASIO) to tap into and alter data on private computer systems.

 The ASIO Amendment Bill 1999 passed the Senate yesterday, giving
 federal authorities the power to tap into private computer systems for
 surveillance purposes. This is the first time in 13 years a major change
has
 been made to the ASIO Act 1979.

 While the legislation gained bipartisan support, some members expressed
 concern that bill was rushed through Parliament. Senator Bolkus noted
 yesterday that the Senate had waited four or five months to debate the
bill.
 "We could have spent more time in the analysis period," he said in
 Parliament.

 Labor has also expressed concern that the law allows ASIO to add, delete
 or alter data on remote computers. An amendment has subsequently been
 made that says data can only be altered if it is "necessary" to obtain
 access to data.

 The change hasn't appeased the Democrats, who claim that the new law is
 a serious breach of Australians' privacy. Deputy leader Senator Natasha
 Stott Despoja said that the laws could be intentionally misused to plant
 evidence. "The government has found quite a convenient excuse for
 significant new excursions into personal surveillance," she said.

 Privacy groups are angry that the bill gives ASIO the power to tap into
 private computer systems. Consumer group Financial Services Consumer
 Policy Centre has previously called on the Senate to reject the bill,
claiming
 it contains "serious flaws" (see story).


 This article is located at http://www.newswire.com.au/9911/asio.htm
--
Harvey Newstrom 

Author, Consultant, Engineer, Legal Hacker, Researcher, Scientist.