Text 25981, 107 rader
Skriven 2006-02-27 21:18:00 av Michiel van der Vlist (2:280/5555)
  Kommentar till text 25960 av Dale Shipp (1:261/1466.0)
Ärende: Elist mergers
=====================
 >>   It is annoying behavior by definition of P4, section 2.1.4. unless
 >>   all links in the chain have given express permission.

 >>   The two reasons that I can think of it being annoying are that

 >>   a. the sysop who the mail is passing through cannot verify
 >> (if need be) that the mail does not contain illegal or commercial
 >> traffic. That is the reason given by P4.

 MVDV>> A bogus argument.

 >    Tell that to the author's of P4

Unfortunately none of them is around any more. I sure would have a few things
to say to them.

 > and to those who are charged with enforcing it.  In some sections,
 > it would seem to be putting a burden onto the sysop to not participate
 > in the transmission of illegal or commercial activities.

The makers of P4 obviously did not think it through. There are ways of
encryption that are not detectable as such.

 > In other places, it would seem that the sysop is only liable to
 > fidonet if such mail originates on their system,
 >    i.e. from a user, point or gateway.

Well, unlike some, I never held the makers of P4 to be of infinite wisdom. Some
parts of P4 contradict each other and other parts just make little sense at
all. Also the makers of P4 were not clearvoyant.


 MVDV>> The sysop has no need to verify hat other than for
 MVDV>> satisfying his own curiousity. In fact a common legal
 MVDV>> opinion holds that you can not be accountable for what you
 MVDV>> do not know, but if you DO check, you better make sure you
 MVDV>> miss nothing, or else you can be held accountable for
 MVDV>> missing it. And since there is no way to guarantee you miss
 MVDV>> nothing, it is safer not to attempt to check at all. By this
 MVDV>> reasoning one should one should refuse to route all mail
 MVDV>> /unless/ it is encrypted.

 >    I've heard that argument applied to ISPs.  It has merit.

Of course it has merits.

  >>   b. Encryption methods may well expand the message considerably.

 MVDV>> Another bogus argument.

 >    Expansion from 8 characters to 1000+ is not trivial.

But not a realistic example either. Using PGP to just encrypt an 8 character
password is an overkill. Simply x-oring the lower 6 bits of each character with
a 48 bit key is just as secure and will not make it longer.

 >> For example, to send an 8 character password encrypted using
 >> a PGP public key of the receiver, one would need to send more
 >> than 1000 characters.

 MVDV>> PGP has build in compression. For very short messages, the overhead
 MVDV>> makes the  encrypted version longer than the original. For longer
 MVDV>> messages it actually gets shorter because the compression
 MVDV>> take the upper hand. I tested this out many years ago for
 MVDV>> messages ranging from less than 1 100 bytes to messages of
 MVDV>> hundreds of kilobytes. If I remember correctly for PGP 2.6
 MVDV>> the turnover point was around 600 to 700 bytes and for very
 MVDV>> long messages their was some 30% gain.

 >   Reason for that is that there is a fixed overhead based on
 > the number of recipients (which is a reason that PGP does not scale
 > well to messages sent to a large number of recipients).

I have some difficulty imagining why anyone would want to send an encrypted
message to a large number of people. If more than five people know about the
"secret" it will be public knowledge soon enough is my experience.

 > As you say, you gain on message length (at least for the typical
 > fidonet message) as a result of the compression.  Eventually,
 > with long messages that compression overtakes the fixed overhead.

Turn over point around 6 or 700 bytes.

 >   In normal fido traffic you get that savings by the usual
 > compression done.

Netmail is not usually compressed. Many sysops do not process compressed mail
from an unsecure link.

 > Compression algorithms applied *after* encryption will not
 > compress because of the random looking nature of the
 > enciphered message.

It will compress, but not as good as clear text.

 > PGP (and some other encipherment programs) compensate for
 > that by compressing before encryption.

PGP was not designed with FidoNet in mind. In fact the makers may never have
heard of FidoNet. Compression is the exception rather than the rue in the
InterNet, so no, I donlt think it was done to "compensate" for the reduced
compressability.

Chers, Michiel

--- Buy Danish
 * Origin: http://www.vlist.org (2:280/5555)