[ih] "how better protocols could solve those problems better"

[vinton cerf]

ah, thanks - i was thinking you were referencing Hamming distances...

v


On Thu, Oct 1, 2020 at 12:54 PM Craig Partridge via Internet-history <
internet-history at elists.isoc.org> wrote:

> Actually it is Hammond.  As far as I can tell (from digging through mounds
> of old papers [appropriate for an Internet History list!]), the paper that
> launched CRC-32 as *the* CRC to use was a study by Joseph L. Hammond, J.E.
> Brown and S.S. Liu, "Development of a transmission error model and an error
> control model," Georgia Tech report (as I recall, to AFRL) in 1975.
>
> Craig
>
> On Thu, Oct 1, 2020 at 10:42 AM Vint Cerf <vint at google.com> wrote:
>
> > presumably you meant Hamming not Hammond?
> > v
> >
> >
> > On Thu, Oct 1, 2020 at 11:05 AM Craig Partridge via Internet-history <
> > internet-history at elists.isoc.org> wrote:
> >
> >> Hi John:
> >>
> >> Re: errors.  The short answer is that cryptographic sums are designed to
> >> detect any mangling of data with the same probability.  For error sums,
> >> you
> >> can tune the checksum to the error patterns actually seen.  In my view,
> >> CRC-32 has done so well because Hammond did a really nice analysis for
> >> AFRL
> >> in the early 70s about what kinds of errors were likely on a link.
> Above
> >> the link layer, the indications are that most errors are in the computer
> >> logic of the interconnection devices, and so you see errors of runs of
> >> octets or 16-bit or 32-bit words.  You also see clear cases of pointers
> >> being damaged.  There are classes of checksums that detect those sorts
> of
> >> bursts really well but they are less good on single bit errors.
> >>
> >> Thanks!
> >>
> >> Craig
> >>
> >> On Thu, Oct 1, 2020 at 8:24 AM John Day <jeanjour at comcast.net> wrote:
> >>
> >> > Craig,
> >> > This is interesting.  You are right.
> >> >
> >> > But what I have been trying to find out is what kinds of ‘errors’ the
> >> > cryptographic hashes are design to catch?  And what is their
> undetected
> >> bit
> >> > error rate? And it should be possible to design error codes for
> >> something
> >> > in between, right?
> >> >
> >> > I have always had this fear that we are not using these codes as they
> >> are
> >> > designed to be used and we are just lucky that the media is as
> reliable
> >> as
> >> > it is.  (I always remember that back in the early ARPANET days,
> reading
> >> a
> >> > paper on the error rates and that line from Illinois to Utah had like
> 1
> >> > error a month (or something outrageous like that) while the worst line
> >> was
> >> > Rome, NY (Griffiths AFB) to Cambridge, MA!  ;-)  Of course the
> >> > Illinois/Utah was probably a short hop to Hinsdale and then microwave
> to
> >> > SLC, while the Rome/Cambridge went through multiple COs and old
> >> > equipment!)  ;-)
> >> >
> >> > O, and isn’t this data archive naming problem you have noted the kind
> of
> >> > things that librarians and database people have a lot of experience
> >> with?
> >> >
> >> > Take care,
> >> > John
> >> >
> >> > > On Oct 1, 2020, at 09:50, Craig Partridge via Internet-history <
> >> > internet-history at elists.isoc.org> wrote:
> >> > >
> >> > > On Wed, Sep 30, 2020 at 6:58 PM Joseph Touch <touch at strayalpha.com>
> >> > wrote:
> >> > >
> >> > >>
> >> > >>
> >> > >>> On Sep 30, 2020, at 4:58 PM, Craig Partridge via Internet-history
> <
> >> > >> internet-history at elists.isoc.org> wrote:
> >> > >>>
> >> > >>> I've got some NSF funding to figure out what the error patterns
> are
> >> > >>> (nobody's capturing them) with the idea we might propose a new
> >> checksum
> >> > >>> and/or add checkpointing into the file transfer protocols.  It is
> >> > little
> >> > >>> hard to add something on top of protocols that have a fail/discard
> >> > model.
> >> > >>
> >> > >> We already have TCP-MD5, TCP-AO, TLS, and IPsec.
> >> > >>
> >> > >> Why wouldn’t one (any one) of those suffice?
> >> > >>
> >> > >
> >> > > Actually no.  These are security checksums, which are different from
> >> > error
> >> > > checksums.  The key differences are:
> >> > >
> >> > > * Security checksums miss an error 1 in 2^x, where x is the width of
> >> the
> >> > > sum in bits.  Error checksums (good ones) are designed to catch 100%
> >> of
> >> > the
> >> > > most common errors and miss other errors at a rate of 1 in 2^x.  So
> a
> >> > > security checksum is inferior in performance (sometimes
> dramatically)
> >> to
> >> > an
> >> > > error checksum.
> >> > >
> >> > > * Security checksums are expensive to compute (because they assume
> an
> >> > > adversary) and so people tend to try to skip doing them.  Error
> >> checksums
> >> > > are easy to compute.
> >> > >
> >> > > Currently the best answer is that for data transmission (e.g. TCP
> >> > segments)
> >> > > you need an error checksum.  At a higher level you do the security
> >> > checksum.
> >> > >
> >> > > Craig
> >> > >
> >> > >
> >> > > --
> >> > > *****
> >> > > Craig Partridge's email account for professional society activities
> >> and
> >> > > mailing lists.
> >> > > --
> >> > > Internet-history mailing list
> >> > > Internet-history at elists.isoc.org
> >> > > https://elists.isoc.org/mailman/listinfo/internet-history
> >> >
> >> >
> >>
> >> --
> >> *****
> >> Craig Partridge's email account for professional society activities and
> >> mailing lists.
> >> --
> >> Internet-history mailing list
> >> Internet-history at elists.isoc.org
> >> https://elists.isoc.org/mailman/listinfo/internet-history
> >>
> >
> >
> > --
> > Please send any postal/overnight deliveries to:
> > Vint Cerf
> > 1435 Woodhurst Blvd
> > McLean, VA 22102
> > 703-448-0965
> >
> > until further notice
> >
> >
> >
> >
>
> --
> *****
> Craig Partridge's email account for professional society activities and
> mailing lists.
> --
> Internet-history mailing list
> Internet-history at elists.isoc.org
> https://elists.isoc.org/mailman/listinfo/internet-history
>