From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 107f24,582dff0b3f065a52 X-Google-Attributes: gid107f24,public X-Google-Thread: 1014db,582dff0b3f065a52 X-Google-Attributes: gid1014db,public X-Google-Thread: 109fba,582dff0b3f065a52 X-Google-Attributes: gid109fba,public X-Google-Thread: 103376,bc1361a952ec75ca X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2001-08-04 07:13:02 PST Path: archiver1.google.com!newsfeed.google.com!newsfeed.stanford.edu!news.tele.dk!148.122.208.68!news2.oke.nextra.no!nextra.com!news3.oke.nextra.no.POSTED!not-for-mail From: "Tor Rustad" Newsgroups: comp.lang.ada,comp.lang.c,comp.lang.c++,comp.lang.functional References: <3B687EDF.9359F3FC@mediaone.net> <3B6A588C.B67A9CF8@isltd.insignia.com> <9ked6d$mtr$1@nh.pace.co.uk> Subject: Re: How Ada could have prevented the Red Code distributed denial of service attack. MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Message-ID: NNTP-Posting-Host: 148.122.147.228 X-Complaints-To: news-abuse@nextra.no NNTP-Posting-Date: Sat, 04 Aug 2001 16:12:46 MEST Organization: Nextra Public Access X-Trace: news3.oke.nextra.no 996934366 148.122.147.228 Date: Sat, 4 Aug 2001 16:11:08 +0200 Xref: archiver1.google.com comp.lang.ada:11292 comp.lang.c:72101 comp.lang.c++:79912 comp.lang.functional:7299 Date: 2001-08-04T16:11:08+02:00 List-Id: "Marin David Condic" wrote in message > There was code to detect and react to errors. It worked exactly as it had > been planned to work. There wasn't even a "logic error" - the logic was > perfect given the anticipated use of the device. (Having built similar > systems, I can attest to the fact that when certain errors come up, you > have > to make your best guess as to what the cause is likely to be and take some > kind of action that would make sense. This is what the engineers did.) Not quite, it's with high probability a *wrong* conclusion to assume simultanouse HW fault in duplicated/independent HW. As an analogy to the IRS design, cryptographers do design "secure" cryptosystems, which may even be proven correct by formal methods. In the real world it'is still broken, why? One reason can be a change in the environment, [1] discuss this subject and gives an interesting example from a cash machine fraud in Holland (1993-1994). Here, one person wire-tapped the communication between a card reader and the controlling PC, and aswell captured the PIN by just looking. The change in the environment in this case, was that back when the standards for magnetic cards where designed, it was assumed that the card would only be read in a secure environment (e.g. ATM) and the content of the magnetic stripe was not a secret (as the PIN was). The orginal designers didn't forsee the usage of untrusted devices, and nobody in the industry saw this environment change (it happend over multiple years). > I hope this clears things up a little. There always seems to be a lot of > misunderstanding of exactly what went on in this disaster and wherein the > problems came up. Yes. Interesting reading. [1] "Security Engineering" by Ross Anderson. -- Tor "I was a relative latecomer. The earliest date that I am sure I was posting news was in 1984, but it might have been as early as two years before that". - Chris Torek, comp.lang.c 2001-08-02.