Re: TPM coming to Canada

[Peter Gutmann]

M Taylor <[EMAIL PROTECTED]> writes:

>It appears that TPM is being seriously considered by Copyright Policy Branch
>of Canadian Heritage, and has announced a paper by  Dr. Ian Kerr and others. 
>
>
>It mentions a nice top heavy certificate rich method or a DMCA like law as
>two TPMs that might work in their opinion.
>
>[...]
>
>I'm afraid I'll have to start writing letters to government and non-
>government groups to inform them of issues beyond revenue control issues
>(like creator's rights and consumer protection).

A better suggestion for killing it: Write letters strongly encouraging the
PKI-based method.

Peter.


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

Re: Brumley & Boneh timing attack on OpenSSL

[Peter Gutmann]

Bill Stewart <[EMAIL PROTECTED]> writes:

>Schmoo Group response on cryptonomicon.net
>http://www.cryptonomicon.net/modules.php?name=News&file=article&sid=263&mode=&order=0&thold=0
>Apparently OpenSSL has code to prevent the timing attack,
>but it's often not compiled in (I'm not sure how much that's for
>performance reasons as opposed to general ignorance?)

I had blinding code included in my crypto code for about 3 years,
when not a single person used it in all that time I removed it
again (actually I think it's probably still there, but disconnected).
I'm leaning strongly towards "general ignorance" here...

Peter.

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

Re: [Bodo Moeller ] OpenSSL Security Advisory: Timing-based attacks on SSL/TLS with CBC encryption

[Peter Gutmann]

An extremely trivial observation, but may be useful to some:

>The attack assumes that multiple SSL or TLS connections involve a common
>fixed plaintext block, such as a password.

There's been a discussion about how this affects POP over SSL on a private
list.  My suggestion was:

-- Snip --

- Don't retry a connection repeatedly if it fails the first time (I guess you
  don't do that anyway, but some programs like Outlook try automated repeated
  connects).

- Add random whitespace to the initial messages so the password isn't always
  at a fixed location (that is, sprinkle extra spaces and tabs and whatnot
  around in the lines you send up to and including the password).

-- Snip --

This changes the padding on each message containing the password, making the
attack rather more difficult, and has the advantage that you don't need to
convince the party running the server to update their software.  Depending on
how much stuff you can send per message, you can vary it by quite a bit.  In
the POP case the "PASS xxx" would be a single message so you don't have quite
that much leeway, but it looks like you can add enough whitespace to make the
padding random.  Someone else on the list posted a followup to say he'd tried
it on two servers and they had no trouble with the whitespace.

Peter.

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

The Crypto Gardening Guide and Planting Tips

[Peter Gutmann]

After much procrastination I recently put the Crypto Gardening Guide and
Planting Tips online at
http://www.cs.auckland.ac.nz/~pgut001/pubs/crypto_guide.txt, this may be of
interest to readers.  From the introduction:

  There has been a great deal of difficulty experienced in getting research
  performed by cryptographers in the last decade or so (beyond basic
  algorithms such as SHA and AES) applied in practice.  The reason for this is
  that cryptographers don't work on things that implementors need because it's
  not cool, and implementors don't use what cryptographers design because it's
  not useful or sufficiently aligned with real-world considerations to be
  practical. As a result, security standards are being created with mechanisms
  that have had little or no security analysis, often homebrew mechanisms or
  the standards editor's pet scheme.  The problem is a lack of communication:
  Cryptographers often don't seem aware of the real-world constraints that
  their design will need to work within in order to be successfully deployed.
  The intent of this document is to cover some of those real-world constraints
  for cryptographers, to point out problems that their designs will run into
  when attempts are made to deploy them.  Also included is a motivational list
  of extremely uncool problems that implementors have been building ad-hoc
  solutions for since no formal ones exist.

Peter.


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

Sovereignty issues and Palladium/TCPA

[Peter Gutmann]

It looks like Palladium (or whatever it's called this week) is of concern not
just to individuals but to governments as well (the following text forwarded
from elsewhere):

-- Snip --

  Governments would want to explore the implications of the use and
retention of government-held information and use of software for government
business.
  More particularly, governments are likely to want to explore the issues
related to potential foreign control/influence over domestic governmental
use/access to domestic government held data.
  In other words, what are the practical and policy implications for a
government if a party external to the government may have the potential
power to turn off our access to its own information and that of its
citizens.

-- Snip --

Unlike China, not everyone can address this problem by building their own
systems from the silicon on up.

Peter.

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

Re: Verizon must comply with RIAA's DMCA subpoena

[Peter Gutmann]

William Allen Simpson <[EMAIL PROTECTED]> writes:

>But there is a strong economic rationale.  We save untold operational
>expense, support costs, and legal fees.  (The legal cost of complying with
>that single interstate subpoena cost us an entire month of revenue.)

Lucky Green a while back reported that some European ISPs charge customers
less if they use IPsec because then there's less cost involved in complying
with surveillance requirements.

Peter.

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

Re: deadbeef attack was choose low order RSA bits (Re: Key Pair Agreement?)

[Peter Gutmann]

Adam Back <[EMAIL PROTECTED]> writes:
>On Mon, Jan 20, 2003 at 09:08:31PM -0500, Radia Perlman wrote:
>>[...] I was going to suggest something similar to what David Wagner
>>suggested, but with Scott telling Alice the modulus size and the
>>*high* order 64 bits (with the top bit constrained to be 1). I can
>>see how Alice can easily generate two primes whose product will have
>>that *high* order part, but it seems hard to generate an RSA modulus
>>with a specific *low* order 64 bits.
>
>One cheap way the low order 64 bits can be set is to set the low order bits
>of p to the target bitset and the low order bits of q to ...1 (63 0s and
>one 1 in binary), and then to increase the stride of candidate values in the
>prime sieve to be eg 2^64.

That way's trivially detectable by inspection of the private key (which
admittedly isn't a problem in this case because you're not trying to hide its
presence).  More challenging though are ways of embedding a fixed pattern that
isn't (easily) detectable, a la various ways of leaking information in the
public key such as SETUP attacks.

Peter.

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

TCPA-defeating BIOS switcher

[Peter Gutmann]

There's a neat device called the BIOS Saviour which I first saw on the
eksitdata site, http://www.eksitdata.com/, but which has now had a few reviews
on English-language sites, e.g.
http://www.alltechbox.com/reviews/ioss_rd1_bios_savior_eng.php3 and
http://www.ascully.com/modules.php?name=Reviews&rop=showcontent&id=178.  It
consists of a mezzanine board that fits underneath your existing BIOS chip and
contains a second BIOS chip that can replace the existing one.  You can switch
between the two via a switch mounted on a blank plate in an expansion slot.
The intended use is to protect against bad flashes or virii (other uses are
for hot-chipping motherboards with hacked overclocking-enabled BIOSes if the
existing BIOS doesn't support it), but it could also be quite useful to swap
out a TCPA-crippled BIOS for an unencumbered one .  Really adventurous modders
could set it up to boot into the TCPA BIOS as far as is necessary, halt the
CPU via a small processor sitting on the SMB, swap in the non-TCPA BIOS, and
continue.

Peter.

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

Re: PGPfreeware 8.0: Not so good news for crypto newcomers

[Peter Gutmann]

"Richard Johnson" <[EMAIL PROTECTED]> writes:

>To my dismay, the developers of gnupg chose to embed the command line
>processing deep in their software, making doing a proper library-supported
>GUI more difficult.  This was the same mistake that made PGP 2 such a bear to
>port, etc.  I wish I had the time or skill to fix that, but the reality is I
>simply don't have either.

There are other PGP libraries available.  The Veridis Filecrypt SDK,
http://www.veridis.com/products/FileCryptSDK/fcsdk.asp, is a commercial
offering which uses the OpenPGP format, and my own cryptlib,
http://www.cs.auckland.ac.nz/~pgut001/cryptlib/index.html, is available under
the Sleepycat license (GPL or commercial, your choice).  You can modify it in
any way you like, although if you want to do things with it long-term, you may
want to wait until the next release, I rewrote a lot of the lower-level PGP
code recently.

Peter.

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

Biometrics "isn't for security--it's for convenience"

[Peter Gutmann]

There's a good retrospective on biometrics by Jim Wayman (former director of
the U.S. Biometrics Center) in this month's Info Security Magazine, available
at http://www.infosecuritymag.com/2002/nov/retrospective.shtml#1d.

  "It's going to be hard to know how these technologies can be applied to
  increase national security. They might be an added tool, but it will require
  a lot more human intervention. We're not just going to turn these machines
  on and start catching terrorists," he says.

  Because he works primarily for the government, Wayman says he was irritated
  with the way some biometrics vendors tried to capitalize on Sept. 11 by
  suggesting their technology could have prevented the terrorist attacks.

  "No, the government didn't have this stuff in place, precisely because it
  had been working on it and knew its limitations and didn't find any value
  for the costs involved. The government has been on top of this; the
  government's position hasn't changed," he says.

It's nice to see an honest, commonsense assessment like this instead of the
usual biometrics-will-solve-everything stuff (after Sept.11 I was contacted by
a number of biometrics-peddlers, including one who got quite nasty when I
suggested that his wares weren't the panacea he seemed to think they were).

Peter.

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

Digital signature legislation tutorial posted

[Peter Gutmann]

I've recently revamped part 2 of my Godzilla security tutorial, splitting off
the coverage of digital signature legislation and related issues into its own
section.  Part2a, consisting of a total of 79 slides, covers the question of
why we need digital signature legislation, what is a signature, paper
vs.electronic signatures, non-repudiation, trust, and liability, existing
approaches, examples of existing legislation of various types including
advantages and drawbacks, and the Digital Signature Law litmus test (and it
also explains why having a techie comment on legal issues isn't as silly as it
sounds :-).  It's available as part 2a of the Godzilla tutorial at
http://www.cs.auckland.ac.nz/~pgut001/tutorial/index.html.  Comments welcome

Peter.

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

Re: did you really expunge that key?

[Peter Gutmann]

Simon Josefsson <[EMAIL PROTECTED]> writes:

>[EMAIL PROTECTED] (Peter Gutmann) writes:
>>>Which operating systems "leak" memory between processes in this way?
>>
>>Win32 via ReadProcessMemory.
>
>The documentation for the function says it will check read access
>permissions.  Isn't this permission check done properly?  I.e., disallow
>memory reads across processes owned by different users.

Almost all Win32 systems (except for a few Citrix-style systems) are single-
user, so the check is irrelevant.  Even if it's running in a different user
context, for Win9x systems that's meaningless, and for NT systems it's pretty
safe to assume the user is Admin so you can get to anything anyway.

>If you can run a program as root, aren't there easier way to discover
>passwords than allocating memory initialized by other processes? E.g.,
>attaching a debugger to /bin/login.

The problem is someone running a program 3 days later and finding keys in
memory, not active attacks.

>My point is that the software in general cannot solve this without help from
>the operating system.

It can do a pretty good job of it.  Zeroising a key after use on a system
which isn't currently thrashing gives you a pretty good chance of getting rid
of it.

(Yes, you can hypothesise all sorts of weird places where data could end up if
 you're not careful, but to date multiple demonstrated attacks have pulled
 plaintext keys from memory where they were left by programs, and not from
 keyboard device driver buffers or whatever).

>If you run security software on a insecure host, you won't achieve security
>no matter how good the security software is.

Right, so we'll just given up even trying then, and wait for the day when
secure systems are readily available.

>A pair of functions secure_memory_allocate() and secure_memory_zeroize() that
>handle "volatile char*" data, together with a compiler that respects the
>volatile property, seems like a useful interface.  No doubt, this already
>exists.

Nope.  NT (not Win9x) has VirtualLock(), but there are special issues
surrounding this which are too complex to go into here, and Unix doesn't have
anything (mlock() won't cut it).

BTW I misattributed the previous message in my reply (I'm posting from another
system and had to manually edit the reply), apologies for any confusion this
caused.

Peter.

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

Re: did you really expunge that key?

[Peter Gutmann]

"John S. Denker" <[EMAIL PROTECTED]> writes:

>On which systems is all this really an issue, and when? 

The majority of them.

>Which operating systems "leak" memory between processes in this way?

Win32 via ReadProcessMemory.  Most Linux systems which set up the user as root
when they install the OS.  The combined total would be what, 97%? 98%? 99%? of
the market?

>Which operating systems write core dumps that can be read by non-privileged
>users?

Watson under Win32, any Unix system with poor file permissions (which means a
great many of them).  Again, that's most of the market.

This *is* a serious issue, which is why any security software worth its salt
takes care to zeroise memory after use.

Peter.

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

Re: Did you *really* zeroize that key?

[Peter Gutmann]

David Honig <[EMAIL PROTECTED]> writes:

>Wouldn't a crypto coder be using paranoid-programming skills, like 
>*checking* that the memory is actually zeroed? (Ie, read it back..)
>I suppose that caching could still deceive you though?

You can't, in general, assume the compiler won't optimise this away
(it's just been zeroised, there's no need to check for zero).  You 
could make it volatile *and* do the check, which should be safe from 
being optimised.

It's worth reading the full thread on vuln-dev, which starts at
http://online.securityfocus.com/archive/82/297827/2002-10-29/2002-11-04/0.
This discusses lots of fool-the-compiler tricks, along with rebuttals
on why they could fail.

Peter.


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

Re: Did you *really* zeroize that key?

[Peter Gutmann]

>[Moderator's note: FYI: no "pragma" is needed. This is what C's "volatile"
> keyword is for. 

No it isn't.  This was done to death on vuln-dev, see the list archives for
the discussion.

[Moderator's note: I'd be curious to hear a summary -- it appears to
work fine on the compilers I've tested. --Perry]

Peter.


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

Windows 2000 declared secure

[Peter Gutmann]

http://biz.yahoo.com/prnews/021029/sftu114_1.html

Microsoft Windows 2000 Awarded Common Criteria Certification
Tuesday October 29, 2:00 pm ET
Achieves Highest Level of Security Evaluation for the Broadest Set of Real-
  World Scenarios

Microsoft Corp. (Nasdaq: MSFT - News) today announced that its Windows 2000
platform has been awarded the Common Criteria certification for the broadest
set of real-world scenarios yet achieved by any operating system as defined by
the Common Criteria for Information Technology Security Evaluation (CCITSE).
The Common Criteria (CC) certification is a globally accepted standard for
evaluating the security features and capabilities of information technology
products.

[...]

http://story.news.yahoo.com/news?tmpl=story2&ncid=1209&e=2&u=/nm/20021030/tc_nm/
tech_microsoft_security_dc&sid=95573713

Microsoft Says Windows 2000 Passes Security Check
Tue Oct 29, 8:23 PM ET
By Elinor Mills Abreu

SAN FRANCISCO (Reuters) - Microsoft Corp. (NasdaqNM:MSFT - news) said on
Tuesday that Windows 2000 (news - web sites) has received the highest level of
security evaluation of any commercial operating system, an important benchmark
for government and other contracts.

[...]

 NOT TESTING FOR FLAWS

"This type of testing isn't testing for flaws," said John Pescatore, an
analyst at Gartner Inc. "It's more testing whether we can believe the claims
the operating system is making for the security functions it provides."

[...]

Alan Paller, research director at the System Administration, Networking and
Security Institute, agreed.

"It doesn't mean anything for the users. Right now, it's a relatively pure
marketing program for the vendors," Paller said. "They still deliver the
software misconfigured and with flaws."

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

Interesting KPMG report on DRM

[Peter Gutmann]

KPMG have a report "The Digital Challenge: Are You Prepared?" available at
http://www.kpmg.com/news/index.asp?cid=660 in which they surveyed execs at
media companies and conclude that they're focusing too much on (trying to)
lock up content using encryption rather than how to do something useful with
it:

  Digital content is getting a lot of attention - but not at the board level,
  where it is urgently needed. As a recent KPMG survey of top executives
  shows, media companies are focusing too much on encryption and other
  defensive technologies while failing to develop proactive strategies that
  recognize and leverage their online intellectual property assets.

[...]

  But the industry.s efforts to grapple with losses on this scale by locking
  away content behind multiple layers of protection - whether encryption,
  copyright protection, or authentication - have tended to detract from the
  user experience while failing to deliver the hoped-for revenue streams.

  Indeed, for all the publicity, expert attention, and corporate ingenuity
  devoted to digital piracy, it is striking that global content companies have
  not yet been able to find a working solution.

  This white paper, organized around a survey conducted for KPMG by The
  Economist Intelligence Unit, takes the industry.s pulse on The bottom line
  is that media companies need to shift their focus from a circle-the-wagons
  defense of digital intellectual property to innovative strategies for
  managing online content as a core revenue source. To achieve this shift,
  digital intellectual property needs to be valued properly, just like other
  assets on the balance sheet. Also, its protection needs to be treated as a
  key issue of corporate governance and given sustained and dedicated board-
  level attention.

  It is clear from the survey that media executives are trying to remain
  optimistic about the potential of digital content - but securing
  intellectual property rights is an uphill battle. In the quest for the right
  mix of measures to fight piracy, executives are relying heavily on
  encryption as well as reactive steps to police and punish violators. At the
  same time, however, many companies fail to conduct systematic accounting for
  their digital assets, or to pursue more proactive strategies to build new
  revenue streams from their online content.

[...]

  Media companies have so far failed to pioneer new business models that would
  rob piracy of its appeal. Preoccupied with defending the barricades against
  pirates, the industry has shown a deficit of creativity and innovation in
  rolling out products and services that can compete with the pirates. This
  was clear in KPMG.s survey, where only a handful of respondents saw offering
  potential abusers the chance to distribute content legally as a way of
  protecting digital intellectual property.

  In addition, the content industry remains hostage to its own strict
  interpretations of copyright laws and definitions of intellectual property.
  Most leading media organizations have their roots in traditional media
  formats - they still consider every bit of content they produce to be
  subject to copyright and they defend it - tooth and nail. However, today.s
  Internet world conflicts with this business model, as consumers expect more
  fluid boundaries and demand a free flow of information.

Good stuff, read the whole thing at http://www.kpmg.com/news/index.asp?cid=660.

Peter.

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

Real-world steganography

[Peter Gutmann]

I recently came across a real-world use of steganography which hides extra
data in the LSB of CD audio tracks to allow (according to the vendor) the
equivalent of 20-bit samples instead of 16-bit and assorted other features.
According to the vendors, "HDCD has been used in the recording of more than
5,000 CD titles, which include more than 250 Billboard Top 200 recordings and
more than 175 GRAMMY nominations", so it's already fairly widely deployed.
>From http://www.hdcd.com/partners/proaudio/overview.html:

[...]

Hidden Code Addition/Output Dither/Quantization

The final step in the reduction to 16 bits is to add high-frequency weighted
dither and round the signal to 16-bit precision. The dither increases in
amplitude in the frequency range of 16 to 22.05 kHz, leaving the noise floor
flat below 16 kHz where the critical bands of hearing associated with tonality
occur. As part of the final quantization, a pseudo-random noise hidden code is
inserted as needed into the least significant bit (LSB) of the audio data. The
hidden code carries the decimation filter selection and Peak Extend and Low
Level Range Extend parameters. Inserted only 2?5 percent of the time, the
hidden code is completely inaudible-effectively producing full 16-bit
undecoded playback resolution. The result is an industry-standard 44.1-kHz,
16-bit recording compatible with all CD replication equipment and consumer CD
players.

[...]

The paper describing the process is available under the somewhat misleading
name http://www.hdcd.com/partners/proaudio/AES_Paper.pdf.  The description of
the stego en/decoding process is on p.15 (it's a rather long excerpt, but it's
interesting stuff):

As part of the final quantization, a hidden code side channel is inserted into
the LSB when it is necessary for the encoder to inform the decoder of any
change in the encoding algorithm. It takes the form of a pseudo-random noise
encoded bit stream which occupies the least significant bit temporarily,
leaving the full 16 bits for the program material most of the time. Normally,
the LSB is used for the command function less than five percent of the time,
typically only one to two percent for most music. Because the hidden code is
present for a small fraction of the time and because it is used as dither for
the remaining 15 bits when it is inserted, it is inaudible. This was confirmed
experimentally with insertion at several times the normal fraction of time.

[...]

The mechanism which allows insertion of commands only when needed consists of
encapsulating the command word and parameter data in a "packet". A
synchronizing pattern is prepended to the data and a checksum is appended. The
resulting packet is then scrambled using a feedback shift register with a
maximal length sequence and inserted serially, one bit per sample, into the
LSB of the audio data. The decoder sends the LSB's of the audio data to a
complementary shift register to unscramble the command data. A pattern
matching circuit looks for the synchronizing pattern in the output of the
descrambler, and when it finds it, it attempts to recover a command. If the
command has a legal format and the checksum matches, it is registered as a
valid packet for that channel. The arrival of a valid packet for a channel
resets a code detect timer for that channel. If both channels have active
timers, then code is deemed to be present and the filter select data is
considered valid immediately. However, any command data which would effect the
level of the signal must match between the two channels in order to take
effect. The primary reason for this is to handle the case where an error on
one channel destroys the code. In such a case, the decoder will mistrack for a
short time until the next command comes along, which is much less audible than
a change in gain on only one channel, causing a shift in balance and lateral
image movement. If either of the code detect timers times out, then code is
deemed not to be present, and all commands are canceled, returning the decode
system to its default state. If the conditions on the encoder side are not
changing, then command packets are inserted on a regular basis to keep the
code detect timers in the decoder active and to update the decoder if one
starts playing a selection in the middle of a continuous recording.

Since the decoder is constantly scanning the output of the de-scrambler shift
register for valid command packets even when none are present, the possibility
exists that there may be a false trigger. For audio generated by the encoder,
this possibility is eliminated in the absence of storage and transmission
errors by having the encoder scan the LSB of the audio data looking for a
match. If a match to the synchronizing pattern is found, the encoder inverts
one LSB to destroy it.

Modern digital storage and transmission media incorporate fairly sophisticated
error detection and correction systems. Therefore, we felt that only moderate
precautions were necessary 

FIB workstation photos

[Peter Gutmann]

As part of its tour of Nvidia, Anandtech got to look at an FIB workstation of
the kind used for (among other things) reverse-engineering and modifying
semiconductors.  For those who have never seen one of these things, there are
photos at http://www.anandtech.com/video/showdoc.html?i=1711&p=9

Peter.

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

Re: Sun donates elliptic curve code to OpenSSL?

[Peter Gutmann]

Greg Broiles <[EMAIL PROTECTED]> writes:

>Sun is promising not to sue people for patent infringement for using Sun's
>code as provided in the OpenSSL library, provided that the people who don't
>want to be sued comply with a list of conditions:
>
>(1) they promise not to sue Sun for infringing any of their own patents which
>might cover the use of the donated code
>
>(2) don't modify Sun's code as provided by Sun, don't use only parts of the
>donated code, and don't remove the license text from the code.

Doesn't this exclude it from being used in OpenSSL, since it violates the
license?

 * The licence and distribution terms for any publically available version or
 * derivative of this code cannot be changed.  i.e. this code cannot simply be
 * copied and put under another distribution licence
 * [including the GNU Public Licence.]

Peter.

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

Re: Sun donates elliptic curve code to OpenSSL?

[Peter Gutmann]

[EMAIL PROTECTED] writes:

>Some of the OpenSSL developers are on this list. In case they are too busy to
>reply, below are some of the comments from the package:

Could someone with legal know-how translate whatever it is this is saying into
English?

Peter.

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

Re: Cryptogram: Palladium Only for DRM

[Peter Gutmann]

Niels Ferguson <[EMAIL PROTECTED]> writes:
>At 16:04 16/09/02 -0700, AARG! Anonymous wrote:
>>Nothing done purely in software will be as effective as what can be done
>>when you have secure hardware as the foundation.  I discuss this in more
>>detail below.
>
>But I am not suggesting to do it purely in software. Read the Intel manuals
>for their CPUs. There are loads of CPU features for process separation,
>securing the operating system, etc. The hardware is all there!

There was a rather nice paper at Usenix Security 2000 on this [pause]
available from
http://www.usenix.org/publications/library/proceedings/sec2000/robin.html

Peter.

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

Re: Cryptographic privacy protection in TCPA

[Peter Gutmann]

Nomen Nescio <[EMAIL PROTECTED]> writes:

>If a key is misused, i.e. "scraped" out of the TPM and used to create a
>virtualized, rule-breaking software TPM, it can be revoked.  This means that
>all the TPMs that share that one key lose the use of that key. But it doesn't
>matter much, because they each have many more they can use. Since it is
>expected that only a small percentage of TPMs will ever need their keys
>revoked, most TPMs should always have plenty of keys to use.

I designed something along these lines some years ago as a way of building a
fault-tolerant key management system.  The idea is that you create a pile of
keys, and these vote on key updates.  If a key is compromised, you sign its
replacement with a quorum of non-compromised keys, and replace the bad key.
You also periodically roll over keys as a preventive measure, limiting
exposure due to compromises.  No need for a PKI or anything else complex like
that, it's all automatic and transparent.

There can be slight problems if a device stays offline long enough that enough
keys have been rolled over to make reaching a quorum impossible, which was an
issue when I designed the thing but rather unlikely now.  I can dig up the
exact details in case anyone's interested.

Peter.


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

Re: building a true RNG

[Peter Gutmann]

David Wagner <[EMAIL PROTECTED]> writes:

>I once wrote a short note about the relevance of this to IPSec:
>http://www.cs.berkeley.edu/~daw/my-posts/using-prngs

There's another way to avoid this problem, which is to separate the nonce RNG
and crypto RNG, so that an attacker seeing the nonce RNG output can't use it
to attack the crypto RNG.  This is done in PGP 5.x and the cryptlib RNG.  OTOH
some RNGs are used in exactly the opposite manner, generating alternate public
and private random quantities, which make it possible to use one to infer
information about the other.  Examples are generators used with SSL and ssh,
which both alternate from public nonces to private session keys and back.

Peter.

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

RE: IP: SSL Certificate "Monopoly" Bears Financial Fruit

[Peter Gutmann]

"Lucky Green" <[EMAIL PROTECTED]> writes:

>"Trusted roots" have long been bought and sold on the secondary market as any
>other commodity. For surprisingly low amounts, you too can own a trusted root
>that comes pre-installed in >95% of all web browsers deployed.

I'd heard stories of collapsed dot-coms' keys being auctioned off, that being
the only thing of value the company had left.  It makes the title of Matthias'
paper even more appropriate.

(However, I do think that anyone wanting to compromise your security will use
 this morning's MSIE hole to do it rather than buying a CA key.  OTOH it'd be a
 great universal skeleton key for government agencies charged with protecting
 the world from equestrians).

Peter.

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

Re: IP: SSL Certificate "Monopoly" Bears Financial Fruit

[Peter Gutmann]

[EMAIL PROTECTED] writes:
>On 6 Jul 2002 at 9:33, R. A. Hettinga wrote:
>>Thawte has now announced a round of major price increases.  New
>>cert prices appear to have almost doubled, and renewals have
>>increased more than 50%. While Thawte proclaims this is their
>>first price increase in five years, this comes at a time when we
>>should be seeing *increased* competition and *lower* prices for
>>such virtual products, not such price increases.  But of course,
>>in an effective monopoly environment, it's your way or the
>>highway, so this should have been entirely expected.
>
>IE comes preloaded with about 34 root certificate authorities, and it is easy
>for the end user to add more, to add more in batches. Anyone can coerce open
>SSL to generate any certificates he pleases, with some work.

Both Netscape 6 and MSIE 5 contain ~100 built-in, automatically-trusted CA
certs.

 * Certs with 512-bit keys.

 * Certs with 40-year lifetimes.
 
 * Certs from organisations you've never heard of before ("Honest Joe's Used
   Cars and Certificates").
   
 * Certs from CAs with unmaintained/moribund websites ("404.notfound.com").

These certs are what controls access to your machine (ActiveX, Java, install-
on-demand, etc etc).

  * It takes 600-700 mouse clicks to disable these certs to leave only CAs you
really trust.

(The above information was taken from "A rant about SSL, oder: die grosse
 Sicherheitsillusion" by Matthias Bruestle, presented at the KNF-Kongress
 2002).

>Why is not someone else issuing certificates?

How many more do you need?

Peter.

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

Re: New Chips Can Keep a Tight Rein on Consumers

[Peter Gutmann]

Pete Chown <[EMAIL PROTECTED]> writes:
>Peter Gutmann wrote:
>>Actually I'm amazed no printer vendor has ever gone after companies who
>>produce third-party Smartchips for remanufactured printer cartridges.  This
>>sounds like the perfect thing to hit with the DMCA universal hammer.
>
>There is no copyright issue, though.  The DMCA only bans circumvention devices
>that relate to copyrighted content.

If the vendor required it, how long do you think it would take their lawyers to
figure out a way in which some sort of copyright was involved somewhere, and it
could therefore be hit with the DMCA hammer?  Thus the "universal hammer"
comment, you can define almost anything you want to be a copyright violation if
it suits your purposes.  My guess on this one (and IANAL) is that reading the
instruction codes sent from the host would be the user-definable copyright
violation for third-party Smartchips.

Peter.

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

Re: Revenge of the WAVEoids: Palladium Clues May Lie In AMD Motherboard Design

[Peter Gutmann]

"R. A. Hettinga" <[EMAIL PROTECTED]> writes:

>WAVE, some of you might remember, was started by a former NatSemi Chairman
>back before the internet got popular. It was going to be a dial-up book-entry-
>to-the-screen content control system with special boards and chips patented to
>down to it's socks.

Think of it as DIVX for PCs, with a similar chance of success (see my earlier
post about TCPA being a dumping ground for failed crypto hardware initiatives
from various vendors).  Its only real contribution is that the WAVEoid board on
Ragingbull (alongside the Rambus one) is occasionally amusing to read, mostly
because it shows that the dot-com sharemarket situation would be better
investigated by the DEA than the FTC.

Peter.

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

Re: Steven Levy buys Microsoft's bullshit hook, line, and sinker

[Peter Gutmann]

"Jay D. Dyson" <[EMAIL PROTECTED]> writes:
>On Sun, 23 Jun 2002, Bram Cohen wrote:
>>Of course, the TCPA has nothing to do with security or privacy, since
>>those are OS-level things. All it can really do is ensure you're running
>>a particular OS.
>>
>>It's amazing the TCPA isn't raising all kinds of red flags at the
>>justice department already - it's the most flagrant attempt to stifle
>>competition I've ever seen.
>
>It's even more amazing that those who care about security at all aren't nearly
>as up in arms about this matter.  The very idea that the one company with the
>longest history of producing the most pernicious security problems in the
>digital world is being suddenly embraced as that very world's savior.

I think a major contributing factor is TCPA's history.  It's the product of a
bunch of failed security initiatives by a collection of hardware vendors,
dating back to HP's ICF from 1996 (can anyone else even remember what ICF was,
without looking it up)?  Then there's CDSA, and IBM's experiement with smart
cards embedded in motherboards... a ton of vendors with completely different
objectives and a pile of leftover projects which failed to take off when they
weren't called TCPA yet.  Is it even worth wasting cycles on speculating where
TCPA will end up?

Peter.

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

Good quote on biometric ID

[Peter Gutmann]

I was reading a late-70's paper on computer security recently when I saw that
it contains a nice quote about the futility of trying to use biometrics to
prevent Sept.11-type attacks, I thought I'd share it with people:

  When a highway patrolman is sent to his duty, he has to be given the
  authority to cite traffic violators.  This cannot be done explicitly for each
  violator because at the time that the patrolman is sent to his duty, the
  traffic violator does not exist, and the identity of the future violators is
  not known, so that it is impossible to construct individual access rights for
  the violators at that time.  The point is that the patrolman's authority has
  to do with the behaviour of motorists, not their identity.

  - Naftaly Minsky, "An Operation-Control Scheme for Authorisation in Computer
Systems", International Journal of Computer and Information Sciences,
Vol.2, No.2, June 1978, p.157.

Peter.


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

Re: Hiding (and Seeking) Messages on the Web

[Peter Gutmann]

>Hiding (and Seeking) Messages on the Web
>Al Qaeda uses the Web as a communications network
>
>June 17 issue -  One day last October, an intelligence-community analyst
>noticed something strange about a radical Islamist Web site she had been
>monitoring for several months. A previously open, innocuous part of the site
>was suddenly blocked. She checked her notes, found the old address for the
>link and typed it in-to find an otherwise empty page commanding in Arabic,
>MISSIONARIES ATTACK!
>
>OTHER "HIDDEN" PAGES ON the site included seemingly nonsensical phrases and
>quotations from the Qur'an-coded instructions for Qaeda operatives and their
>supporters. U.S. intelligence discovered Al Qaeda uses the Web as a
>communications network. Analysts believe Al Qaeda uses prearranged phrases and
>symbols to direct its agents. An icon of an AK-47 can appear next to a photo
>of Osama bin Laden facing one direction one day, and another direction the
>next. Colors of icons can change as well. Messages can be hidden on pages
>inside sites with no links to them, or placed openly in chat rooms. The
>messages and patterns of symbols are given to analysts at the CIA and National
>Security Agency to decipher.

Does anyone know what sort of hidden terrorist messages Microsoft are
communicating?  Their web pages appear and disappear, and contain nonsensical
phrases and quotations from the Windows documentation.  A Windows icon can
appear in one location one day, and another location the next.  Colours of
icons can change as well.  Messages can be hidden on pages inside Microsoft
sites with no links to them, or placed openly in .HLP files in the Windows
system directory.  The messages and patterns of symbols are given to sysadmins
and programmers to decipher.

Peter.

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

Re: PKI: Only Mostly Dead

[Peter Gutmann]

>Peter Gutmann should be declared an international resource.

Thankyou Nobody.  You should have found the e-gold in your acount by now :-).

>Only one little thing mars this picture.  PKI IS A TREMENDOUS SUCCESS WHICH IS
>USED EVERY DAY BY MILLIONS OF PEOPLE.  Of course this is in reference to the
>use of public key certificates to secure ecommerce web sites.  Every one of
>those https connections is secured by an X.509 certificate infrastructure.
>That's PKI.

  "Opinion is divided on the subject" -- Captain Rum, Blackadder, "Potato".

The use with SSL is what Anne|Lynn Wheeler refer to as "certificate
manufacturing" (marvellous term).  You send the CA (and lets face it, that's
going to be Verisign) your name and credit card number, and get back a cert.
It's just an expensive way of doing authenticated DNS lookups with a ttl of one
year.  Plenty of PK, precious little I.

>The truth is that we are surrounded by globally unique identifiers and we use
>them every day.  URLs, email addresses, DNS host names, Freenet selection
>keys, ICQ numbers, MojoIDs, all of these are globally unique!
>"[EMAIL PROTECTED]" is a globally unique name; you can use that
>address from anywhere in the world and it will get to the same mailbox.

You can play with semantics here and claim the exact opposite.  All of the
cases you've cited are actually examples of global distinguisher + locally
unique name.  For example the value 1234567890 taken in isolation could be
anything from my ICQ number to my shoe size in kilo-angstroms, but if you view
it as the pair { ,  } then it makes sense
(disclaimer: I have no idea whether that's either a valid ICQ number or my shoe
size in kilo-angstroms).

(This is very much a philosophical issue.  Someone on ietf-pkix a year or two
 back tried to claim that X.500 DNs must be a Good Thing because RFC 822 email
 address and DNS names and whatnot are hierarchical like DNs and therefore
 can't be bad.  I would suspect that most people view them as just dumb text
 strings rather than a hierarchically structured set of attributes like a DN.
 The debate sort of fizzled out when no-one could agree on a particular view).

I think the unified view is that what you need for a cert is a global
distinguisher and a locally meaningful name, rather than some complex
hierarchical thing which tries to be universally meaningful.  Frequently the
distinguisher is implied (eg with DNS names, email addresses, "for use within
XYZ Copy only", etc), and the definition of "local" really means "local to the
domain specified in the global distinguisher".  I'm not sure whether I can
easily fit all that into the paper without getting too philosophical - it was
really meant as a guide for users of PKI technology.

Peter.


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

Re: PKI: Only Mostly Dead

[Peter Gutmann]

"R. A. Hettinga" <[EMAIL PROTECTED]> quotes:

>http://www2.cio.com/research/security/edit/a05232002.html
>
>CIO Magazine
>Only Mostly Dead
>By Scott Berinato
>
>[...]

Actually it's not quite that bad.  I have a paper "PKI: It's Not Dead, Just
Resting" (no relation to the article, despite the name) which takes a
(hopefully) somewhat detached look at PKI issues and how they can be addressed,
covering (as far as possible within the 15-page limit) the X.509 and PGP
approaches, as well as the other usual suspects like AADS, XML/SAML, SPKI, and
so on, as well as some areas which nothing seems to be doing at the moment -
it's an attempt to do a grand unified view of PKI without ending up with a
whole book.  I've also tried to throw in a reasonable amount of historical
perspective to explain why some (mostly X.509) things are done the way they
are.  It may or may not appear in ;login, the Usenix journal, at some point,
although I haven't heard anything for awhile.  It's available from
http://www.cs.auckland.ac.nz/~pgut001/pubs/notdead.zip (zipped PDF) for anyone
who's interested.  I wouldn't link to it at the moment because of its current
in-limbo status, once it's officially published somewhere I'll add a link from
my home page.

Peter.


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

Re: what is GPG's #1 objective: security or anti-patent stance ( Re: on the state of PGP compatibility (2nd try))

[Peter Gutmann]

Adam Back <[EMAIL PROTECTED]> writes:

>Back in the days of pgp2.x I used to receive and send a fair proportion of
>mail encrypted with pgp; these days it is a much lower proportion, and a
>rather high proportion of those fail.  It's not like I'm using old software or
>failing to try what is reasonable to get messages to work.  Even with my
>fairly complete collection of PGP versions you saw the results.  Imagine how
>much worse it will be between people who do not upgrade frequently or take
>such defensive strategies.  So you say upgrade already.  However as I think I
>have demonstrated, I follow this strategy myself and as you can see it doesn't
>work either.

I've been in a similar situation.  Back when I was fighting our government over
crypto export controls, it was sometimes necessary to talk to journalists in a
manner which didn't give the spooks a week's advance notice about something
which they shouldn't have known about until they opened the morning paper.
This was in the days of PGP 5.x.  Some of the people I was talking with were
pretty patient, and often put up with multiple iterations of neither side being
able to decrypt the other's messages, but eventually the choice came down to
given the opposition advance notice or not having the story published at all,
and there's really not much choice there.

Now substitute "human rights group" for "journalist" and "secret police" for
"spooks" and you can see why this is a problem.  Non-commercial PGP has always
been by geeks, for geeks, with features more important than minor
considerations like usability.  Who cares if there are 146 semi-documented,
vaguely-defined command-line options, look at the algorithm choices!  If you
want to use some obscure hash algorithm which was fasionable for 2 months in
1997, you can, and who cares if it takes you half an hour, the FAQ, the
manpage, and an online search to figure out how to encrypt a file?

That's why non-commercial crypto will always struggle to find mainstream
acceptance.  Doing the crypto engine is (relatively) easy, and fun, and there
are lots of people willing to help.  Doing the UI components is dreary and
boring, and no-one is interested because they've just spotted a hash algorithm
published in the Journal of the Bratislavian Philological Society in 1978 which
they urgently need to add support for.

(Although I don't use Windows mailers, I've heard nice things about The Bat,
 http://www.ritlabs.com/the_bat/features.html, which has built-in PGP support.
 Apparently at some point Pegasus Mail, http://www.pmail.com, will have built-
 in PGP and S/MIME support as well).

Peter.

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

RE: Welome to the Internet, here's your private key

[Peter Gutmann]

Greg Rose <[EMAIL PROTECTED]> writes:

>While priming the RC4 table, I accidentally filled the data buffer instead
>(D'oh!) with consecutive byte values 0x00, 0x01, ... 0xFF, 0x00, ...
>
>This very much passes the FIPS 140 tests for randomness, despite being nothing
>like it:

A generic order-0 entropy estimator (think Huffman coder) will pass this,
because each symbol occurs with equal probability.  The reason this is a
problem is because any introductory information theory text will give the
standard formula for entropy estimation (H = -sum(prob(x) * log( prob(x and
users will either stop reading there or the text won't go any further.  I've
seen a (fielded) crypto RNG which uses this sort of estimator, which won't
catch a whole pile of failure modes which the FIPS tests would get.

Peter.

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

RE: Welome to the Internet, here's your private key

[Peter Gutmann]

"Trei, Peter" <[EMAIL PROTECTED]> writes:

>One other scheme I've seen, and which, while it doesn't give me warm fuzzies,
>seems reasonable, is to issue the the enduser a smartcard with a keypair on
>it. The SC generates the pair onboard, and exports only the public half. The
>private half never leaves the SC (there is no function on the card to export
>it).
>
>If you trust the above, then the only copy of the private key is on the SC,
>despite it having been generated without the end users participation.

This also causes problems, because it's really, really hard to spread the key
around if the only copy is on the card.  Solutions I've seen are to multiplex a
single card + reader across multiple machines, or (more commonly) to generate
the key in software and then load it onto the card, with copies kept active on
the host PC.  This combines the benefits of smart card security and the
flexibility of software crypto keys which can be copied and distributed as
required.

Peter.

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

RE: Welome to the Internet, here's your private key

[Peter Gutmann]

Greg Rose <[EMAIL PROTECTED]> writes:

>The scariest thing, though... at first I put in an unkeyed RC4 generator for
>the self-test data, but accidentally ran the FIPS test on a straight counter
>output... and it passed (even version 1)! I'd always assumed that something in
>the regularity of a counter would trigger it. Running through the buffer,
>XORing consecutive bytes, makes it fail quite handily, but might also have the
>undesirable effect of hiding a bias in the data, if there was one. I'm thinking
>of suggesting to NIST that a stronger test would be to run the test on the raw
>data, and then on the data after XORing consecutive bytes... if it's really
>random stuff it should pass both, and in the meantime this would catch all
>sorts of failures. Any comments?

General-purpose data compressors (which make rather nice entropy estimators)
also have problems with counting events.  The Calgary compression corpus (the
Dhrystone of the compression world) includes a file geo in which every fourth
byte is a zero.  No standard compressor will pick this up, so that while they
all realise that zeroes occur with ~25% probability, they don't realise that
they always occur at every fourth byte (alongside a few others in between).
There will always be data patterns which appear obvious to a human but aren't
easily picked up by automated tests, so I don't know how far it's worth chasing
this thing.

Peter.

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

Re: Welome to the Internet, here's your private key

[Peter Gutmann]

Jaap-Henk Hoepman <[EMAIL PROTECTED]> writes:

>It's worse: it's even accepted practice among certain security specialists.
>One of them involved in the development of a CA service once told me that they
>intended the CA to generate the key pair. After regaining consciousness I
>asked him why he thought violating one of the main principles of public key
>cryptography was a good idea. His answer basically ran as follows: if the CA
>is going to be liable, they want to be sure the key is strong and not
>compromised. He said that the PC platform of an ordinary user simply wasn't
>secure/trusted enough to generate keys on. The system might not generate `good
>enough' randomness, or might have been compromised by a trojan.

I've seen similar things.  The CAs are so worried about key security that they
insist on generating the things themselves, but then hand them over in PKCS #12
format from which they're shared by, and easily accessible to, every single app
running on the machine, are copied across other machines (because it's valuable
enough that you don't want to have to get a new one for each machine), etc etc
(again, I go into this in some detail in my paper in the section titled
"Private keys aren't").

Some of the, uh, logic applied by CAs for cert management can lead to really
bizarre situations.  For example there's a public CA which password-protects
access to its CRLs, using the reasoning that anyone who can get access to a CRL
can determine which keys have been compromised, and that's a bad thing (isn't
that what a CRL is for?).  As a result, anyone can get access to the certs the
CA issues, but only a tiny, select few can check whether they've been revoked
or not (given that most apps just ignore revocation checking, this probably
isn't as serious as it sounds).  There's a list of silliness as long as a very
long thing when it comes to working with certs...

Peter.

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

Welome to the Internet, here's your private key

[Peter Gutmann]

It is accepted practice among security people that you generate your own
private key.  It is also, unfortunately, accepted practice among non-security
people that your CA generates your private key for you and then mails it to you
as a PKCS #12 file (for bonus points the password is often included in the same
or another email).  Requests to have the client generate the key themselves and
submit the public portion for certification are met with bafflement, outright
refusal, or at best grudging acceptance if they're big enough to have some
clout.  This isn't a one-off exception, this is more or less the norm for
private industry working with established (rather than internal, roll-your-own)
CAs.  This isn't the outcome of pressure from shadowy government agencies, this
is just how things are done.  Be afraid.

(I have a paper in the works which covers things like this in some detail, but
 the number of times this has come up recently is sufficiently alarming that I
 thought I'd post a heads-up here to let others who aren't exposed to this sort
 of stuff know about it.  This also doesn't begin to go into the number of CAs
 who are re-certifying the same user key over and over again, year after year
 ("We haven't been informed that it's been compromised, so it's safe to keep
 using it for another year")).

Peter.



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

Amusing note on real-world PKI deployment

[Peter Gutmann]

Found while submitting a paper to a PKI conference:

-- Snip --

[...]

A Note on Authentication

We're using passwords for user authentication because, given the diversity of
user platforms and the (current) lack of a widespread PKI, it's the most
suitable right now.

[...]

-- Snip --

I guess this is an updated form of the Marshall Rose quote about "when X.400
users want to communicate, they use the phone" :-).

Peter.



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

Re: PGP & GPG compatibility

[Peter Gutmann]

John Gilmore <[EMAIL PROTECTED]> writes:

>Note, however, that there are many things that OpenPGP doesn't do, making
>encrypted email still a pretty sophisticated thing to do. Brad Templeton has
>been kicking around some ideas on how to make zero-UI encryption work (with
>some small UI available for us experts who care more about our privacy than
>the average joe).
>
>  http://www.templetons.com/brad/crypt.html

There are already a number of S/MIME gateways which do exactly this.  The most
typical mode of operation is org-to-org, where all mail from an organisation is
routed through their corporate gateway anyway so it's a natural place to
perform this operation.  It works reasonably well, and is completely
transparent to the end user (although org-to-org is rather easier to get going
than end-user-to-end-user).  The S/MIME WG has been working on a whole string
of add-ons to basic S/MIME for handling this type of messaging, encrypted
mailing lists, and assorted other useful stuff.

Peter.



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

Re: Bill's Bull, pt. 2...

[Peter Gutmann]

"R. A. Hettinga" <[EMAIL PROTECTED]> quotes:

>January 17, 2002
>
>Tech Center
>
>Microsoft Announces Corporate Shift To Focus on Tech Security, Privacy

Or:

  Microsoft Issues Press Release to Say it Will No Longer Treat Security as
  Just a PR Problem

Peter.



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

Liability issues in computer security

[Peter Gutmann]

For those who don't normally read it, the December issue of ;login (which
you'll eventually be able to get at http://www.usenix.org/publications/login/
if you're not a member) has a nice legal analysis of the issue of liability for
negligent computer security.  It's probably the best (and certainly the most
detailed) discussion I've seen on this topic (unless there's something hidden
in an obscure law journal somewhere which I'm not aware of).

Peter.




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

RE: CFP: PKI research workshop

[Peter Gutmann]

"Arnold G. Reinhold" <[EMAIL PROTECTED]> writes:

>The EWR monorail had been shut down for the better part of a year to correct a
>pesky track corrosion problem (it's hard to get all the bugs out of a system
>that is not widely used).

Thus making it a perfect analogy for PKI [0].

Peter.

[0] Before people flame me for this, what's currently widely-used is what's in
X.509v1 modulo CRL support.  Anything else, you're on your own.



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

Neat security quote found on slashdot

[Peter Gutmann]

>From the "Gift Card Hacking" thread,
http://slashdot.org/comments.pl?sid=25442&cid=0&pid=0&startat=&threshold=1&mode=flat&commentsort=0&op=Change

Re:Nondisclosure (Score:1) 
by FauxPasIII ([EMAIL PROTECTED]) on Saturday December 29, @12:27PM 
(#2762484) 

  Businesses are not going to expend money fixing any problem, no matter how
  severly it affects me as a customer, until it starts to affect their
  profitability. I wouldn't expect them to; they are a construct created with
  the express purpose of optimizing profitability. My goal as a security-
  conscious consumer is to -make- it the corporation's best interest to fix any
  problems that would have a detrimental effect on me as quickly as possible.

(Please, not another full-disclosure flamewar, I just wanted to post this
 because it seems to summarise the situation nicely).



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

Re: CFP: PKI research workshop

[Peter Gutmann]

Nelson Minar <[EMAIL PROTECTED]> writes:

>The thing that makes me the most sad is that the PKI situation only seems to
>be getting worse, not better.

The reason for this is that as we work on PKI deployment, we discover more and
more (previously unknown) problems which need to be solved.  If you look at PKI
in 1978 it was pretty simple (certificates in a "public file"), then in the
1980's it got more complex with directories and CRLs and whatnot, and after
that an ongoing stream of further issues which need to be addressed were
discovered as systems were finally deployed.  It's just getting harder and
harder as we discover more and more problems when we try and actually implement
the thing.  Even what we know now is only the tip of the iceberg compared to
what we're going to discover further down the track, and that's only
identifying the *problems* to be solved, not providing solutions.

PKI is like an erection: The more you think about it, the harder it gets.

Peter.




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

Re: CFP: PKI research workshop

[Peter Gutmann]

>As I never tire of saying, "PKI is the ATM of security."

Naah, it's the monorail/videophone/SST of security.  Looks great at the World
Fair, but a bit difficult to turn into a reality outside the fairgrounds.

Peter (who would like to say that observation was original, but it was actually
   stolen from Scott Guthery).




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

Cut and paste defeats Excel's password protection

[Peter Gutmann]

http://www.nwfusion.com/news/2001/1217excel.html

Spreadsheet passwords can be foiled by simply copying and pasting.
By John Fontana
Network World, 12/17/01

REDMOND, WASH. - Microsoft Excel, the predominant spreadsheet in use today,
contains a feature that could expose sensitive corporate data once the document
is distributed within a company or among trading partners.

That feature is drawing an increased level of attention from researchers and
Excel users alike as its implications become more fully understood. One expert
calls it "as potentially damaging" as many of the most recent viruses.

Excel has features that allow spreadsheet creators to hide, lock and/or
password-protect data and mathematical calculations used in original documents.
These features seemingly provide a measure of data security to conceal
specified data from prying eyes.

In reality, that data can be exposed by any end user who can execute a simple
copy-and-paste procedure. It takes fewer steps to reverse the security than it
does to set it up.

[...]



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

Re: The MS DRM Patent and Freedom to Speak and Think

[Peter Gutmann]

>Microsoft's patent for a Digital Rights Management
>Operating System was awarded yesterday:
>
>   http://cryptome.org/ms-drm-os.htm
>
>A digital rights management operating system protects
>rights-managed data, such as downloaded content, from
>access by untrusted programs while the data is loaded
>into memory or on a page file as a result of the
>execution of a trusted application that accesses the
>memory. To protect the rights-managed data resident in
>memory, the digital rights management operating system
>refuses to load an untrusted program into memory while
>the trusted application is executing or removes the
>data from memory before loading the untrusted program.
>[...]

I wonder how long it'll take for someone to locate the undocumented _MPAAKEY
which exists alongside MS's documented one?

Peter.



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

Thai Pirates Crack Microsoft's New Windows System

[Peter Gutmann]

http://dailynews.yahoo.com/h/nm/2002/tc/tech_thailand_windows_dc_1.html

BANGKOK (Reuters) - Thai computer users are buying thousands of pirated copies
of Microsoft's new Windows XP (news - web sites) operating system a week ahead
of its official launch in Thailand, vendors said on Monday.

Shops at Bangkok's Pantip Plaza -- a multi-story rabbit's warren of computer
goods outlets -- said pirates had found ways of getting around the new
operating system's security features.

``We've had XP Professional for three weeks and it's selling very well. We sell
around 200 copies a day,'' one shop owner, who identified himself only as Nop,
told Reuters.

[...]

Peter.



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

Re: when a fraud is a sale, Re: Rubber hose attack

[Peter Gutmann]

Rick Smith at Secure Computing <[EMAIL PROTECTED]> writes:
>At 06:48 PM 11/5/2001, David Jablon wrote:
>>Yet, strong network-based authentication of people does not require
>>complex secret information ... if "complex" means demanding
>>at least {64, 80, 128} random bits.
>>
>>With emerging strong password schemes, your average one-in-a-thousand
>>or one-in-a-million kind of secret can do some pretty neat things --
>>in some cases with no need at all for stored secrets,
>>as in a [SP]EKE password-encrypted chat session.
>
>Definitely true. It would be great to see that technology replace the
>relatively vulnerable challenge response hashes used by Microsoft and others.
>In general I'm skeptical of protocols that rely entirely on a memorized secret
>for remote access security, but the [SP]EKE stuff is supposed to use the weak
>secret to bootstrap a strong one without opening a crack that might allow a
>dictionary attack on the weak secret. A slick idea.

... contained within a minefield of patents and IP restrictions, which is
killing its use.  What would be necessary is either for someone (presumably
with any army of lawyers to back them up) to state that a particular (sound)
scheme was free of any IP restrictions, or for one or more of the groups with
patents to state they'd allow everyone royalty-free use.  As it is at the
moment, it's just too risky to do anything.  Even if someone has a technology
which they claim is unencumbered, others may claim that they have some patent
which covers it, or the situation is unclear enough to scare off companies who
are afraid of lawsuits.  As a result, no-one can do anything.

Peter.



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

Re: Proving security protocols

[Peter Gutmann]

Rick Smith at Secure Computing <[EMAIL PROTECTED]> writes:
>At 09:00 AM 11/1/2001, Roop Mukherjee wrote:
>>Can someone offer some criticism of the practice formal verification in
>>general ?
>Okay, I'll grab this hot potato.

I may as well speak up as well then... I spent most of a chapter of my thesis
looking at formal security verification in fairly exhaustive detail (if I
missed anything I'm sure I'll hear about it soon :-).  You can get it as
http://www.cryptoapps.com/~peter/04_verif_techniques.pdf.  The conclusion is
that there are more effective ways to spend your time and money, but for the
full story I'd recommend you read the above document.

Peter.



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

Re: Thawte Protects The World From Crypto (was Re: [ Slashdot Message ] Daily Stories)

[Peter Gutmann]

"R. A. Hettinga" <[EMAIL PROTECTED]> forwarded:
>++
>| Thawte Protects The World From Crypto  |
>|   from the strange-goings-on dept. |
>|   posted by timothy on Monday October 29, @06:28 (privacy) |
>|   http://slashdot.org/article.pl?sid=01/10/29/0028250  |
>++
>
>nutsaq writes: "Thawte.com, a South African Certificate Authority, in a
>move of astonishing wrong-headedness, has inexplicably changed it's
>developer certificate policy. To quote [0]from the site: 'Due to current
>world circumstances developer certificates can no longer be issued to
>individuals.'Sucks to be working with crypto these days. Apparently I'll
>get no help from Thawte to encrypt stuff, oh wait, I didn't need it, the
>browsers did."

As was mentioned on the Slashdot debate, this has nothing to do with crypto but
is for AuthentiCode signing certs.  Blaming this move in terrorists therefore
makes it even more bizarre.  According to Thawte (via Slashdot), they were just
following orders from Verisign.  The only explanation I can think of is that
it's some attempt by MS to further lock small developers out of XP/.NET
(alongside charging $1K/year for developers and similar things), but that's
pretty far-fetched.  On the whole this move makes no sense, is anyone from
Verisign able to exlain it?  (Is anyone from *anywhere* able to explain it?).

Peter.



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

bin Laden's hidden messages revealed

[Peter Gutmann]

While browsing through an expansion of pi I have discovered various messages
describing the attack on the WTC.  Further corroboration of this was found in
e, the square root of 2, 3, and other values.

The next step is obvious: The government must either ban entirely, or at least
introduce strict licensing of, irrational numbers.  God knows there's enough
irrationality around already after the attack.

Peter.



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

Re: [FYI] Did Encryption Empower These Terrorists?

[Peter Gutmann]

Enzo Michelangeli <[EMAIL PROTECTED]> writes:

>Many merchants need a unique identifier for the buyer, and their traditional
>processes often use the PAN (card number, for credit transactions). According
>to what I heard, at one point the original specs of SET were altered in order
>to accomodate, as an option, the visibility of the PAN to the merchant,
>thereby giving up the other advantage of SET besides cardholder's
>authentication (i.e., protection of the card number from eyes different from
>cardholder's or banking system's).

I've run into the same issue with various companies (including some big ones)
who eventually run into the following situation:

  "We need to encrypt our customer database because of security concerns over
  credit card numbers being stolen.  Oh yes, we use the CC# as the primary key
  for all our accounts".

This practice seems to be fairly widespread.  Workarounds are very difficult
(*everything* is keyed off the CC# as a unique customer ID, something like that
is very hard to fix in practice).

(And before someone jumps in with the obvious "It's easy, just replace the CC#
 with ", consider the following
 scenario: You have a company with gear distributed over 300 sites worldwide,
 using software from 120 vendors running on 18 different platforms, of which 3
 provide source code.  8 have gone out of business (the software is still being
 used because it does the job), and all but the 3 which have source code
 available use an undocumented, proprietary format for their data.  Your job is
 to provide a time-and-materials estimate on what it'd take to fix this.  You're
 allowed a maximum of 90 days and $50K (+ 3 programmers) to get the problem 
 solved).

Peter.



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

Stego spy terrorist scare

[Peter Gutmann]

Looking at some of the recent (unsubstantiated) reports of people who would
abhor porn for religious reasons using porn to communicate (!!), I wonder if
these stories can be traced back to the LA Times nonsense of a few years ago
where unnamed spies were doing the same thing?  Given that these rumours stick
around more or less forever once started, and that the stego-porn story seems
to be no more than a rumour, could it just be a mutation of the same story?

(Why couldn't bin Laden just record his messages backwards in heavy metal like
satan does?).

Peter.



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

Re: Field slide attacks and how to avoid them.

[Peter Gutmann]

"Kevin E. Fu" <[EMAIL PROTECTED]> writes:

>But XDR is so BORING compared to a REAL standard like ASN.1! It doesn't have
>infinite possibilies for object definitions requiring help from standards
>committees, multiple incompatible data representations with different kinds of
>ambiguity, or ugly API packages that are too large to believe that the
>implementers debugged them adequately.  That's just no fun at all!

I can feel this sliding into a specification language debate, but I have to put
in a word to defend ASN.1 here.  When used by a skilled practitioner, ASN.1 can
be truly elegant.  The problem is that, like BASIC, it looks deceptively
simple, so that everyone thinks they can write a spec in ASN.1 after five
minutes study of an ASN.1 introductory guide, and they usually do.  The result
is a great confused muddle which noone can figure out and everyone implements
slightly differently, leading to ASN.1's reputation of being a pain to work
with (to paraphrase the famous FORTRAN comment, "The determined hack can write
crap in any language").  Having had experience working with ASN.1, XDR, the SSL
specification notation, and PGP, I definitely prefer ASN.1 for its ability
(when used correctly) to provide a clear, unambiguous definition of a data
exchange format.

Peter.



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

Re: How to ban crypto?

[Peter Gutmann]

"Steven M. Bellovin" <[EMAIL PROTECTED]> writes:

>The basic [GAK] argument is complexity.  Cryptographic software and key
>exchange protocols are very hard to get right even in simple cases.  If we now
>try to add a new feature, we have to add complexity.  Worse yet, this new
>feature is designed to do something that is not only brand-new, it's something
>that more conventional protocols and implementations are designed to avoid, at
>virtually all costs:  export a copy of the key.  Why do you think we can get
>this right?

There is strong empirical evidence to support the fact that we can't get this
right.  Let's say a GAK infrastructure is two orders of magnitude more
difficult to establish than a PKI (it may be even worse than that, but let's
take that as an estimate - to get a GAK infrastructure going you need, as a
minimum, a fully functional PKI to build on top of).

After 10 years of effort we haven't even managed to get a basic PKI going yet
(what's being practiced today could best be described as "certificate
manufacturing").  I can't see how a GAK infrastructure will ever be practical.

(I once heard a story about a someone in the military who suggested that
 security researchers develop a program which could analyse another program to
 see if it would do something malicious.  The response was that the military
 should fund the research and they'd let them know when they had a solution.
 Perhaps this is a way to get funding for further PKI/GAK research).

Peter.



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

New Microsoft Security Server* (*runs Solaris)

[Peter Gutmann]

Microsoft is currently running a series of double-page ads in various security
magazines advertising the new Microsoft Internet Security and Acceleration
Server (see for example Info Security Magazine, August 2001, p.38-39, or
Information Security magazine, August 2001, p.2-3).  The picture in the ad
shows a sysadmin sitting in a network room in front of the server.  

The server is a Sun machine.

(Nice to see even MS admit that if you want a secure server, you shouldn't be
 running Windows on it :-).

Peter.




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

Re: crypto flaw in secure mail standards

[Peter Gutmann]

"Jeffrey I. Schiller" <[EMAIL PROTECTED]> writes:

>I don't believe S/MIME has timestamps in its signature format.

It's a standard part of the S/MIME signature.  Optional features include
countersignatures from external timestamping authorities.

Peter.




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

Re: secure phone (was Re: Starium...)

[Peter Gutmann]

William Allen Simpson <[EMAIL PROTECTED]> writes:

>OK, it seems to me that all the pieces are already in place.  Maybe I'm
>biased, but IETF already has specifications that cover the wish list.

I hate to sound like a pessimist, but I can't imagine this ever happening. 
This sort of thing has been around since (at least) brew-a-stu in the early
'90s, and seems to come up again every few years (and then fade out after 6-12
months).  Every time the people involved eventually find that while the general
details are easy enough to sort out, getting a finished implementation done
take an awful lot of effort (the first 90% of the work takes 90% of the time
and money, the remaining 9% takes the other 90%, and the final 1% takes the
third 90%).

Given that most people are going to be sitting at PCs or have laptops with
them, what's wrong with Nautilus (or whatever) and a headset plugged into their
sound card (in the worst case you can tunnel $generic_internet_talk_software
over ssh or SSL with CPU power to spare)?  Most users have already got most of
the hardware at hand, is it worth the effort to design a special-case secure
phone for a market which seems to be fairly limited?

Peter.




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

Re: Starium (was Re: article: german secure phone)

[Peter Gutmann]

"Perry E. Metzger" <[EMAIL PROTECTED]> writes:

>I was unaware that Starium has ever released a product to be compatible with,
>and a quick glance at their web site fails to reveal products for sale. Am I
>mistaken on this? I would very much like to buy their products if they
>existed...

They went belly-up some time ago, I don't know who owns the IP rights.

Peter.





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

Re: NSA tapping undersea fibers?

[Peter Gutmann]

Steve Bellovin <[EMAIL PROTECTED]> writes:

>The article is at http://interactive.wsj.com/articles/SB990563785151302644.htm
>for those who subscribe.

.. and at http://www.zdnet.com/zdnn/stories/news/0,4586,2764372,00.html for
those who don't :-).

Peter.




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