As XXXX mentioned, there's already ssl-enabled nntp. Most nntp servers don't support it natively (IIS and Collabra being notable exceptions) but it's pretty trivial to make an stunnel frontend to Your Favorite NNTP Server. And a reasonable quantity of clients seem to also support it.
(apology in advance: some of the stuff that follows is pretty basic security theory. Many of you already know this stuff, but I thought it would be useful to include it in case anyone is reading with interest who doesn't have the background.)
(caveat in advance: I am not a security professional. I've never been systematically trained to do computer security nor have I ever been paid to do it. Please take anything I say with a grain of salt.)
To really do this thing right, you'd also want no unencrypted data to ever be written to disk. That means on the server end, either pointing the nntpd process at an encrypted filesystem or adding encrypt/decrypt functionality directly to the process. (There's a bunch of handwaving in there -- I haven't sufficiently researched encrypted filesystems to make proclamations about them.) And what happens if the server process needs to use swap?
It also means trusting the clients not to write data to disk after unencrypting -- which in a distributed nntp network would be newsreaders and other servers (and the people running them). I don't know how you enforce that, so some quantity of trust in the people configuring clients is probably necessary.
In the single-nntp server case, each user can be given an account on the server and you could nttp via an ssh tunnel, which gives you the better-than-ssl security you're looking for. Technically this also works in the multiple-nntpserver case, but either the accounts need to be mirrored on each server, or each account is bound to a single server. On the other hand, adding user-accounts increases the points-of-entry on a system; I assume that part of the requirements of a setup like this is that it shouldn't be easy to break into the server. Giving an account sufficient permissions to set up an ssh tunnel likely means interactive logins. I don't know of any other ipv4 public-key tunneling systems (there's at least one in development for IPv6).
I personally wouldn't be comfortable running this on anything but an openbsd system, but that's in part because I don't think I'm qualified to secure a linux or a windows box. Both those OSs have more interesting encrypted filesystem implementations available than OpenBSD does, but hardening them and keeping them that way can be a pain in the ass.
What would the requirements be for server-side file encryption? Encrypted filesystems are generally designed to be proof against offline attacks -- so if somebody yanks the disk they still can't read the files. Do you require your disk encryption to provide while-running security? Most trivial implementations are per-user; once you've enabled access to the nntpd process anybody who can gain nntp-user-permissions can see the data. If you turn off interactive logins for that user and otherwise secure the machine from incursions in a responsible manner, is that sufficient? Or do you need full-fledged per-process access controls?
What would be the requirements for physical security? Is it enough to know that the box lives in a house owned by people you trust? Or would you want to make sure it was in a locked facility somewhere? What does that mean for things that require physical access? How do the physical security requirements stack up against the security problems with privileged remote logins?
What policies for clients would be put in place? How could you audit compliance with those policies?
(Quick-and-very-dirty implementation of secured nntp: everybody sets up a local nntp system, but instead of reading and writing articles on local disk, everyone shares a single remote datastore using cfs (which uses nfs). This is probably a terrible, terrible idea; at the very least, I bet performance would be horrific.)
You can ping this entry by using http://www.khephra.org/mt-tb.cgi/242 .