[risks] Risks Digest 22.15

From: RISKS List Owner (riskoat_private)
Date: Sun Jul 14 2002 - 14:20:41 PDT

  • Next message: RISKS List Owner: "[risks] Risks Digest 22.16"

    RISKS-LIST: Risks-Forum Digest  Sunday 14 July 2002  Volume 22 : Issue 15
    
       FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS (comp.risks)
       ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator
    
    ***** See last item for further information, disclaimers, caveats, etc. *****
    This issue is archived at <URL:http://catless.ncl.ac.uk/Risks/22.15.html>
    and by anonymous ftp at ftp.sri.com, cd risks .
    
      Contents:
    Listen to TCAS, not the controller! (Monty Solomon)
    Biometric programs "more ... toys than of serious security measures"
      (Yves Bellefeuille)
    Brazilian Internet theft (Tom Van Vleck)
    Pretty Poor Privacy from Network Associates (NewsScan)
    FreeBSD Scalper worm, a bad precedent... (Nicholas C. Weaver)
    Software bugs cost the US 40bn a year (Pete Mellor)
    Free Prozac in the junk mail draws a lawsuit (Monty Solomon)
    Cringely on Palladium (Pete Mellor)
    More on Palladium (Pete Mellor)
    EULA (Monty Solomon)
    Windows Media Player security update EULA (Pedt Scragg)
    Re: Randomly generated 4-letter words in sendmail ... (Bill Gunshannon)
    Re: US Navy suffers domain hijacking (Bill Stewart, Conor O'Neill)
    Re: E-mail address parsing (Tony Finch)
    Re: FORTH (Jonathan)
    REVIEW: "Digital Signatures", Mohan Atreya et al. (Rob Slade)
    Abridged info on RISKS (comp.risks)
    
    ----------------------------------------------------------------------
    
    Date: Wed, 10 Jul 2002 01:31:45 -0400
    From: Monty Solomon <montyat_private>
    Subject: Listen to TCAS, not the controller!
    
    Edmund L. Andrews: Controller Sent Jets Into Crash, Flight Data Show
    *The New York Times*, 9 July 2002
    
    Information from the flight recorders aboard the two planes that crashed
    into each other one week ago over southern Germany show that a Swiss air
    traffic controller in effect put the planes on a collision course by
    ordering the Russian pilot to descend at the same time that the plane's own
    collision-avoidance system was urging him to climb.
    
    The new data, released today by German investigators, show that the two
    planes' automated systems communicated with each other exactly as they were
    meant to do and that the accident would probably not have occurred if the
    Russian pilot had simply ignored the Swiss controller in Zurich. The
    collision killed 52 Russian schoolchildren and 19 adults.
    
    In addition, German investigators said German controllers saw danger 
    nearly two minutes before the crash and desperately tried to warn the 
    controllers in Zurich, who had responsibility for both planes.  ...
    
    http://www.nytimes.com/2002/07/09/international/europe/09CRAS.html
    
    ------------------------------
    
    Date: Sat, 06 Jul 2002 03:05:13 -0400
    From: yanat_private (Yves Bellefeuille)
    Subject: Biometric programs "more ... toys than of serious security measures"
    
    Since the death of _Byte_, the German magazine _c't_, or _Magazin fuer
    Computer Technik_, is probably the best technical computer magazine in the
    world.
    
    Some articles from this magazine are translated into English and made
    available on its WWW site at http://www.heise.de/ . One recent article
    of interest to comp.risks readers is "Biometric Access Protection
    Devices and their Programs Put to the Test", from _c't_ 11/2002, dated
    22 May 2002, available at http://www.heise.de/ct/english/02/11/114/ .
    
    The conclusion is that "the products in the versions made available to
    us were more of the nature of toys than of serious security measures".
    One wonders whether the biometric security programs now used by
    corporations and governments, especially in the US, are any better.
    
    Yves Bellefeuille <yanat_private>, Ottawa, Canada
    Esperanto FAQ: http://www.esperanto.net/veb/faq.html
    Rec.travel.europe FAQ: http://www.faqs.org/faqs/travel/europe/faq
    
    ------------------------------
    
    Date: Fri, 12 Jul 2002 14:24:38 -0400
    From: Tom Van Vleck <thvvat_private>
    Subject: Brazilian Internet theft
    
    Arrest of hacker is requested
    Jornal do Brasil, Sexta-Feira, 12 Jul 2002
    (tvv rough translation, thanks babelfish)
    
    The police of Mato Grosso do Sul yesterday asked for the re-arrest of the
    student Guillermo Amorim de Oliveira Alves, age 18 years, accused of the
    biggest theft yet carried out through the Internet in Brazil.  Guillermo was
    arrested 19 Jun 2002 in the act of diverting R$25,000 from bank accounts
    using a notebook computer.  He was held in custody for 14 days by the
    Federal Police and was released on 3 Jul on habeas corpus.  But analysis of
    his computer, divulged on 9 Jul, showed that the hacker violated the sites
    of four national banks and diverted at least R$120,000 from 50 accounts.
    The analysis is incomplete, but there is evidence that the hacker has a bank
    account containing R$3 million.  His computer also contained 3500 American
    credit-card numbers from two card issuers.  The FBI will enter the case.
    
    ------------------------------
    
    Date: Fri, 12 Jul 2002 09:44:27 -0700
    From: "NewsScan" <newsscanat_private>
    Subject: Pretty Poor Privacy from Network Associates
    
    A computer security company has uncovered a flaw in PGP (Pretty Good
    Privacy) -- a freely distributed, public key encryption system that's used
    to scramble e-mail messages -- that could allow malicious users to
    unscramble sensitive messages. The flaw is found only in PGP plug-ins for
    Microsoft Outlook users distributed by Network Associates. "The PGP
    vulnerability enables an attacker to send a specially crafted e-mail to any
    Outlook address enabled with the PGP plug-in, which will in turn give them
    access to that system," says eEye Digital Security, which discovered the
    problem. EEye chief hacking officer Marc Maiffret says the flaw allows an
    attacker to do "anything a user of that machine could do -- copy files,
    delete files, install a backdoor." Gartner research director for Internet
    security John Pescatore says, "This vulnerability means people using [the
    affected] version of PGP actually are less secure than if they weren't using
    security at all. It's always a really, really bad thing when a security
    product has a bug." (NewsFactor Network, 11 Jul 2002; NewsScan Daily, 12 Jul
    2002)
      http://www.ecommercetimes.com/perl/story/18560.html
    
    ------------------------------
    
    Date: Mon, 8 Jul 2002 15:31:11 -0700 (PDT)
    From: "Nicholas C. Weaver" <nweaverat_private>
    Subject: FreeBSD Scalper worm, a bad precedent...
    
    The recent Apache "scalper" worm, targeting FreeBSD systems, represents a
    dangerous precedent, even if it is a rather ineffective worm: it linearly
    scans randomly selected class Bs, it doesn't employ a very good scanner, and
    it can only infect a few types of machines (Apache 1.3.20, .22-24 running on
    FreeBSD).
    
    It was roughly 10 days between when Gobbles Security released an exploit for
    the recent Apache vulnerability (in response to ISS's statement two days
    earlier, announcing the vulnerability and stating that it was only
    exploitable on win32 and some 64 bit platforms) that the worm was seen in
    the wild.  This compared with several months for Code Red and Nimda, between
    vulnerability disclosure and appearance of a worm.
    
    We can expect this time to reduce to nearly 0 in the future, as worm authors
    prepare worms in advance, or borrow existing worm code, and simply drop in
    exploits as they are published.  As we have already seen mail worm toolkits,
    we can expect similar active scanning worm toolkits.  This means that the
    window of vulnerability between when an exploit or flaw is published, and
    when it is actively exploited, will quickly reduce to zero.
    
    As important, this worm contained a controllable DOS and backdoor module,
    something directly useful to a blackhat, as did the Goner mail worm.  The
    blackhat community has realized that worms are a great way to compromise
    machines with little effort and little risk.
    
    My personal, somewhat hazy crystal ball: Over the next year, we will see a
    lot of "1 day" worms, where shortly after an exploit is published, a
    corresponding worm will be released.  These worms will almost invariably
    carry DDoS, credit card searchers, or similar payloads optimized for
    blackhat goals.  We probably will see toolkits!
    
    We will also start to see worms appearing less than 2-3 days after a
    detailed vulnerability is reported, as slightly more sophisticated blackhats
    create an exploit, drop it into existing frameworks, and release worms.
    
    Be Afraid (tm).
    
    Scalper Worm code and first detection was at
    http://www.dammit.lt/apache-worm/
    
    Nicholas C. Weaver <nweaverat_private>
    
    ------------------------------
    
    Date: Sat, 29 Jun 2002 14:30:27 +0100 (BST)
    From: Pete Mellor <pmat_private>
    Subject: Software bugs cost the US 40bn a year
    
    I tried to look for a reference to the original NIST report, but 
    could not access www.nist.gov at the time.  
    
    *Computer Weekly*, 28 June 2002  
      http://www.cw360.com/article%26rd%3D%26i%3D%26ard%3D113682%26fv%3D1
    
    Software bugs are costing the US economy an estimated 40bn [pounds?] each
    year, with almost two-thirds of the cost being borne by end-users, and the
    remainder by developers and vendors, according to a new study for the US
    government.  Software faults could be costing the European Union, whose 15
    member states have a combined gross domestic product (GDP) slightly less
    than the US GDP almost as much again.  The US study, by the National
    Institute of Standards and Technology (NIST), said that testing could reduce
    the cost of bugs by about a third but would not eliminate all software
    errors.
    
    ------------------------------
    
    Date: Sun, 7 Jul 2002 11:56:44 -0400
    From: Monty Solomon <montyat_private>
    Subject: Free Prozac in the junk mail draws a lawsuit
    
    Unsolicited Prozac arrived in a hand-addressed manila envelope, from a
    nearby Walgreens drugstore, with a "Dear Patient" form letter.  "Enclosed
    you will find a free one month trial of Prozac Weekly.  Congratulations on
    being one step to full recovery."  This led one recipient to file a
    class-action lawsuit, stating that Walgreens, a local hospital, three
    doctors, and Prozac's maker Eli Lilly misused patients' medical records and
    invaded their privacy. It also accused the drugstore and Lilly of engaging
    in the unauthorized practice of medicine.  [PGN-ed from article by Adam
    Liptak, *The New York Times*, 6 Jul 2002]
      http://www.nytimes.com/2002/07/06/national/06PROZ.html
    
    ------------------------------
    
    Date: Tue, 9 Jul 2002 22:49:37 +0100 (BST)
    From: Pete Mellor <pmat_private>
    Subject: Cringely on Palladium 
    
    Those who have been following the Palladium thread might be interested in 
    the following article entitled "I told you so" by Robert X. Cringely:- 
      http://www.pbs.org/cringely/pulpit/pulpit20020627.html 
    The following is a long extract from his article:
    
      Let's concentrate on the Microsoft story. Last August, I wrote of a rumor
      that Microsoft wanted to replace TCP/IP with a proprietary protocol -- a
      protocol owned by Microsoft -- that it would tout as being more secure.
      Actually, the new protocol would likely be TCP/IP with some of the
      reserved fields used as pointers to proprietary extensions, quite similar
      to Vines IP, if you remember that product from Banyan Systems. I called it
      TCP/MS in the column. How do you push for the acceptance of such a
      protocol? First, make the old one unworkable by placing millions of
      exploitable TCP/IP stacks out on the Net, ready-to-use by any teenage
      sociopath. When the Net slows or crashes, the blame would not be assigned
      to Microsoft. Then ship the new protocol with every new copy of Windows,
      and install it with every Windows Update over the Internet. Zero to 100
      million copies could happen in less than a year.
    
      This week, Microsoft announced Palladium through an exclusive story in
      Newsweek written by Steven Levy, who ought to have known better. Palladium
      is the code name for a Microsoft project to make all Internet
      communication safer by essentially pasting a digital certificate on every
      application, message, byte, and machine on the Net, then encrypting the
      data EVEN INSIDE YOUR COMPUTER PROCESSOR. Palladium compatible hardware
      (presumably chipsets and motherboards) will come from both AMD and Intel,
      and the software will, of course, come from Microsoft. That software is
      what I had dubbed TCP/MS.
    
      The point of all this is simple. It may actually make the Internet
      somewhat safer. But the real purpose of this stuff, I fear, is to take
      technology owned by nobody (TCP/IP) and replace it with technology owned
      by Redmond. That's taking the Internet and turning it into MSN. Oh, and
      we'll all have to buy new computers.
    
      This is diabolical. If Microsoft is successful, Palladium will give Bill
      Gates a piece of every transaction of any type while at the same time
      marginalizing the work of any competitor who doesn't choose to be
      Palladium-compliant. So much for Linux and Open Source, but it goes even
      further than that. So much for Apple and the Macintosh. It's a militarized
      network architecture only Dick Cheney could love.
    
      Ironically, Microsoft says they will reveal Palladium's source code, which
      is little more than a head feint toward the Open Source movement. Nobody
      at Microsoft is saying anything about giving the ownership of that source
      code away or of allowing just anyone to change it.
    
      Under Palladium as I understand it, the Internet goes from being ours to
      being theirs. The very data on your hard drive ceases to be yours because
      it could self-destruct at any time. We'll end up paying rent to use our
      own data!
    
      Can you tell I think this is a bad idea? 
    
      What bothers me the most about it is not just that we are being sold a
      bill of goods by the very outfit responsible for making possible most
      current Internet security problems. "The world is a fearful place (because
      we allowed it to be by introducing vulnerable designs followed by clueless
      security initiatives) so let us fix it for you." Yeah, right. Yet
      Palladium has a very real chance of succeeding.
    
      How long until only code signed by Microsoft will be allowed to run on the
      platform? It seems that Microsoft is trying to implement a system that
      will enable them, once and for all, to charge game console-like royalties
      to software developers.
    
    ------------------------------
    
    Date: Fri, 12 Jul 2002 12:59:22 +0100 (BST)
    From: Pete Mellor <pmat_private>
    Subject: More on Palladium
    
    My thanks to the person who sent me the forwarded message below.  (I have
    withheld his name just in case, although the URL he sent is a totally public
    source.)
    
    Please have a look at both of the URLs below.  
    
    My informant is right: if the Cringely article scared you, after reading
    Ross Anderson's contribution, you'll turn green and have to change your
    pants!
    
    PS: It is not made clear in the article, but Ross Anderson is a 
    very highly respected computer security guru at Cambridge University.  
    
    ---------- Forwarded message ----------
    Date: Thu, 11 Jul 2002 19:06:12 +0100
    Subject: more palladium stuff
    
    Dear Colleagues,
    
    As a follow-up of Pete Mellor's mail "Cringely on Palladium ", here's
    another document, which is WAY more scary than what he sent:
    
    http://www.cl.cam.ac.uk/users/rja14/tcpa-faq.html
    
    I think everybody who is involved in computer stuff should read it...
    especially programmers and software developers!!!  This information should
    be spread widely and people should know about it!!!  Forward this to your
    friends!
    
    For those of you, who haven't received Pete Mellor's mail, here's the link
    to the document he sent (you may want to READ IT FIRST):
    
    http://www.pbs.org/cringely/pulpit/pulpit20020627.html
    
    ------------------------------
    
    Date: Thu, 11 Jul 2002 23:35:55 -0400
    From: Monty Solomon <montyat_private>
    Subject: EULA
    
    Excerpt from
         http://www.macintouch.com/toasttitanium3.html
    
    >Date: Wed, 10 Jul 2002s
    >From: [MacInTouch Reader]
    >Subject: Roxio Toast 5.1.4. Update EULA language
    
    Like many people who use a computer daily, I prefer to keep my software 
    up to date. And so I generally utilize updates provided by the various 
    software manufacturers. 
    
    However, given recent reports of Microsoft's impending Palladium 
    technology and its ability to invade a computer at will, I've taken to 
    actually reading the license agreements that one must accept in order to 
    install software or updates. 
    
    Just a few days ago, I retrieved the v5.1.4 update for Roxio's Toast CD 
    mastering software. And was stunned to discovered the following verbiage 
    emplaced within the license agreement's "RESTRICTIONS" section. 
    
    Content providers are using the digital rights management technology ("DRM")
    contained in this Software to protect the integrity of their content
    ("Secure Content") so that their intellectual property, including copyright,
    in such content is not misappropriated. Owners of such Secure Content
    ("Secure Content Owners") may, from time to time, request Roxio or its
    suppliers to provide security related updates to the DRM components of the
    Software ("Security Updates") that may affect your ability to copy, display
    and/or play Secure Content through the Software or other applications that
    utilize the Software. You therefore agree that, if you elect to download a
    license from the Internet which enables your use of Secure Content, Roxio or
    its suppliers may, in conjunction with such license, also download onto your
    computer such Security Updates that a Secure Content Owner has requested
    that Roxio or its suppliers distribute. Roxio and its suppliers will not
    retrieve any personally identifiable information, or any other information,
    from your computer by downloading such Security Updates.
    
    Note that these statements are nestled in the midst of a longer paragraph
    containing the usual stuff about not reverse engineering the software, with
    copy not directly related to these statements preceding and following these
    statements. Almost as if Roxio hoped that this language would not be
    noticed.
    
    I'd suspected something like this might be present within the agreement ever
    since a recent session of burning music CD's from my collection of MP3's,
    using Toast v5.1.3. The last discs I burned play normally, both on my
    computer and in my CD players, but if you put one of them into the
    computer's drive and open it as a data disc, you are presented with a list
    of untitled files, all zero mb in length.
    
    I haven't tried to copy one these discs, as I've no reason to do so as yet.
    And as I still have my mp3 files, I can make another whenever needed.
    
    But with this discovery, I find myself hoping for a viable alternative to 
    Toast. 
    
    Note here that I use an older Mac, a Performa 6360, upgraded with a Sonnet
    G3/320 L2 card. Apple's DiscBurner software will not load, stating that it
    requires a machine with built-in USB capability. I have not been able to
    utilize iTunes' burning capability, either, which requires OS 9.2 and 9.2
    updates refuse to install on my machine.
    
    ------------------------------
    
    Date: Sun, 14 Jul 2002 07:27:32 +0100
    From: Pedt Scragg <bofhat_private>
    Subject: Windows Media Player security update EULA (Re: Tolle, RISKS-22.14)
    
    >  "may disable your ability to copy and/or play Secure Content and use other
    >  software on your computer" is an interesting phrase. If you remove one
    >  item from the sentence it becomes "may disable your ability to
    >  ....................... use other software on your computer".
    
    AV software in case MS accidentally send out another virus, firewalls to 
    allow MSN Messenger et al. free reign?
    
    There is a further risk here in the item that Bill removed from that
    sentence.  For example, updated software looking at software version numbers
    refusing to allow plain text e-mailed content to be 'copied' to the updated
    recipient machine if the source is software which has not been updated to a
    version which included this new bit of the EULA.
    
    A second risk became evident when this new bit of the EULA was discussed 
    in a newsgroup when all the posters after the original article stated 
    they didn't apply any security patches.
    
    ------------------------------
    
    Date: Mon, 8 Jul 2002 08:19:31 -0400 (EDT)
    From: Bill Gunshannon <billat_private>
    Subject: Re: Randomly generated 4-letter words in sendmail ... (Ake, R-22.13)
    
    A more interesting concern is the encoding used by MIME. Things like
    UUencode and BASE64 (and others, I am sure) create extremely large files of
    random (at least as far as language is concerned) letters.  When I search
    some of my saved mail folders I can find pretty much any 3 or 4 letter
    combination.  I have even mentioned in discussions around the department the
    concept that as the number of viruses increases and the amount of encoded
    e-mail increases the number of false positives will also have to increase.
    When you add "dirty word" filtering to the equation matters become much
    worse.  In a system that automatically discards suspect e-mail, this could
    mean a lot of important information not getting through.
    
    Bill Gunshannon, University of Scranton, Scranton, Pennsylvania
    <billat_private>   
    
    ------------------------------
    
    Date: Sat, 06 Jul 2002 17:01:57 -0700
    From: Bill Stewart <bill.stewartat_private>
    Subject: Re: US Navy suffers domain hijacking (Brent, RISKS-22.10)
    
    The United States Post Office is well-known for its confusion about
    whether it wants to be treated as a business or a government agency.
    The Louisiana Attorney General's office, however, by using the domain
    la-ag.com a couple years ago, was clearly stating that it's in business.
    Not sure what business it's in, or what its prices are :-)
    The domain is now owned by some agricultural company, which makes more sense,
    and the LA AG's office is using www.ag.state.la.us/
    
    ------------------------------
    
    Date: Tue, 9 Jul 2002 09:30:50 +0100
    From: "Conor O'Neill" <ONeillCJat_private>
    Subject: Re: US Navy suffers domain hijacking (Ashworth, RISKS-22.13)
    
    Similarly, the UK parliament has a perfectly good Web address:
            http://www.parliament.uk/
    
    but insists on using a .tv suffix for its live video feed:
            http://www.parliamentlive.tv/
    
    Conor O'Neill, Bristol, UK
    
    ------------------------------
    
    Date: Fri, 12 Jul 2002 17:41:09 +0100
    From: Tony Finch <dotat_private>
    Subject: Re: E-mail address parsing (Colburn, RISKS-22.13)
    
      [I have excerpted starkly from an extended exchange between 
      George Roussos and Tony Finch, inspired by Colburn.  PGN]
    
    You should read this in the context of the syntax for domains in RFC
    821 and 822 (or rather 2821 and 2822 if you want to be up-to-date),
    which does not allow a . at the end of the domain.
    
    > In practice, I have not come across a mailer that would not recognise
    > or refuse delivery when the root dot is present, including all versions
    > of exchange (please check this, it is true).
    
    Sendmail and Exim are popular MTAs [that consider the dot invalid].
      [Examples omitted.  PGN]
    Other MTAs might not care if you violate the RFCs.
    
    f.a.n.finch <dotat_private> http://dotat.at/
    
    ------------------------------
    
    Date: Tue, 9 Jul 2002 14:31:27 -0600
    From: Victor the Cleaner <jonathanat_private>
    Subject: Re: FORTH (Simon, RISKS-22.14)
    
    Sadly, as a more recent trend that's true.  For a while, some folks were on
    this track, though.  Back in the early 80s, Rockwell had a couple of parts
    (65F11 and 65F12, IIRC) that had a Forth interpreter in mask ROM; New Micros
    (newmicros.com) still sells a 68HC11 with onboard Forth.  And in the
    late-80s Harris sold a part (licensed from Novix, I think) that was a really
    speedy little thing optimized for Forth (with heavy emphasis on the stack).
    
    More information at:  http://www.ultratechnology.com/chips.htm
    
    In all, though, you're right.  In this business, the elegance of yore tends 
    not to remain in vogue.
    
    ------------------------------
    
    Date: Tue, 2 Jul 2002 07:43:29 -0800
    From: Rob Slade <rsladeat_private>
    Subject: REVIEW: "Digital Signatures", Mohan Atreya et al.
    
    BKDIGSIG.RVW   20020520
    
    "Digital Signatures", Mohan Atreya et al., 2002, 0-07-219482-0, U$59.99
    %A   Mohan Atreya
    %A   Benjamin Hammond
    %A   Stephen Paine
    %A   Paul Starrett
    %A   Stephen Wu
    %C   300 Water Street, Whitby, Ontario   L1N 9B6
    %D   2002
    %G   0-07-219482-0
    %I   McGraw-Hill Ryerson/Osborne
    %O   U$59.99 905-430-5000 +1-905-430-5134 fax: 905-430-5020
    %P   368 p.
    %T   "Digital Signatures"
    
    Although cryptography is generally considered to be useful for hiding
    information or holding it confidential, cryptographic methods can also be
    used to determine whether data has been altered.  Slightly more specialized
    means can also be used to provide evidence that a certain individual
    composed or verified a certain message, in the same way that a handwritten
    signature is presumed to assert a person's intent or agreement with respect
    to a contract.  Properly used and supported, these digital signatures can be
    stronger and more flexible than physical signatures as a means of binding an
    identity to a document.
    
    Chapter one is an introduction, both to some basic concepts, and to the book
    as a whole.  (The material is disjointed in places: there is a section
    entitled "Legislation" on page six and another on page eight, although the
    content is different.)  The overview of cryptography, in chapter two, has
    some very weak and some very good points: the explanation of the four modes
    of DES (Data Encryption Standard) is much clearer than in most texts.  The
    description is, however, very generic, and does not address hash or
    signature topics at all, nor does it address algorithmic and key length
    strength and weakness.  Certificates are a vital part of the common digital
    signature structure, but chapter three's discussion concentrates on X.509
    fields and request procedures, without getting into the underlying concepts.
    Data integrity is another key (sorry) concept in the creation of digital
    signatures, but while the material on checksums and hashing starts out well,
    chapter four ends in something of a confusing mess.  Chapter five flits
    between real and theoretical systems in such a way that no valid assessment
    of uses and shortcomings is possible.  A number of miscellaneous topics are
    listed in chapter six.  Chapter seven looks at various business issues and
    models, generally with respect to public key infrastructure, but is oddly
    unhelpful in real world terms.  Some standards are listed and tersely
    described in chapter eight.  Definition sections lifted from various pieces
    of legislation are reproduced in chapter nine.  Chapter tens lists a number
    of legal concepts that may have a bearing on digital signatures: these are
    more practically related to systems and policies in chapter eleven.
    
    The technical and practical aspects of this book fall far short of being
    useful either to the security professional, or to the manager who may need
    to address the topic or make decisions about systems.  The legal sections,
    however, might justify, for the professional, the purchase of this otherwise
    confused work.
    
    copyright Robert M. Slade, 2002   BKDIGSIG.RVW   20020520
    rsladeat_private  rsladeat_private  sladeat_private p1at_private
    http://victoria.tc.ca/techrev    or    http://sun.soci.niu.edu/~rslade
    
    ------------------------------
    
    Date: 29 Mar 2002 (LAST-MODIFIED)
    From: RISKS-requestat_private
    Subject: Abridged info on RISKS (comp.risks)
    
     The RISKS Forum is a MODERATED digest.  Its Usenet equivalent is comp.risks.
    => SUBSCRIPTIONS: PLEASE read RISKS as a newsgroup (comp.risks or equivalent)
     if possible and convenient for you.  Alternatively, via majordomo,
     send e-mail requests to <risks-requestat_private> with one-line body
       subscribe [OR unsubscribe]
     which requires your ANSWERing confirmation to majordomoat_private .
     If Majordomo balks when you send your accept, please forward to risks.
     [If E-mail address differs from FROM:  subscribe "other-address <x@y>" ;
     this requires PGN's intervention -- but hinders spamming subscriptions, etc.]
     Lower-case only in address may get around a confirmation match glitch.
       INFO     [for unabridged version of RISKS information]
     There seems to be an occasional glitch in the confirmation process, in which
     case send mail to RISKS with a suitable SUBJECT and we'll do it manually.
       .MIL users should contact <risks-requestat_private> (Dennis Rears).
       .UK users should contact <Lindsay.Marshallat_private>.
    => The INFO file (submissions, default disclaimers, archive sites,
     copyright policy, PRIVACY digests, etc.) is also obtainable from
     http://www.CSL.sri.com/risksinfo.html  ftp://www.CSL.sri.com/pub/risks.info
     The full info file will appear now and then in future issues.  *** All
     contributors are assumed to have read the full info file for guidelines. ***
    => SUBMISSIONS: to risksat_private with meaningful SUBJECT: line.
    => ARCHIVES are available: ftp://ftp.sri.com/risks or
     ftp ftp.sri.com<CR>login anonymous<CR>[YourNetAddress]<CR>cd risks
       [volume-summary issues are in risks-*.00]
       [back volumes have their own subdirectories, e.g., "cd 21" for volume 21]
     http://catless.ncl.ac.uk/Risks/VL.IS.html      [i.e., VoLume, ISsue].
       Lindsay Marshall has also added to the Newcastle catless site a
       palmtop version of the most recent RISKS issue and a WAP version that
       works for many but not all telephones: http://catless.ncl.ac.uk/w/r
     http://the.wiretapped.net/security/info/textfiles/risks-digest/ .
     http://www.planetmirror.com/pub/risks/ ftp://ftp.planetmirror.com/pub/risks/
    ==> PGN's comprehensive historical Illustrative Risks summary of one liners:
        http://www.csl.sri.com/illustrative.html for browsing,
        http://www.csl.sri.com/illustrative.pdf or .ps for printing
    
    ------------------------------
    
    End of RISKS-FORUM Digest 22.15
    ************************
    



    This archive was generated by hypermail 2b30 : Sun Jul 14 2002 - 15:11:18 PDT