News is broken and needs to be redesigned/reimplemented.
Robert Withrow
to be redesigned and reimplemented with the goals of security and
athenticity built in. It should be designed so that forgeries,
sendsys bombs, and now cancel automatons are impossible.
The last time I said this Henry (or was it Geoff) said I was
overreacting. What do *you* think... I think that we have
not yet reached the creshendo of this netfoolishness and it
will only get worse until it is fixed.
P.S. Eric R.: I am *not* predicting the ``end of USENET''. If
inefficiency and insecurity were enough to cause something to die
organized government would have ceased to exist long ago... ;-)
--
---
Robert Withrow, R.W. Withrow Associates, Swampscott MA 01907 USA
Tel: +1 617 598 4480, Fax: +1 617 598 4430, Net: wi...@rwwa.COM
Curt Welch
>I've said it before and I'll say it again: News is broken and needs
>to be redesigned and reimplemented with the goals of security and
>athenticity built in. It should be designed so that forgeries,
>sendsys bombs, and now cancel automatons are impossible.
What you want is mostly impossible. The great thing about Usenet
is that no one person can control it. There's no way to implement
authentication and security without giving up that freedom.
If you want authentication and security, try Prodigy or Compuserv.
If you want real freedom, use Usenet and live with the problems.
The benefits are well worth the problems.
There's no solution to the forgeries problem other than the
one that's already in place. Forgeries can always be traced
back to the source as long as it's done before the articles
expire and as long as the sysadmins are willing to help. If the
forgeries become a problem, and if the sysadmin of the system
responsible won't help, then their neighbors will cut them off
from the rest of the net. We don't need a better solution than
this.
Sendsys bombs are a problem. As the net continues to grow, these
type of things will become harder to control - and more serious.
But the solution is both obvious and simple. Stop responding
to sendsys requests. The more problems we have with sendsys bombs,
the more systems we will have that no longer respond to them.
This cancel daemon is an interesting problem. I think in the long run,
this type of problem might be solved like the sendsys problem. We will
have to turn off the cancel feature. In the short term, it's just
another form of the forgery problem, and is dealt with the same way.
But it occurs to me that there is a redesign solution to the cancel
problem. You could add an encrypted password to every message. For
example, generate a random 8 digit password every time you post a
message, run it through the Unix password encryption algorithm, and
include the encrypted version in the message. The cancel message would
then include the plain-text password. Systems would not process cancel
messages unless they included a valid password.
This system would also be easy to phase in over time. If the original
message being canceled didn't have a Cancel-Key: header, then the
cancel message wouldn't need the Cancel-Password: to work.
And these extra header lines wouldn't bother any of the current systems
(I don't think).
The hardest part of implementing this would be figuring out how and
were to store the passwords for all local postings. You probably don't
want the user to make up passwords. You want the system to generate
the passwords and store them on the local system. This makes the
passwords more secure and makes it easier for the user. The system
would then retrieve the password when the user generates a cancel
message. They should probably be stored in the history file as an
extra field. This way, they are removed when the information about the
article is removed from the system.
The problem with storing the password in the history file is that anyone
on your system can read them. But this shouldn't be a big problem. If
you want more security, then you could store them under the users account
in a file - but you would then have the problem of not knowing when to
throw out the information about the old postings. But then again, you
can save the article date and the expires date in this file and just
remove them based on that.
Yes, I think this just might work. But is it really needed? I think it
would be a nice improvement. I'll probably add it to our local news
system unless someone points out a flaw in my thinking.
And is the Unix encryption algorithm good enough? Breaking 8 character
randomly generated passwords is a lot harder than breaking real passwords.
And even if you could break the password for one posting, it would only
allow you to cancel that posting. I think the Unix encryption algorithm
probably is good enough for this, and it's nicely available on all the Unix
system.
What should the new header lines be called?
Curt Welch
cu...@oasys.dt.navy.mil and
cu...@kcwc.com
Henry Spencer
>I've said it before and I'll say it again: News is broken and needs
>to be redesigned and reimplemented with the goals of security and
>athenticity built in. It should be designed so that forgeries,
>sendsys bombs, and now cancel automatons are impossible.
Tom Limoncelli has already done such a wonderful job of responding to
this that I'm tempted to just keep my mouth shut. :-) I will content
myself with observing: it's hard, it creates as many problems as it
solves, and it would take a long time to show results.
Henry Spencer
>Sendsys bombs are a problem. As the net continues to grow, these
>type of things will become harder to control - and more serious.
>But the solution is both obvious and simple. Stop responding
Then you screw the mapmakers... and if you do it at a single isolated
site, it simply doesn't help the fight against sendsys bombing much.
The Performance Release of C News contains a reasonable first step against
sendsys bombing: delayed replies.
>This cancel daemon is an interesting problem. I think in the long run,
>this type of problem might be solved like the sendsys problem. We will
>have to turn off the cancel feature...
Unfortunately, there are some situations -- notably inadvertent serious
copyright violations -- where it is necessary and urgent to cancel an
article.
>... it occurs to me that there is a redesign solution to the cancel
>problem. You could add an encrypted password to every message...
Cryptographic-signature authentication is indeed what is needed to
solve the problem. Unfortunately, it's expensive, awkward to implement,
and beset with legal difficulties.
The idea is not new; there was even a paper on it one or two Usenixes ago.
>For example, generate a random 8 digit password every time you post a
>message, run it through the Unix password encryption algorithm...
Nope, nope, this definitely will not do. The password algorithm is now
quite vulnerable to brute-force searches... and by the way, getting a
really *random* password is not easy. Using something obvious like time
of day or process ID makes the brute-force-search process much easier.
And even the Unix password algorithm, by the way, suffers from the
idiocies of the US government.
--
There is nothing wrong with making | Henry Spencer @ U of Toronto Zoology
mistakes, but... make *new* ones. -D.Sim| he...@zoo.toronto.edu utzoo!henry
Brad Templeton
>Nope, nope, [cancel-passwords] definitely will not do. The password
>algorithm is now
>quite vulnerable to brute-force searches... and by the way, getting a
>really *random* password is not easy. Using something obvious like time
>of day or process ID makes the brute-force-search process much easier.
>And even the Unix password algorithm, by the way, suffers from the
>idiocies of the US government.
Be serious, Henry. We're not talking national security. If it takes
a week of CPU time to forge a cancel for my message, I'm not quaking
in my boots with fear.
--
Brad Templeton, ClariNet Communications Corp. -- Sunnyvale, CA 408/296-0366
Brad Templeton
bit of discussion in the various groups.
But nobody's done anything about it.
The answer is that if you want cancel passwords, you'll have to implement
them. That's the only way anything gets done on USENET. Do it, don't
talk about it.
I pointed out back then the flaw in my own scheme. The concept of
a cancel daemon *is* useful for things like renaming groups, deleting
groups, post-moderating groups and yes, even the legitimate control of
crossposting. (For example, if the charter of alt.cascade had read,
"cascades are not to be crossposted to other groups" then a properly
working cancel-daemon would be appropriate.)
Cancel passwords would make all this difficult or impossible.
no
Curt Welch
cancel passwords):
>That's an old solution -- I thought it up a few years ago and it got a
>bit of discussion in the various groups.
It seemed like an idea that someone else should have already thought up.
>But nobody's done anything about it.
>The answer is that if you want cancel passwords, you'll have to implement
>them. That's the only way anything gets done on USENET. Do it, don't
>talk about it.
I think I will. It will be interesting to see just how much code it
takes.
>I pointed out back then the flaw in my own scheme. The concept of
>a cancel daemon *is* useful ...
>Cancel passwords would make all this difficult or impossible.
Yes, after thinking more about it I think this is probabably the case.
The cancel password scheme would work fine, but it might well
cause more problems than it would solve. For example, you wouldn't
be able to cancel a forgery that was sent out in your name. Or
if your system lost the passwords, you wouldn't be able to cancel your
own message.
But yet, it just seems wrong that the news system gives anyone on
the net the power the censor any post they don't like. They should
have the right to remove any message they don't like from their
own system, but being able to remove it from most systems on the
net by sending out a fake cancel messages just seems wrong.
Your example of using a cancel daemon to combat some problems, like
incorrect use of cross-posting, is valid. But this type of thing
would be better done with the use of news filters installed by
the news admins. If most the major news systems had an easy way
to install kill files or news filters to remove un-wanted traffic
from their system, then the problem messages would get killed if there
was really a group consensus the they were a problem.
As it is now, any one person can decide that something is wrong and
set up a cancel daemon. Of couse if there is a group consensus
that this daemon was "bad", then the net would rise up against the
person (like it just did) and stop them.
The net does take care of itself without the use of cancel passwords,
but maybe having cancel passwords would make it a better place?
As I said, I'll look into adding this so anyone that wants to try it
out can. Brad's right, these things don't get done by talking about
them.
Curt
Henry Spencer
>>Nope, nope, [cancel-passwords] definitely will not do. The password
>>algorithm is now
>>quite vulnerable to brute-force searches...
>
>a week of CPU time to forge a cancel for my message, I'm not quaking
>in my boots with fear.
Be serious, Brad. Maybe on an 11/70 it would have taken a week. Not
any more. Remember, the existing message headers tell you the time
down to the second plus the process ID of the poster, and the password-
generating algorithm must be assumed to be known. That brute-force
search doesn't need to be all that lengthy, especially since the Unix
password algorithm is not very expensive to run.
Note that Brad's abstracting in [] is wrong. I didn't say that the whole
approach wouldn't do; I said that using the Unix password algorithm
wouldn't do. Something like DES or MD5 probably would.
The hard part, actually, is generating a whole bunch of random bits as
the password. Portably. Without using either the time of day (down to
the second) or the process ID. Without using the password from a previous
article as a starting point (because then breaking one article with a
lengthy brute-force search gives you the rest from that site). Without
using anything else already available in the article, like user's name.
One thing Geoff and I decided long ago was that we weren't going to put
a lot of time and effort into implementing and supporting any "security"
measures that can be subverted easily.
Cryptographic authentication *is* what's wanted. At present, there are
some implementation difficulties with doing it right, and half-hearted
versions aren't going to accomplish much.
Peter da Silva
>to be redesigned and reimplemented with the goals of security and
>athenticity built in. It should be designed so that forgeries,
>sendsys bombs, and now cancel automatons are impossible.
Then do it. Design and implement secure news. Since TCP isn't entirely
secure, you'll have to add some authentication protocol on top of that.
Since UUCP is spoofable, you'll need to use it there as well. It's not
going to be easy.
If it works we'll all switch over. If it doesn't we'll have learned
something.
But you can't get there from here.
--
`-_-'
Have you hugged your wolf today? 'U`
Peter da Silva, Taronga Park BBS, Houston, TX +1 713 568 0480/1032
Terry Poot
In article <21...@oasys.dt.navy.mil>, cu...@oasys.dt.navy.mil (Curt Welch)
writes:
>But it occurs to me that there is a redesign solution to the cancel
>problem. You could add an encrypted password to every message. For
>example, generate a random 8 digit password every time you post a
>message, run it through the Unix password encryption algorithm, and
Is this PD? Can it be exported and implemented on non-unix systems? Is there
_any_ useable technology that doesn't cause problems with US export controls?
>include the encrypted version in the message. The cancel message would
>then include the plain-text password. Systems would not process cancel
>messages unless they included a valid password.
>
>This system would also be easy to phase in over time. If the original
>message being canceled didn't have a Cancel-Key: header, then the
>cancel message wouldn't need the Cancel-Password: to work.
>
>And these extra header lines wouldn't bother any of the current systems
>(I don't think).
>
>The hardest part of implementing this would be figuring out how and
>were to store the passwords for all local postings.
Not good. What if the storage mechanism fails and loses the password? You can't
cancel. And as has been pointed out, there are situations where it is important
to be able to cancel an article.
>You probably don't
>want the user to make up passwords.
Also true. They'll forget them.
>You want the system to generate
>the passwords
Yes.
>and store them on the local system.
No. Use some algorithm such that the password can be regenerated by the posting
system. Perhaps have the sysadmin set a base password, not known to users, and
let him change it as often as he wishes (the system would record past
passwords). This would be combined in some non obvious way, like a hash code,
with the message-id to produce the unencrypted password. Thus the sysadmin could
cancel every article coming out of his system, which I think is good. Other
users on the same system could maybe forge cancels for articles posted from
there, but I don't think that's a big problem.
BTW, since the sysadmin sets the base password, if the password storage fails,
he at least has a chance to remember what his previous passwords were.
>I think the Unix encryption algorithm
>probably is good enough for this, and it's nicely available on all the Unix
>system.
So what about the rest of us?
--
Terry Poot <t...@mccall.com> The McCall Pattern Company
(uucp: ...!rutgers!depot!mccall!tp) 615 McCall Road
(800)255-2762, in KS (913)776-4041 Manhattan, KS 66502, USA
Rob Stampfli
cannot cancel an issued message (other than locally):
Description:
1. Modify Cnews so that the "Date:" field on the message is used as INPUT
to a pre-agreed-to encryption mechanism -- say DES -- for each article
posted. The originally generated Message-ID will be used as the KEY,
and the OUTPUT of the encryption will be permuted so as to be printable,
and of a uniquely specified format. This output will be used as the
prefix (what comes before the '@' sign) of the "Message-ID:" field which
becomes part of the message header. The original Message-ID will be kept
in the issuing site's history file, but will not be part of the message.
(This should not break the history mechanism, as the issuing site's name
is in the "Paths:" field, so the message should never be fed back to the
site. Externally, the message will be known by its permuted Message-ID.)
Note that the originally generated Message-ID should not be easily
guessable, and should contain pseudo-random information, like the PID,
PPID, and/or times(2) output, which would guarantee uniqueness, but not
be derivable by the outside world. For other reasons, the current Cnews
attempts to do this, but this may have to be beefed up.
2. To generate a legitimate cancel message, the original Message-ID, as
stored in the issuing site's history file, will be appended to the
cancel message as the "Approved:" field. The "Control:" field will
contain the word "cancel" and the permuted Message-ID of the message to
be cancelled, taken from the body of the message itself, as it exists
on the issuing site.
3. When a site receives a cancel control message, it will first check to
see if the cancelable message is present. If not, it just passes the
cancel message along as it does now. If the message is present, and the
Message-ID given in the "Control:" field matches the unique format of a
permuted Message-ID, then the "Date:" field of the original message is
encrypted, using the "Approved:" field of the cancel message as the key,
and the results are compared with the "Message-ID:" field of the original
message. If they match, the cancel is deemed genuine, the message is
deleted locally, and the cancel message propagated. If they don't match,
the cancel message is deemed invalid, and it is neither honored nor
propagated.
Comments:
This mechanism has the attributes of being downward compatible with the
existing software, and requiring no new fields in the message headers
(except for an additional "Approved:" field in the cancel message). It
also has the feature of being effective, even if a significant portion
of Usenet is not using it, since once the main sites convert to it, bogus
cancel messages are not propagated very far. The main drawbacks are that
(1) anyone at a site issuing a message can theoretically forge a cancel
message, but this can be minimized by using the methods in existance
today, and (2) there is a slight chance that the permuted Message-IDs
will not be unique. This can be circumvented by combining non-encrypted
information, such as date artifacts, with the output of the encryption
when forming the permuted Message-ID field. (3) An encryption mechanism
will have to be made part of Cnews. This will increase the size of the
Cnews package, but Phil Karn has written an excellent public-domain DES
implementation that can be used and would undoubtedly be beneficial as
a standard for other uses. I am not familiar with Canadian laws on the
exportation of encryption software, but since Cnews is a product of
Canada, the assinine US laws on the subject could be ignored.
--
Rob Stampfli res%kd...@n8emr.columbus.oh.us The neat thing about standards:
614-864-9377 HAM RADIO: kd...@n8jyv.oh There are so many to choose from.
Felix Lee
stop sendsys/newgroup bombers, since it would no longer possible for
anyone to cancel these messages without the right cookie. A simple
fix is to make control messages exempt from cancel-authentication.
However, once control messages become authenticated, you no longer
want random people to be able to cancel trusted control messages, so
there needs to be a simple way of switching this behavior.
A related problem is a copyright violation would have to be cancelled
by the poster, or maybe the poster's sysadmin, which isn't always
feasible. This can be fixed once control messages become
authenticated: let cancel messages from trusted sources bypass the
cancel-authentication.
--
John Stanley
> The originally generated Message-ID will be used as the KEY,
> and the OUTPUT of the encryption will be permuted so as to be printable,
> and of a uniquely specified format.
Problem 1: there currently is NO specified format for the "prefix" part
of the Message-ID, thus you can't specify a unique format for the secure
form. I.e., the prefix can look like anything, so identifying it as
secure by how it looks is not possible. Solution? Change the RFC's and
break every news package other than the one that you decide to use as
the specification for the unique, non-encrypted message ID's.
> The original Message-ID will be kept
> in the issuing site's history file, but will not be part of the message.
Problem 2: not all sites have history files. Ok, save it somewhere, not
necessarily the history file.
>2. To generate a legitimate cancel message, the original Message-ID, as
> stored in the issuing site's history file, will be appended to the
> cancel message as the "Approved:" field.
Problem 3? Isn't there software that requires the Approved: header to
honor a cancel? Maybe not, but I thought I heard that there was.
> message. If they match, the cancel is deemed genuine, the message is
> deleted locally, and the cancel message propagated. If they don't match,
> the cancel message is deemed invalid, and it is neither honored nor
> propagated.
Problem 4: any non-secure site that tries to cancel one of its own
messages will get that cancel propogated no further than the first
"secure cancel" site, since it will most likely not have an Approved:
line to use to match against, or will have one that doesn't encrypt to
match the Message-Id:. Might as well turn cancel off altogether.
> This mechanism has the attributes of being downward compatible with the
> existing software,
Sorry. No. Maybe "existing C-News software", but the world is not
just C-News.
> It
> also has the feature of being effective, even if a significant portion
> of Usenet is not using it, since once the main sites convert to it, bogus
> cancel messages are not propagated very far.
Neither will cancels from existing software.
> (3) An encryption mechanism
> will have to be made part of Cnews.
And B-News, and Waffle, and UUPC, and every other news software
package.
Brad Templeton
does not need to be too secure. Even something that took an hour to break
on a fast CPU would prohibit the sort of thing we've seen here.
I am sure that you can find a variety of things worthy of use as random
seeds on any given system. If you have the time to better than a second,
you can of course use those fractional seconds, and the lower 7 bits of
the process ID, and a few random words from rapidly changing areas in the
kernel as provided by a simple program with memory-read permissions.
Brad Templeton
moderator of a moderated group to cancel any article in that group,
in particular ones not generated by the moderator.
When people get clever and decide they will post their own article
to RHF, I have no choice but to cancel such items quickly, otherwise
my mailbox fills up with readers saying, "have you seen this strange
article that didn't come from you..."
(If there are 200,000 readers, and 1% of them decide to inform you,
that would be 2,000 mail messages. Fortunately this doesn't happen, but
you get the picture.)
Jamie Andrews
>"cascades are not to be crossposted to other groups" then a properly
No no Brad, this is the Brave New 1992 Usenet, where if
you cancel anyone's article, for any reason, they net.keelhaul
you for violating their "first amendment rights". (1/4 :-))
--Jamie.
Jim Mercer
>to be redesigned and reimplemented with the goals of security and
>athenticity built in. It should be designed so that forgeries,
>sendsys bombs, and now cancel automatons are impossible.
if you want security and authentication, subscribe to compuserv, or buy
several magazine subscriptions.
USENET works, leave it alone.
--
[ Jim Mercer Reptilian Research me...@iguana.reptiles.org +1 519 893-6085 ]
[ I don't want to work for a company that has a CIO. ]
[ Disclaimer! I don't need no stinking Disclaimer! ]
Curt Welch
>Be serious, Brad. Maybe on an 11/70 it would have taken a week.
Be serious Henry, it takes years even on a Cray, or with a
building full of Sun systems to search the entire Unix password space.
Like Brad is trying to point out, if it takes them more than an hour,
the scheme will be workable.
Your point is quite valid however. If you don't do a good job of
generating the password, then it will be easy to break. Using only the
process ID and the clock isn't very secure, (since the cracker knows the
time and process ID from the message ID).
But there are lots of easy ways to generate the password. Unix
passwords are about 56 bits. The trick is to find at least 56 bits of
mostly non-related information that the cracker doesn't have access to,
and use that to generate the password. The millisecond time information
will give you about 6 bits. Many systems have microsecond clocks that
would be a source for about 32 random bits (but would not be portable.)
Remember that these passwords only have to be generated when an article is
posted, not when it's received or transported, so speed isn't as critical
as it is in other parts of the news system.
A good source of random bits can be gotten by doing stats on files.
The modification dates, length, and inode number, can be good values to
use. The trick to making the code portable is to find files
that the cracker can't guess the values of. Because we are talking
about the news system, then the news files are one place to look. If
you use the dates, length, and inode number of the standard news files
like the sys file, the active file, the log file, and history file, and
the /usr/lib/news directory. Because these files change every few
seconds, their modification times aren't too useful, but the other
numbers will give you about 10 good random bits per file. And because
these files change when you post an article, their inodes will
mostlikely be in core so this will be fast. You can throw in a few
other files as well like '/' and the user's home directory and his
.newsrc file, and the password file and the programs current working
directory ("").
If you have access to the machine the messages was posted on, then you
could drastically reduce the search space, but for most of the net, this
technique will make cracking the password a 100 year CPU problem. Well
over the 1 hour required.
On top of this, my current thinking on how I was going to implement the
passwords was to have the newsreading program generate them.
Because all posting is done from within my newsreader, I have lots
of random bits to work with. In my news reader, I can use the process
ID because you don't know how long the program was being used before
they posted. And the editing of the posting is done from within the
newsreader, so you can save the time before and after posting and get a
few more bits of random info this way. And my newsreader program has a
copy of the user's .newsrc in memory, a copy of the active file, and a
copy of the subject lines from every article they have read. All this
is a great source for random bits, all in core in the program that's
generating the password.
If you are careful, I don't think it will be hard to generate a good
random password that will provide more than enough security when using
the Unix password algorithm.
>That brute-force
>search doesn't need to be all that lengthy, especially since the Unix
>password algorithm is not very expensive to run.
The best I've seen is on the order of 1000 crypts per second (without
hardware support), with today's technology.
Assuming the password only ends up with 45 random bits (instead of 56),
then it would take (2^45 / 1000) / 2 seconds on the average to crack.
This is over 1000 years. If the CPU power of systems increases by
a factor of 10 every 10 years, this still gives you 50 years before
the crack time gets down to under a week.
And we don't need "real" security. We are just trying to increase the
cost of canceling an article that you didn't post. I think this
scheme would provide plenty of increased cost with a reasonable
implementation cost.
>One thing Geoff and I decided long ago was that we weren't going to put
>a lot of time and effort into implementing and supporting any "security"
>measures that can be subverted easily.
That's a wise decision.
>Cryptographic authentication *is* what's wanted.
Yes, cancel passwords only address the small problem of forging cancel
messages, it doesn't do anything for helping out the general
authentication problem.
I'm not trying to presure you guys into implementing cancel passwords.
You've done more than your share for the net already. If I can't find
the time to write my own implementation, then I don't expect you to do it.
If I (or someone) writes the code, and supplies the needed patches to C
news, etc, and if a large majority of the net decides they like it and starts
using it, then I would hope you would include it. Until then, the ball's
in my court.
Curt Welch
Henry Spencer
>I know you were talking crypt, Henry, but the point is that such a system
>does not need to be too secure. Even something that took an hour to break
>on a fast CPU would prohibit the sort of thing we've seen here.
Today, an hour. Next year, five minutes. It doesn't prohibit it for long.
And the original proposal wasn't something that would take a CPU hour to
break, either.
>I am sure that you can find a variety of things worthy of use as random
>seeds on any given system. If you have the time to better than a second,
>you can of course use those fractional seconds, and the lower 7 bits of
>the process ID, and a few random words from rapidly changing areas in the
>kernel as provided by a simple program with memory-read permissions.
I'm not so sure. Fractional time, yes... but that only gives you five
or six bits on a lot of systems. The process ID of inews (etc) is in the
message ID for most modern news systems, so this contributes either no
bits (if inews is all one process) or only two or three (if it's more
than one and hence the key bits have a small offset from the inews pid).
And I don't know about your site, but programs from the net do *not*
get memory-read permissions on zoo -- a portable news system really
can't depend on access to such a high level of privilege.
Robert Withrow
| USENET works, leave it alone.
Right. Especially if by work you mean cancel wars, sendmail bombs, etc.
Kyle Jones
> The hard part, actually, is generating a whole bunch of random
> bits as the password. Portably. Without using either the
> time of day (down to the second) or the process ID. Without
> using the password from a previous article as a starting point
> (because then breaking one article with a lengthy brute-force
> search gives you the rest from that site). Without using
> anything else already available in the article, like user's
> name.
Don't make things so hard. C news itself wasn't hatched full
blown overnight. The first itieration of the system should be to
just let the user type a password for his/her article. The
article's security will be in his or her hands. The user can
pick a different passwrod for every article, or use the same one
over and over.
More complicated system can be implemented by sysadmins and/or
users who want such things.
> One thing Geoff and I decided long ago was that we weren't going to put
> a lot of time and effort into implementing and supporting any "security"
> measures that can be subverted easily.
Fair enough.
> Cryptographic authentication *is* what's wanted. At present, there are
> some implementation difficulties with doing it right, and half-hearted
> versions aren't going to accomplish much.
Sure they will. They'll give us valuable experience so that we
can do better the next time. We may very well find that a very
naive security system will be enough to discourage the majority
of cancel forgers. The important thing is that the system be
open-ended so that new encryption methods can be incorporated
into the system. (e.g. the proposed Cancel-Key header would have
key type field that speciifed the encryption method to use.)
Peter da Silva
>Be serious, Brad. Maybe on an 11/70 it would have taken a week. Not
>any more. Remember, the existing message headers tell you the time
>down to the second plus the process ID of the poster,
Only if you've left the original message-id generating mechanism in place.
By inspection I can tell that *you've* already changed it.
>and the password-
>generating algorithm must be assumed to be known.
Why? It can be dynamically changed on a site-by-site basis. You could, for
example, have the installer add an absolute and relative bias to these
numbers. You can have them also select the alphabet for the message ID
*and* password generation. You can bias the password with the checksum of
the last 10 lines in /usr/lib/news/log and /etc/utmp. Run "ps" and generate
a checksum of the result. There are LOTS of sources of randomness in a
UNIX system.
Kyle Jones
> One minor problem with cancel-authentication is it makes it harder to
> stop sendsys/newgroup bombers, since it would no longer possible for
> anyone to cancel these messages without the right cookie. A simple
> fix is to make control messages exempt from cancel-authentication.
>
But how are we going to do this? Pardon me if I missed the
discussion, but going on what I've read so far the cancel message
key/password approach won't work with newgroup, rmgroup, sendsys,
and senduuname.
Felix Lee
> However, once control messages become authenticated, [...]
Kyle Jones:
> But how are we going to do this? Pardon me if I missed the
No way in particular. I was just noting that cancel-authentication
will have to adapt when/if control message authentication happens.
--
Jerry Aguirre
>I'm not so sure. Fractional time, yes... but that only gives you five
>or six bits on a lot of systems. The process ID of inews (etc) is in the
One very large amount of dynamically changing pseudo random data that
is guaranteed available and readable on the posting system is the news
spool itself. Use the PID and fractional time to select some index
into the news system and then generate a hash based on that. This
could envolve something as simple as reading the directory of the news
group to be posted to and hashing that. Remember that article
numbering is local to every system and even if started in sync quickly
drifts out of sync. Or one could get complicated and use the PID to
select the Nth newsgroup and the time to select the Nth article and
then hash that article into a key.
Or just hash the last article listed in the history file. Or grab the
last N bytes from the history file, or ... There are a lot of
posibilities. One can easily generate a key as long as desired.
Granted some of this can be reproduced by someone with access to that
system but that can be considered a feature. Besides, if bogus cancels
are coming from the same system then that is an internal problem.
Now, for a minor nit no one seems to have considered. Suppose the
cancel arrives before the article. There is no key available to compare
to so there is no way to validate the cancel. Currently news marks the
article as "received" in the history so if it subsequently arrives it
will be rejected as a duplicate.
With cancel authentication we have to keep track of such cancels until
the article arrives and then when it arrives find the correct cancel and
check the key. The details of implementing this is left as an exercise
for the reader. :-)
Jerry
Felix Lee
> Now, for a minor nit no one seems to have considered. Suppose the
> cancel arrives before the article.
Yes. This is a minor complication. The straightforward way of
implementing this in C News requires the ability to update records in
the history database. (This is something I've been meaning to try to
implement. Real Soon Now...)
--
Henry Spencer
>>... Remember, the existing message headers tell you the time
>>down to the second plus the process ID of the poster,
>
>Only if you've left the original message-id generating mechanism in place.
>By inspection I can tell that *you've* already changed it.
We've changed the encoding, not the contents. There's still a date and
a pid in there. There really isn't any other good, portable, robust way
of getting a guaranteed-unique identifier.
>>and the password-
>>generating algorithm must be assumed to be known.
>
>Why? It can be dynamically changed on a site-by-site basis...
The algorithm must be assumed to be known, since the overwhelming majority
of sites will not locally modify it. It may have site-specific components,
but a would-be forger only has to solve for those once per site. (This
would have been a significant obstacle to the recent cancel storm, but
wouldn't obstruct some other kinds of malicious cancellation much. We
are reluctant to spend considerable time and effort solving only part
of the problem.)
>You can bias the password with the checksum of
>the last 10 lines in /usr/lib/news/log and /etc/utmp. Run "ps" and generate
>a checksum of the result...
The "ps" approach is really too slow for inews. Neither /usr/lib/news/log
nor /etc/utmp is really all that random, although there's probably enough
there to be worthwhile. Using the low-order bits of the *length* of some
of these files, as another poster suggested, would help.
Henry Spencer
True, with reservations. This is an approach I hadn't thought of.
>The modification dates, length, and inode number, can be good values to
>use...
Yes and no. The low-order bits of the length are good. Inode number is
typically pretty much constant, at least over substantial periods, on
each machine -- this will hamper people cancelling all cross-posts to
rec.pets.cats, but not people cancelling all postings by Jim Bowery,
who need do only one major brute-force search per sending site. The
same is true for modification date on infrequently-modified files, and
modification dates on frequently-modified files (like news's history
file) are not very random (as Curt notes).
>On top of this, my current thinking on how I was going to implement the
>passwords was to have the newsreading program generate them...
Unfortunately, this means we have to modify *all* the news readers before
we start seeing real security for cancels. Some of those programs aren't
even maintained any more. The right place to do something like this is
in the inews machinery.
>>That brute-force
>>search doesn't need to be all that lengthy, especially since the Unix
>>password algorithm is not very expensive to run.
>
>The best I've seen is on the order of 1000 crypts per second (without
>hardware support), with today's technology.
It's getting faster all the time. Besides: why use the Unix password
algorithm at all?!? There are *much* better algorithms in the public
domain, like MD5. Using the password algorithm for this is just silly;
as an authentication algorithm it is thoroughly obsolete.
>And we don't need "real" security. We are just trying to increase the
>cost of canceling an article that you didn't post...
We are trying to increase it *enough* to seriously obstruct various forms
of antisocial behavior. Increasing it a little just makes it a challenge.
We may not need "real" security, but we do need *effective* security.
Henry Spencer
> > Cryptographic authentication *is* what's wanted. At present, there are
> > some implementation difficulties with doing it right, and half-hearted
> > versions aren't going to accomplish much.
>
>Sure they will. They'll give us valuable experience so that we
Maybe you want to spend your life keeping one small step ahead of the
bozos; we don't. We are not averse to cryptographic authentication,
but we want to see it implemented *once*, gotten right so that it will
be truly effective, and then propagated widely.
Remember that the half-life of a news version is *years*. Constantly
changing the encryption algorithm is the same as having none; it will
be effective only if it is very widely installed, so that a forged
cancel really does have very little effect, and that requires it to
be stable (and effective) for a period of several years.
Kyle Jones
> We are not averse to cryptographic authentication, but we want
> to see it implemented *once*, gotten right so that it will be
> truly effective, and then propagated widely.
>
> Remember that the half-life of a news version is *years*.
> Constantly changing the encryption algorithm is the same as
> having none; it will be effective only if it is very widely
> installed, so that a forged cancel really does have very
> little effect, and that requires it to be stable (and
> effective) for a period of several years.
This is why I have been urging that the authentication be
decoupled from the news software as much as possible. Make it
simple to adopt new authentication methods, and maybe people will
be more willing to install them. If it means rebuilding and
reinstalling all of C news then perhaps they won't. Even lacking
an viable authentication method, someone should be thinking about
how such a system would be hooked into the existing news
framework. Hooks are what we need.
Curt Welch
>algorithm at all?!? There are *much* better algorithms in the public
>domain, like MD5. Using the password algorithm for this is just silly;
>as an authentication algorithm it is thoroughly obsolete.
Now you're getting to some good points. A serious problem with using
the Unix password algorithm isn't whether it's good enough, but whether
it's available on enough systems. I've been led to believe that it's
not public domain - is that true? Is there no easy way to make it
available on other platforms? For exampile, I have my own version (a
rewrite of crypt() for speed.) Could I distribute it since it doesn't
contain any actual code from the original crypt()?
Where can I get info on MD5? Is it, as you say, public domain? Would
there be any problem in including MD5 code in news software that would
be sent all over the world?
Curt
Ross Ridge
>I'm not so sure. Fractional time, yes... but that only gives you five
>or six bits on a lot of systems. The process ID of inews (etc) is in the
>message ID for most modern news systems, so this contributes either no
>bits (if inews is all one process) or only two or three (if it's more
>than one and hence the key bits have a small offset from the inews pid).
Since the idea is to change most modern news systems anyways, you can
also change their message ID formats in order to use the 15 bits of a
PID for authentication purposes. Similarily you could get rid of seconds
from the Date: and message ID headers and use those 6 bits. Where you'ld
get any more bits you'ld need I don't know. This probably means going back
to B News message ID generation, but that's not as bad poking around in kernel
memory. Hmm... maybe just use the authentication code in the message ID.
Ross Ridge
--
Ross Ridge - The Great HTMU l/ //
[OO][oo]
ro...@zooid.guild.org /()\/()/
uunet.ca!zooid!ross db //
Tim Kuehn
>The hard part, actually, is generating a whole bunch of random bits as
>the password. Portably. Without using either the time of day (down to
>the second) or the process ID.
How about:
1) Grab the current process id.
2) Get a list of all the currently active processes (ie, from something
like ps -e).
3) Obtain x = (current process id) mod (number of active processes)
4) Use process #x in the list of active processes as your random number
for the password.
This would give you a randomizer not dependent on the time of day, and
would be difficult to break if you didn't keep a record of all the process
activity on a given machine all the time. For sites external to the
poster's machine, it'd be impossible to determine.
+-----------------------------------------------------------------------+
| Tim Kuehn | TDK Consulting |(519)-888-0766| |
| <>< | Services | ti...@tdkcs.uucp ti...@tdkcs.waterloo.on.ca|
+-----------------------------------------------------------------------+
Bruce Clement
Please don't forget that not every news carrying site has Unix.
Yes, most of the techniques you mention could be translated to OS/2, DOS,
CMS, etc., but most of the specifics would have to go.
--
Bruce Clement (fr...@alfheim.welly.gen.nz Waffle 1.64,
fr...@alfheim.actrix.gen.nz SNEWS/2, UUPC 1.11q)
Don't buy from net.censors ... support free speech ... Boycott Apple Computers!
Matthew Farwell
>In article <BqD3G...@zoo.toronto.edu> you write:
>>The hard part, actually, is generating a whole bunch of random bits as
>>the password. Portably. Without using either the time of day (down to
>>the second) or the process ID.
>How about:
>
>1) Grab the current process id.
>2) Get a list of all the currently active processes (ie, from something
> like ps -e).
>3) Obtain x = (current process id) mod (number of active processes)
>4) Use process #x in the list of active processes as your random number
> for the password.
>
>This would give you a randomizer not dependent on the time of day, and
>would be difficult to break if you didn't keep a record of all the process
>activity on a given machine all the time. For sites external to the
>poster's machine, it'd be impossible to determine.
This is just a bit Unix-centric. Apart from that, a similar scheme was
proposed (in comp.lang.c I think) a while back when discussing
generating random passwords, the same argument applies here.
If you have a scheme like this, then I can get a very close
approximation to your 'random' number by simply doing ps -e. If there
are 180 processes running on your machine, then I have a search space of
180. I know the time you posted you article, so allow a few of seconds,
say 10, for that. Knowing the algorithm you use, even if it takes 1
second to do each encryption (very slow), the complete search takes 30
minutes. Now you say 'but the process I chose might not exist by the
time I do the ps. Fine. Worst case, I just try all 30000 possible
entries. Worst case (for you) is if your 'random' algorithm chose say
the first process in the ps list (which in my case is *always* swapper),
or the second, (init), then you're stuck. In fact, looking at my ps
list, the first 15 or processes are pretty invariant. They get started
when my machine goes multiuser, and continue with very little change.
These are 12 out of those 15.
UID PID PPID C STIME TTY TIME COMMAND
root 0 0 0 Jun 26 ? 0:01 swapper
root 1 0 0 Jun 26 ? 0:04 /etc/init
root 17 1 0 Jun 26 ? 0:00 logger /dev/error /usr/adm/messages /us
root 16 1 0 Jun 26 ? 0:22 update
root 136 1 0 Jun 26 ? 0:01 acctd
root 19 1 0 Jun 26 ? 0:03 cron
root 123 1 0 Jun 26 ? 0:00 inetd
root 111 1 0 Jun 26 ? 0:00 slink
news 125 1 0 Jun 26 ? 0:20 nntpd
root 127 1 0 Jun 26 ? 0:00 authd
root 121 1 0 Jun 26 ? 0:03 named
root 139 136 0 Jun 26 ? 0:00 acctd
This cuts down on your randomness even more. On a machine like a Sun,
which seems to have daemons for everything, this gets worse.
You can't use the time to the nearest second or the pid if you want a
random factor.
Dylan.
--
It is no coincidence that in no known language does the phrase 'As
pretty as an Airport' appear -- Douglas Adams
Henry Spencer
>>the password. Portably. Without using either the time of day (down to
>>the second) or the process ID.
>
> like ps -e).
Several people have suggested variations on this. (Doing some sort of
checksum on ps output is another popular one.) The trouble is, ps is
*slow* on a lot of systems. I really don't want to slow down inews to
the point where we have to move the main processing out into the background
again; that caused a lot of headaches and we were glad to get rid of it.
On a busy system on an old machine, ps -ax or ps -e can take *minutes*
to run.
Henry Spencer
> > Remember that the half-life of a news version is *years*.
> > Constantly changing the encryption algorithm is the same as
>
>This is why I have been urging that the authentication be
>decoupled from the news software as much as possible. Make it
>simple to adopt new authentication methods, and maybe people will
The real issue, on a lot of systems, is not the length of time taken
(or at least, only its order of magnitude counts), but getting the poor
harassed sysadmin to spend *any* time on the matter. A steady stream
of wonderful new improved lemon-freshened authentication methods is
perfectly calculated to make a lot of sysadmins sit back and do nothing
until the situation stabilizes. These people don't *want* to spend
their time installing the authentication method of the week, even if
it's rather easier than installing a whole news system.
Having a lot of different methods is also a guarantee that no one
method will be useful enough to make people adopt it consistently.
What good does it do to put an authenticator on my cancel message if
only a fraction of the sites it reaches will have that particular
authentication algorithm available? I repeat, constantly changing
the algorithm (or constantly adding new and improved ones, which
amounts to the same thing) is the same as having none.
I don't understand why we *need* a period of experimental chaos.
Designing a suitable authentication method is not simple, but if it
can be done at all, it ought to be feasible to get it right the
first time. The trick is not picking an encryption algorithm --
if you avoid silly choices like the Unix password algorithm, it's
not difficult to get a decent one -- but devising a system that will
let us do necessary things (like cancelling sendsys bombs) while
still providing enough of an obstacle to cancel sprayers to make
them give up on the idea.
Note, it's not enough to make the sprayers' lives a bit harder; they
will just see that as a challenge. You've got to present them with
a sufficiently major obstacle that they will give up. If you've got
a pig that likes jumping fences, you have to make its fence a lot
higher all at once -- if you do it by increments, all you're doing
is training a jumping pig.
Simon Edward Spero
I think the best think to do is to keep this discussion going long enough
that the RSA patent runs out, and we can use that. Setting up an RSA based
authentication system,even for a store-and-forward based transport mechanism
is quite trivial; all you need is a centralised site capable of registering
one public key per site, and returning a copy of that key decrypted by the
central sites key.
To sent an authenticated message, add a Key: header containing the
previously obtained decrypted public key, together with a checksum for the
entire message, decrypted by the sending sites key.
Hmm.. Given the time lag needed for news software to be taken up, maybe
it could go into the next C-news- it'd then be ready and waiting..
Simon
--
-----
Guest account at TMC | Just Another WAIS Hacker | DOD# 0612
Peter da Silva
>In article <JRR...@taronga.com> pe...@taronga.com (Peter da Silva) writes:
>>>... Remember, the existing message headers tell you the time
>>>down to the second plus the process ID of the poster,
>>Only if you've left the original message-id generating mechanism in place.
>>By inspection I can tell that *you've* already changed it.
>We've changed the encoding, not the contents. There's still a date and
>a pid in there.
There's a date and PID in mine, too. Can you tell me what they are? Plus, you
can easily add noise bits from anywhere (I've already suggested several) and
add them as well.
>The algorithm must be assumed to be known, since the overwhelming majority
>of sites will not locally modify it.
The algorithm can be randomly modified (for example, by changing the alphabet)
on a site by site basis using any source of random data (say, bytes 47 and 1921
of /unix or /etc/passwd). The message-ID can have per-message random data
added. And extra field in the message can be used (Password:). All sorts of
things can be done.
earthbound misfit, I
> I think the best think to do is to keep this discussion going long enough
> that the RSA patent runs out, and we can use that.
What patent?
Oh, you're in the US.
Seriously though, a decent authentication system is required, but one that
is sufficiently secure either doesn't exist or is mired in legal problems
(as above). As I understand it, that's why people like the C News authors
can't "fix it" now - the tools to do the job probably don't exist at present.
I believe that a US standards agency is working on a digital signature
standard that could be applicable to news, but I remember there was some
controversy somewhere. Some time spent reading sci.crypt would probably
be enlightening.
- k
--
Craig Harding kil...@freddy.acme.gen.nz ACME BBS: +64 6 3551342
"Jub'f Xvob?"
Curt Welch
>The algorithm must be assumed to be known, since the overwhelming majority
>of sites will not locally modify it.
In news.admin, pe...@taronga.com (Peter da Silva) writes:
>The algorithm can be randomly modified (for example, by changing the alphabet)
>on a site by site basis using any source of random data (say, bytes 47 and 1921
>of /unix or /etc/passwd). The message-ID can have per-message random data
>added. And extra field in the message can be used (Password:). All sorts of
>things can be done.
Here's what I ended up getting done this weekend.
I added code to my newsreader to create Cancel-Lock: lines on new
postings and to add the correct Cancel-Key: line to cancel messages. I
started looking a C-News to see what needed to be changed there when it
processes cancel messages but I haven't made any changes yet.
I used the MD5 algorithm instead of the Unix password algorithm. It's
a much better choice because it gives you a 128 bit encrypted password
(twice the length of the Unix password), and because the algorithm is
public domain, so anyone can use it. You can get info on MD5 through
anonymous ftp to rsa.com.
MD5 is a one-way encryption algorithm that creates an 128 bit "message
digest" for messages of any length. This means that you can use a
password of any reasonable length.
My code generates a random password that's the same length as the
encrypted form - 128 bits. To generate this password, I used multiple
bits of data from the local system. I used:
The pid - which isn't the same as the one on the article because my
code was added to the newsreader.
The user's uid - which is not normally known to the world.
The time - which is related to the time in the messages ID, but I
generate the password before the user starts writing the message, so
the time is off by some unknown period (adding at least 5 unknown
bits).
The address of a stack variable - I thought this was neat. This is
hard to calculate (you have to use a debugger) and will be different
on different platforms. It makes the code self randomizing without
having to rely on the user that installed the software to make
some random changes to the algorithm.
The address of a global variable - like the address of a stack var,
this will be different on different platforms and different with
different releases of the OS.
The MD5 message digest of /tmp - I read the /tmp directory and
calculate an 128 bit MD5 messages digest. /tmp at any one time will
have thousands of random bits worth of information, and on most
multiuser machines will be changing faster than anyone could capture
it's state when the password was being created.
The MD5 messages digest of ~/.newskey - the user file that holds all
his old Cancel Keys - including the ones that were created but never
used because he aborted the post. This means that to break the
password, you will have to have broken all his previous passwords,
including the ones that were never sent out.
I combine these together by taking the current 128 bit password, xoring
the data into the low bytes, and then running the result through MD5 to
scramble the bits. I do this for each of the above numbers.
Does anyone see a weekness in this approach?
The 128 bit random password is then run through MD5 to create the cancel
lock. A line in the following format is then added to the message:
Cancel-Lock: MD5:9d1f30900a0201848402190cc4651880
The MD5: label specifies the encryption algorithm used to create the
lock. This will allow the addition of locks using other algorithms in
the future. The concept is that multiple locks, using different
algorithms, will be allowed on a single message. Something like this:
Cancel-Lock: MD5:9d1f30900a0201848402190cc4651880 U:iErRSI2pCGAC
News software would ignore any unknown locks.
The cancel control message includes a line that looks like this:
Cancel-Key: MD5:f309df000a02f19d1b48c02146f90c8
Because the password is binary, not ASCII, I used a hex representation
of the password. This would also prevent problems if anyone tried to
implement cancel locks on a non-ASCII system.
My current implementation saves the cancel keys in file called ".newskey"
in the user's home directory. Because I built this into a newsreader,
and because the keys are generated before the article is sent to inews,
I don't have have the message ID to save in the file with the key. But
this wasn't a problem. When you cancel an article, the newsreader just
scans the .newskey file and checks all the keys until it finds one that
matches the lock. I put the date and time in the file (in ctime()
format) so the user can tell when the keys were created.
I was thinking of taking the code I wrote and putting it into a separate
program for other people to use (or try out etc.) I would write one
program called cancellock which would generate the random password,
save the key in the .newskey file, and output the complete Cancel-Lock:
header line. A second program called cancelkey would take a cancel lock
as an argument, lookup the correct key, and generate the Cancel-Key line
for use in the Cancel message.
Whatever I do, I'll make the code available in one form or another.
My current thought on how cancel messages should be processed is
something like this: If the article being canceled has a Cancel-Lock
line, then the cancel message must have the correct key. If the
Cancel-Lock: line has any syntax errors, then it should be ignored.
If the Cancel-Lock line has multiple keys, then only the ones that
use an encryption algorithm that the news software knows about should
be used. The rest should be ignored. If the news software knows about
multiple algorithms, and if the article has multiple locks, then the
cancel message must have multiple keys, and they must all match
correctly before the article will be canceled.
If the key(s) don't match, the article shouldn't be canceled, and the
cancel control messages should be junked (i.e. not sent on to other
systems.)
Cancel-Locks will be ignored on control messages - i.e. you can cancel a
control messages whether it's locked or not. We don't want to give the
sendsys bombers a cancel proof bomb.
Cancel-Locks will be ignored on messages with an Approved: line (i.e.
you can not lock articles posted to moderated groups.) This way, the
moderator will always be able to cancel articles posted to his group.
I think the problem of a cancel messages showing up before the article
being canceled can just be ignored. It should continue working like
it currently does. I think B-news drops the cancel messages - which
isn't a very good way to deal with this - and C-news will generate
a fake history entry preventing the messages from every getting on
the system.
This means that if you can forge a cancel messages and get it out to
other systems quicker than the original article, then you will be able
to effectively cancel it on some systems even though it has a cancel
lock. I don't think this will be much of a problem - and besides you
could play this same game another way to try and wipe out an article.
You could send out a fake messages with the messages ID of the article
you wanted to cancel. Any system that got your messages first would
never get the original article.
Here on oasys.dt.navy.mil, we use nntp and nntplink to move news. It
only takes our system a few seconds to send off an article to all
our feeds once we receive it. With this type of propagation speed on
the backbone sites, it will be hard for someone to forge a replacement
article and get it distributed ahead of the original to very many sites.
If news systems took more care to processes, and propogate, articles in
the order they were receved, then this would be even less of a problem.
Any other thoughts on this whole concept?
Curt Welch
cu...@kcwc.com
mathew
> In article <1992Jun25.0...@clarinet.com> br...@clarinet.com (Brad Temp
> >seeds on any given system. If you have the time to better than a second,
> >you can of course use those fractional seconds, and the lower 7 bits of
> >the process ID, and a few random words from rapidly changing areas in the
> >kernel as provided by a simple program with memory-read permissions.
>
> I'm not so sure. Fractional time, yes... but that only gives you five
> or six bits on a lot of systems.
Since you only need to generate these bits when something's being posted, you
can take the seconds (maybe minutes) before the user first starts editing the
article. This should be moderately unguessable even given the posting time.
You could even get the user to type a few random characters, and grab a few
bits from the middle of each one. No funny permissions required.
mathew
--
Ceci | n'est pas une pipe.
mathew
> that the RSA patent runs out, and we can use that.
I think the best thing to do is ignore the RSA patent and use RSA now.
Should keep the PKP Mattress Police busy. My PGP RSA public key is available
on request.
Not that I have PGP, of course; it's prohibited to export it from the USA, so
how could I have obtained a copy? Heavens, next I'll be pretending I have a
copy of the US DoD DES specification.
Ronald Khoo
> Besides: why use the Unix password algorithm at all?
Because it's the only one that you don't have export control problems
with, or at least, the one with the minimum of export control
problems, given that most unix vendors now ship an "internationalised"
crypt(3) with sufficient functionality (access to crypt() itself
but not the routines which can be used to encrypt data).
> We are trying to increase it *enough* to seriously obstruct various forms
> of antisocial behavior. Increasing it a little just makes it a challenge.
> We may not need "real" security, but we do need *effective* security.
It depends on which purpose you're trying to achieve. Using unix
crypt() is like the cheap brass padlock that you use to discourage
opportunist crime. Using a "real security" algorithm is more like
the hardened steel variety with drill-out defeats that you use in
real security applications. Both have their place. For netnews,
I'm not sure that either one is worth the cost :-) However, while
it's perfectly fair for you to choose not to implement the cheap
hack, it's not right to claim that it's worthless because it isn't.
It's just worth less. [ pun intended :-) ]
--
Ronald Khoo <ron...@demon.co.uk> <ron...@ibmpcug.co.uk> <ron...@robobar.co.uk>
BTNet: +44 71 229 7741 | Brambles are the order of the day.
David Barr
BTW, nice TLA's.
--Dave
--
System Administrator, Population Research Institute ba...@darwin.psu.edu
"The Moral Majority" is neither. .*\.([^.]+)\.\1\.\1$
Greg Brail
>If you've got
>a pig that likes jumping fences, you have to make its fence a lot
>higher all at once -- if you do it by increments, all you're doing
>is training a jumping pig.
And to think that I always wondered whether Henry ever has time to get
involved with zoology given all the work he must do regarding News and
the net.
greg
--
Greg Brail Citibank g...@fig.citib.com
"Undefined symbol! Your mother is an undefined symbol!"
-- Someone I once worked for, to her compiler
Henry Spencer
>> Besides: why use the Unix password algorithm at all?
>
>Because it's the only one that you don't have export control problems
>with, or at least, the one with the minimum of export control
>problems, given that most unix vendors now ship an "internationalised"
Why do you assume that we're dealing with Unix? I think we'd really have
to ship a copy of the code; none of the relevant Unix standards mandate
the existence of crypt(3).
It could be done, as witness the existence of published implementations
in password-cracker programs. (Although... I'm slightly unsure of how
those implementations could have been done without reference to Unix
sources, which would make them legally tainted...)
Note that anyone who lets you FTP the text of RFC 1321 is letting you
FTP a complete C implementation of MD5.
>> We are trying to increase it *enough* to seriously obstruct various forms
>> of antisocial behavior. Increasing it a little just makes it a challenge.
>> We may not need "real" security, but we do need *effective* security.
>
>It depends on which purpose you're trying to achieve. Using unix
>crypt() is like the cheap brass padlock that you use to discourage
>opportunist crime...
Just how much discouragement would that cheap brass padlock supply in,
say, downtown Detroit? You've just wasted the price of the padlock.
Why bother, when a good padlock is easier to get and no more expensive?
Henry Spencer
>>The algorithm must be assumed to be known, since the overwhelming majority
>>of sites will not locally modify it.
>
>on a site by site basis using any source of random data ...
This is not modifying the *algorithm*. This is adding some site-specific
components to the *key*. My point is that as long as the recipients are
not actually changing code, the code must be assumed known to the bad
guys, and security must reside in key randomizing. Site-specific key bits
have both advantages -- you can afford to do more elaborate things at
software-build time than at posting time -- and disadvantages -- they
don't change with every posting -- but are probably worth doing.
Note that *any* scheme which requires a cancel to supply a key known only
to the article's originator makes it impossible for "the authorities" to
cancel an improper posting, like a sendsys bomb or a copyright violation.
We can't assume cooperation from the poster or his sysadmin (they may
be the same person).
Henry Spencer
>>If you've got
>>a pig that likes jumping fences, you have to make its fence a lot
>
>And to think that I always wondered whether Henry ever has time to get
Your wondering is correct. :-) This particular comment is courtesy of
one side of my family being farmers, not of my working for a Zoology
department.
Bernd Felsche
>In article <1992Jun30....@fig.citib.com>
> g...@fig.citib.com (Greg Brail) writes:
>>And to think that I always wondered whether Henry ever has time to get
>>involved with zoology...
>Your wondering is correct. :-) This particular comment is courtesy of
>one side of my family being farmers, not of my working for a Zoology
>department.
Ahhh. And there was I thinking that zoo.toronto.edu was the
place you kept all the wild programmers. ;-)
BTW: Ever wonder what you'd get if you gave a monkey a keyboard?
f-o-r-t-y-t-w-o?
--
+-----+ Bernd Felsche _--_|\ #include <std/disclaimer.h>
| | | | MetaPro Systems Pty Ltd / \ ber...@metapro.DIALix.oz.au
| | | | 328 Albany Highway, X_.--._/ Fax: +61 9 472 3337
|m|p|s| Victoria Park, Western Australia 6100 v Phone: +61 9 362 9355
Peter da Silva
>Site-specific key bits
>have both advantages -- you can afford to do more elaborate things at
>software-build time than at posting time -- and disadvantages -- they
>don't change with every posting -- but are probably worth doing.
Some keys I described are site-specific and *do* change on every posting.
>Note that *any* scheme which requires a cancel to supply a key known only
>to the article's originator makes it impossible for "the authorities" to
>cancel an improper posting, like a sendsys bomb or a copyright violation.
Other people have already pointed out that control messages should not
be blocked. For stuff like copyright violations cancels are insufficient
anyway (archives, backups, people saving copies, lost cancel messages,
etc...).
Henry Spencer
>
>Some keys I described are site-specific and *do* change on every posting.
I should have been clearer in my wording... The issue is how to get a lot
of unpredictable bits for a key. Getting them at key-generation time is
best... but efficient, portable sources are few. You can fix some of them
at software-build time, making them site-specific but not article-specific;
this has advantages and disadvantages, which is what I was discussing.
My current feeling is that you can probably get enough bits, combining
some site-specific bits (e.g. process ids from the software build) and
some article-specific bits (sub-second time bits and low-order bits of
file sizes in particular).
>>Note that *any* scheme which requires a cancel to supply a key known only
>>to the article's originator makes it impossible for "the authorities" to
>>cancel an improper posting, like a sendsys bomb or a copyright violation.
>
>Other people have already pointed out that control messages should not
>be blocked...
Exempting control messages gets a wee bit complicated, since you have to
determine whether the message is a control message at cancel time (you
can't rely on a sendsys bomber refraining from including a cancel key!).
Moreover, there are legitimate control messages and some potential for
mischief in cancelling *them* -- consider cancelling a cancel of a
copyright violation.
>For stuff like copyright violations cancels are insufficient
>anyway (archives, backups, people saving copies, lost cancel messages...
They are insufficient in a theoretical sense but often important in a
practical sense, both to minimize further propagation of the improper
posting and to help placate an irate copyright owner. Archiving is
often done at expiry time, which means that cancels are still effective.
Sane people typically don't do backups on their news partitions. Cancels
do propagate pretty well, if imperfectly.
D'Arcy J.M. Cain
>In article <1992Jun30....@fig.citib.com> g...@fig.citib.com (Greg Brail) writes:
>>>If you've got
>>>a pig that likes jumping fences, you have to make its fence a lot
>>>higher all at once...
>>And to think that I always wondered whether Henry ever has time to get
>>involved with zoology...
>Your wondering is correct. :-) This particular comment is courtesy of
>one side of my family being farmers, not of my working for a Zoology
>department.
Hmm. In <1990Jun23....@utzoo.uucp> you said:
>Alas, I question whether this is a viable approach. Usenet does not have
>much political clout, and the results of encouraging the politicians
>to legislate on the subject might not be as intended... When you ride a
>gorilla, you go where the gorilla wants to go.
So is this from being in a Zoology department or did your family also
raise gorillas? :-)
--
D'Arcy J.M. Cain (darcy@druid) |
D'Arcy Cain Consulting | There's no government
Toronto, Ontario, Canada | like no government!
+1 416 424 2871 DoD#0082 |
Catherine Anne Foulston
>raise gorillas? :-)
It's probably because he's been watching Usenet for too long.
Usenet is a zoo without a keeper.
Cathy
--
Cathy Foulston + Rice University + Network & Systems Support + cat...@rice.edu
"Personally I think being thought of as being a jerk by of all Usenet is
more than enough punishment." -- Ross Ridge