A "salt" is a value used to modify a hash of a password.
Originally, user passwords were verified by direct comparison to a file containing the correct passwords. Simply exposing that file thus exposed some or all of the passwords on the system.
To avoid that, passwords were verified by computing a hash value from the password and verifying that to the correct hash value stored in the password file. The actual passwords, never being stored on the system, were thus thought to be protected.
Unfortunately, obtaining the password file revealed hash values which then could be compared to hash values for popular passwords, thus revealing the password itself.
To avoid this, a salt value is hashed along with password, thus changing the hash value and making a known-hash attack difficult.
Subject: What is required of "salt"? Date: Mon, 21 Aug 2000 11:44:00 -0600 From: John Myre <jmyre@sandia.gov> Message-ID: <39A16A60.2FB4F96C@sandia.gov> Newsgroups: sci.crypt Lines: 20 I'm wondering what (cryptographic) properties "salt" has to have. Let me begin by restricting the question to salt as used in password files. This might be the original Unix-style file, or it might be some verifier-based setup. The main purpose of salt, as I understand it, is to ensure that entries for the same password aren't the same (or rather, that the adversary cannot tell that the entries are for the same password). Is there more? Usually I see the assumption that the salt is "random". I don't see, however, why this is so. For example, what would be wrong with using a simple counter to generate salt values? Or, what if the salt were the concatenation of the user name and the server name (or address)? Is there a reason to change the salt when we change the password? JM
Subject: Re: What is required of "salt"? Date: Mon, 21 Aug 2000 18:53:20 GMT From: tomstd@my-deja.com Message-ID: <8nrtqn$1ne$1@nnrp1.deja.com> References: <39A16A60.2FB4F96C@sandia.gov> Newsgroups: sci.crypt Lines: 44 In article <39A16A60.2FB4F96C@sandia.gov>, John Myre <jmyre@sandia.gov> wrote: > > I'm wondering what (cryptographic) properties "salt" has to have. > > Let me begin by restricting the question to salt as used in > password files. This might be the original Unix-style file, > or it might be some verifier-based setup. > > The main purpose of salt, as I understand it, is to ensure > that entries for the same password aren't the same (or rather, > that the adversary cannot tell that the entries are for the > same password). Is there more? > > Usually I see the assumption that the salt is "random". I > don't see, however, why this is so. For example, what would > be wrong with using a simple counter to generate salt values? > Or, what if the salt were the concatenation of the user name > and the server name (or address)? Is there a reason to > change the salt when we change the password? Salts only need to be unique. If you can afford that it's ok. Otherwise just pick a salt at random. The purpose as you may already know of a salt is to hinder hash- matching attacks on password system because passwords as simple as "aaa" can hash to many different valid outputs. The larger the salt the better. It also means that people who use the same password will not have the same passwd hash unless the salt was the same too. Consider a system with no salts used, all users that pick the password "aaa" will have the same hash, not only that but all users on another system will have the same hash. Now if you used a 12 bit salt for example you have to test "aaa" 4096 times (different hashes). So make the salts random that's all. Tom Sent via Deja.com http://www.deja.com/ Before you buy.
Subject: Re: What is required of "salt"? Date: Mon, 21 Aug 2000 13:58:37 -0600 From: John Myre <jmyre@sandia.gov> Message-ID: <39A189ED.650C5A0F@sandia.gov> References: <8nrtqn$1ne$1@nnrp1.deja.com> Newsgroups: sci.crypt Lines: 31 tomstd@my-deja.com wrote: > > In article <39A16A60.2FB4F96C@sandia.gov>, > John Myre <jmyre@sandia.gov> wrote: > > > > I'm wondering what (cryptographic) properties "salt" has to have. > > <snip> > > Salts only need to be unique. If you can afford that it's ok. > Otherwise just pick a salt at random. <snip> > > It also means that people who use the same password will not have the > same passwd hash unless the salt was the same too. <snip> I think you are agreeing with me on the actual requirements of a salt: (mostly) different for each login, to hide collisions in passwords. > So make the salts random that's all. That's one way. What I'm trying to figure out is if that has to be the only way. Different situations would make other alternatives attractive. For instance, if the username could be taken as the salt, then we don't have to store a salt, we don't have to "generate" it, we don't have to communicate it. So - is there a reason why that technique is insecure? JM
Subject: Re: What is required of "salt"? Date: 21 Aug 2000 19:21:57 GMT From: unruh@physics.ubc.ca (Bill Unruh) Message-ID: <8nrvgl$k18$1@nntp.itservices.ubc.ca> References: <39A16A60.2FB4F96C@sandia.gov> Newsgroups: sci.crypt Lines: 46 In <39A16A60.2FB4F96C@sandia.gov> John Myre <jmyre@sandia.gov> writes: ]I'm wondering what (cryptographic) properties "salt" has to have. None. Its only purpose is to make the same password (eg used by different users) store differently in the public password file. This way the attacker will not know when two users have the same password just by looking at the hashed version. Probably a better scheme would have been to use the username ( as they are almost guarenteed to be unique) rather than a one of 4096 random numbers. However, the crypt authors were after shortness, and since machines could typically have more than 4096 users, they figured choosing them randomly was a good procedure. For the MD5 hash you could just as well use the user's name (except for the problem that this would show that the same user on different systems uses the same passwords on those different system.) So, the requirements are : a) unique to each user. b) Unique to each system. c) short. Of course all three cannot be done. Unix crypt opted for short, (2 alphnumeric encoded characters) and thus figured random number was best. You could equally use username+machineIP, or username+randomnumber to satisfy 1 and 2 without however having 3 ]Let me begin by restricting the question to salt as used in ]password files. This might be the original Unix-style file, ]or it might be some verifier-based setup. ]The main purpose of salt, as I understand it, is to ensure ]that entries for the same password aren't the same (or rather, ]that the adversary cannot tell that the entries are for the ]same password). Is there more? ]Usually I see the assumption that the salt is "random". I ]don't see, however, why this is so. For example, what would ]be wrong with using a simple counter to generate salt values? ]Or, what if the salt were the concatenation of the user name ]and the server name (or address)? Is there a reason to ]change the salt when we change the password? The only problem with using the system name is that when you change the system name or ip address, suddenly your whole password base is useless, and even root cannot log on.
Subject: Re: What is required of "salt"? Date: Mon, 21 Aug 2000 14:37:50 -0600 From: John Myre <jmyre@sandia.gov> Message-ID: <39A1931E.7691048B@sandia.gov> References: <8nrvgl$k18$1@nntp.itservices.ubc.ca> Newsgroups: sci.crypt Lines: 80 Bill Unruh wrote: > > In <39A16A60.2FB4F96C@sandia.gov> John Myre <jmyre@sandia.gov> writes: > > ]I'm wondering what (cryptographic) properties "salt" has to have. > > None. Ah, then I'll just use zero. :) > Its only purpose is to make the same password (eg used by > different users) store differently in the public password file. That's the only requirement I've ever seen, as well. > Probably a better scheme would have been > to use the username ( as they are almost guarenteed to be unique) rather > than a one of 4096 random numbers. However, the crypt authors were after > shortness, and since machines could typically have more than 4096 users, > they figured choosing them randomly was a good procedure. Shortness where? If you could take the username as the salt, then salting would cost zero in storage, since the username has to be there anyway. As far as historical design choices go, I'd bet that the variable length of the username was their (perceived) problem. > For the MD5 > hash you could just as well use the user's name (except for the problem > that this would show that the same user on different systems uses the > same passwords on those different system.) In the Unix systems I've seen, the problem is usually there anyway. The password file (with salts) is often copied to the next system, rather than creating new logins. Ok, so that's not good - but I'm not sure salt is where to stop that. That is, if you actually do use the same password on multiple systems, then you are as vulnerable as the least secure system, even without the attacker knowing it. In a practical sense, it can be *better* to use the same password everywhere, because you can pick a good one (and remember it). Or it can be worse, because now you think passwords aren't important. It does seem intuitively obvious that we want the attacker to know as little as possible. It would presumably be better not to reveal whether or not passwords were the same on different systems for the same person. However, I'm not really convinced of this, because I'm not sure what *advantage* the attacker gains. > So, the requirements are : a) unique to each user. Ok. > b) Unique to each system. Arguably. > c) short. Why? That is, does that requirement have any cryptographic purpose, or are you referring to practical constraints? <snip> > The only problem with using the system name is that when you change the > system name or ip address, suddenly your whole password base is useless, > and even root cannot log on. Hm. Good point. I've seen systems in which breaking logins when you change the ip address would be a good thing, but not usually. "Hardly ever," in fact. In a practical system, we could probably finesse this somehow; if it were given that using systemname:username for salt is a good idea otherwise. I can certainly imagine systems in which salts are other than random numbers are handy. Different systems, different techniques. At this point I'm still seeing if anybody can come up with any *cryptographic* requirements, other than uniqueness. JM
Subject: Re: What is required of "salt"? Date: 21 Aug 2000 21:29:01 GMT From: unruh@physics.ubc.ca (Bill Unruh) Message-ID: <8ns6ut$org$1@nntp.itservices.ubc.ca> References: <39A1931E.7691048B@sandia.gov> Newsgroups: sci.crypt Lines: 49 In <39A1931E.7691048B@sandia.gov> John Myre <jmyre@sandia.gov> writes: ]Bill Unruh wrote: ]> ]> In <39A16A60.2FB4F96C@sandia.gov> John Myre <jmyre@sandia.gov> writes: ]> ]> ]I'm wondering what (cryptographic) properties "salt" has to have. ]> ]> None. ]Ah, then I'll just use zero. :) Sure. Cryptographically this is as good as anything else. The salt is public knowledge. It cannot add any cryptographic strength to any one password. ]> Its only purpose is to make the same password (eg used by ]> different users) store differently in the public password file. ]> Probably a better scheme would have been ]> to use the username ( as they are almost guarenteed to be unique) rather ]> than a one of 4096 random numbers. However, the crypt authors were after ]> shortness, and since machines could typically have more than 4096 users, ]> they figured choosing them randomly was a good procedure. ]Shortness where? If you could take the username as the salt, then In the storage. REmember unix crypt was developed 30 years ago. Your pocket calculator that you bought for $10 has far more power and storage than those machines had. They wanted to also hide the fact that the same user uses the same password on different systems (especially on ones administered by entirely different people) ]dsalting would cost zero in storage, since the username has to be But expensive in the algorithm as you would have to figure out how to use the 8 characters in teh username to perturb the crypt procedure. ]there anyway. As far as historical design choices go, I'd bet that ]the variable length of the username was their (perceived) problem. ]In a practical system, we could probably finesse this somehow; if ]it were given that using systemname:username for salt is a good ]idea otherwise. You could also use some system wide salt to do the same thing. Ie, the file /etc/salt contains a "unique" system identifier.
Subject: Re: What is required of "salt"? Date: 21 Aug 2000 16:01:34 -0700 From: daw@blowfish.isaac.cs.berkeley.edu (David A. Wagner) Message-ID: <8nsccf$l80$1@blowfish.isaac.cs.berkeley.edu> References: <39A16A60.2FB4F96C@sandia.gov> Newsgroups: sci.crypt Lines: 35 In article <39A16A60.2FB4F96C@sandia.gov>, John Myre <jmyre@sandia.gov> wrote: > I'm wondering what (cryptographic) properties "salt" has to have. If I recall correctly, there is an excellent discussion in R. Morris, K. Thompson, ``Password security: a case history,'' {\em Communications of the ACM}, vol. 22, no. 11, Nov. 1979. A simplified answer is that the salt makes dictionary attacks more costly: it prevents you from re-using off-the-shelf DES hardware, and it forces you to try each dictionary word separately for each user, rather than amortizing the cost of a dictionary attacks across all users. > Usually I see the assumption that the salt is "random". I > don't see, however, why this is so. For example, what would > be wrong with using a simple counter to generate salt values? > Or, what if the salt were the concatenation of the user name > and the server name (or address)? Is there a reason to > change the salt when we change the password? Using just the username would be bad (someone could build a password -> encrypted-password codebook for specially targeted users, e.g., "root"), but username + fully-qualified server name seems ok as far as I can see. Counter is probably ok as long as you avoid correlations between servers (e.g., if all servers started at counter zero, that'd be bad). However, in general I think the Unix model of storing a hashed password in a publicly-readable location is a really bad idea these days. Experience is that many passwords have very low entropy, so low that no amount of salting can save you. Passwords are basically an obsolete technology, unsafe at any speed. I'd recommend that you consider the alternatives to passwords, and the risks of passwords, very carefully before deploying any new systems that use passwords for authentication.
Subject: Re: What is required of "salt"? Date: Tue, 22 Aug 2000 00:13:37 GMT From: elleron@crosswinds.net Message-ID: <RAjo5.38953$_s1.486215@typhoon.ne.mediaone.net> References: <8nsccf$l80$1@blowfish.isaac.cs.berkeley.edu> Newsgroups: sci.crypt Lines: 48 David A. Wagner <daw@blowfish.isaac.cs.berkeley.edu> wrote: >> Usually I see the assumption that the salt is "random". I >> don't see, however, why this is so. For example, what would >> be wrong with using a simple counter to generate salt values? >> Or, what if the salt were the concatenation of the user name >> and the server name (or address)? Is there a reason to >> change the salt when we change the password? > Using just the username would be bad (someone could build a > password -> encrypted-password codebook for specially targeted > users, e.g., "root"), but username + fully-qualified server name > seems ok as far as I can see. Counter is probably ok as long > as you avoid correlations between servers (e.g., if all servers > started at counter zero, that'd be bad). To be pedantic, the salt is not truly random either, whch noone has pointed out. It's normally obtained from the time of day, so there's some bias towards whatever time the administrator normally creates accounts at. > However, in general I think the Unix model of storing a hashed > password in a publicly-readable location is a really bad idea > these days. Experience is that many passwords have very low > entropy, so low that no amount of salting can save you. The current practice is to move the hashed password to a non-public file, and throw the salt away after calculating the hash. If you absolutely need to have them, that's probably they way to go. As to discarding the salt, remember you can still verify the has by trying every possible salt value. (For a worse case of 4096 tries for crypt(3), for example). > Passwords are basically an obsolete technology, unsafe at any > speed. I'd recommend that you consider the alternatives to > passwords, and the risks of passwords, very carefully before > deploying any new systems that use passwords for authentication. Unfortunatly, they're a neccessary evil at this point in time. Even systems that use a stronger form of authentication often protect that with a password. I would, however, avoid crypt(3) like the bubonic plague. One of the MD5 style hashes (perhaps even modified to use SHA) is even better, and doesn't limit you to eight character words. -- Matt Gauthier <elleron@crosswinds.net>
Subject: Re: What is required of "salt"? Date: Tue, 22 Aug 2000 10:06:27 -0600 From: John Myre <jmyre@sandia.gov> Message-ID: <39A2A503.2BCBABE5@sandia.gov> References: <8nsccf$l80$1@blowfish.isaac.cs.berkeley.edu> Newsgroups: sci.crypt Lines: 61 "David A. Wagner" wrote: > > In article <39A16A60.2FB4F96C@sandia.gov>, John Myre <jmyre@sandia.gov> wrote: > > I'm wondering what (cryptographic) properties "salt" has to have. > > If I recall correctly, there is an excellent discussion in > R. Morris, K. Thompson, ``Password security: a case history,'' > {\em Communications of the ACM}, vol. 22, no. 11, Nov. 1979. Thank you! > A simplified answer is that the salt makes dictionary attacks > more costly: it prevents you from re-using off-the-shelf DES > hardware, and it forces you to try each dictionary word separately > for each user, rather than amortizing the cost of a dictionary > attacks across all users. Certainly that's the only constraint I've ever seen. <snip> > Using just the username would be bad (someone could build a > password -> encrypted-password codebook for specially targeted > users, e.g., "root"), Good point. > but username + fully-qualified server name > seems ok as far as I can see. A practical caveat was pointed out by Bill Unruh: watch out for changes. You wouldn't want to accidentally lock out everybody when you changed your network around. <snip> > Passwords are basically an obsolete technology, unsafe at any > speed. I'd recommend that you consider the alternatives to > passwords, and the risks of passwords, very carefully before > deploying any new systems that use passwords for authentication. What's your attitude towards the various "strong" password-based authentication protocols being worked these days? I mean EKE, SPEKE, SRP, SNAPI, etc.? It just depends on the situation, doesn't it? Ideally, we want two-factor or better authentication: something you know, something you have, and something you are. Whether that kind of stuff is practical depends on how much money you have to spend on security, and how much you are protecting. JM P.S. In fact the original reason I wondered about salt, was its use in SRP. It appeared to me that if the user could know the salt without asking the server, then you could get by with one less message. The question, then, was what to make the salt that the user would actually know, while not losing the properties salt has to have to maintain the security properties of the protocol. The advantage of using username+servername is that those values need to be entered (known) anyway.
Subject: Re: What is required of "salt"? Date: 22 Aug 2000 16:47:13 -0700 From: daw@blowfish.isaac.cs.berkeley.edu (David A. Wagner) Message-ID: <8nv3e1$ms1$1@blowfish.isaac.cs.berkeley.edu> References: <39A2A503.2BCBABE5@sandia.gov> Newsgroups: sci.crypt Lines: 20 In article <39A2A503.2BCBABE5@sandia.gov>, John Myre <jmyre@sandia.gov> wrote: > It just depends on the situation, doesn't it? Ideally, we want > two-factor or better authentication: something you know, something > you have, and something you are. Whether that kind of stuff is > practical depends on how much money you have to spend on security, > and how much you are protecting. The fundamental problem is that today's password systems were built under a threat model that is no longer relevant. Today, if you send a password over the network in the clear, it *will* be captured by eavesdroppers; if you force users to pick passwords, they *will* pick low-entropy secrets. Neither of these realities matches well with storing password hashes in a world-readable file or in requiring passwords for network access to computer systems. Once you figure out your threat model, you can talk about what is the right technology. But my claim is that the threat model that passwords were designed for is just so rarely seen today in computing that passwords are typically the wrong tool for the job.
Subject: Re: What is required of "salt"? Date: Wed, 23 Aug 2000 09:16:19 -0600 From: John Myre <jmyre@sandia.gov> Message-ID: <39A3EAC3.5D283777@sandia.gov> References: <8nv3e1$ms1$1@blowfish.isaac.cs.berkeley.edu> Newsgroups: sci.crypt Lines: 38 "David A. Wagner" wrote: <snip> > The fundamental problem is that today's password systems were built > under a threat model that is no longer relevant. Granted. > Today, if you send a password over the network in the clear, it *will* > be captured by eavesdroppers; if you force users to pick passwords, they > *will* pick low-entropy secrets. Yes, and yes. > Neither of these realities matches well > with storing password hashes in a world-readable file Indeed not! > or in requiring > passwords for network access to computer systems. Hm. This reads as though when you say "passwords" you mean only the technique you described above: storing password hashes in a world-readable file. I certainly agree that such a system is rarely appropriate. > Once you figure out your threat model, you can talk about what is the > right technology. But my claim is that the threat model that passwords > were designed for is just so rarely seen today in computing that passwords > are typically the wrong tool for the job. I think I'll repeat from an earlier post: what are your thoughts on the so-called "strong password methods" like SRP? Do you include them when you say "passwords are typically the wrong tool for the job"? Are user-memorized secrets usually hopeless, regardless of the cryptography? JM
Subject: Re: What is required of "salt"? Date: 23 Aug 2000 12:17:19 -0700 From: daw@blowfish.isaac.cs.berkeley.edu (David A. Wagner) Message-ID: <8o17vv$phv$1@blowfish.isaac.cs.berkeley.edu> References: <39A3EAC3.5D283777@sandia.gov> Newsgroups: sci.crypt Lines: 27 In article <39A3EAC3.5D283777@sandia.gov>, John Myre <jmyre@sandia.gov> wrote: > "David A. Wagner" wrote: > > or in requiring > > passwords for network access to computer systems. > > Hm. This reads as though when you say "passwords" you mean > only the technique you described above: storing password > hashes in a world-readable file. I certainly agree that such > a system is rarely appropriate. Oops, here I meant to refer specifically to sending passwords in the clear over a network. Somehow the "in the clear" phrase didn't survive my self-editing. Sorry. > I think I'll repeat from an earlier post: what are your > thoughts on the so-called "strong password methods" like > SRP? Excellent stuff, when the threat model is right. Sorry, I didn't mean to include them in my complaint about passwords. There are plenty of good uses for passwords (e.g., encrypting private keys; enable codes for smartcards; ATM PIN's); I only wanted to complain about the practice of using plain passwords without any appropriate accompanying crypto. I realize that my original post did a very poor job of communicating that intention. Ok, I think I'll go back to writing school now. :-/
Subject: Re: What is required of "salt"? Date: Tue, 22 Aug 2000 00:00:38 GMT From: jsavard@fNrOeSePnAeMt.edmonton.ab.ca (John Savard) Message-ID: <39a1c26e.140086@news.ecn.ab.ca> References: <39A16A60.2FB4F96C@sandia.gov> Newsgroups: sci.crypt Lines: 15 On Mon, 21 Aug 2000 11:44:00 -0600, John Myre <jmyre@sandia.gov> wrote, in part: >The main purpose of salt, as I understand it, is to ensure >that entries for the same password aren't the same (or rather, >that the adversary cannot tell that the entries are for the >same password). Is there more? Basically, it is meant to hinder precomputation. So if a hacker has a dictionary of possible passwords, instead of once computing the hash of each one, he must go through the whole dictionary for every password file entry he wishes to compromise. John Savard http://home.ecn.ab.ca/~jsavard/crypto.htm
Subject: Re: What is required of "salt"? Date: Thu, 24 Aug 2000 00:45:46 +0100 From: David Hopwood <hopwood@zetnet.co.uk> Message-ID: <39A4622A.8B8C9997@zetnet.co.uk> References: <39A16A60.2FB4F96C@sandia.gov> Newsgroups: sci.crypt Lines: 107 -----BEGIN PGP SIGNED MESSAGE----- John Myre wrote: > = > I'm wondering what (cryptographic) properties "salt" has to have. > = > Let me begin by restricting the question to salt as used in > password files. This might be the original Unix-style file, > or it might be some verifier-based setup. > = > The main purpose of salt, as I understand it, is to ensure > that entries for the same password aren't the same (or rather, > that the adversary cannot tell that the entries are for the > same password). Is there more? An attacker can start a dictionary attack at the time when he/she learns the salt. Therefore, the salt should be unpredictable, so that the attack can only be started when the password file is compromised. This point appears to have been missed in the other replies that stated that salts only have to be unique. It's also worth pointing out that passwords are often shared between different systems (there seems to be no practical way to dissuade users from doing this; I even do it myself despite knowing the risks). So even if we don't consider the time at which a dictionary attack can be started to be significant, salts should preferably be globally unique, not just unique on a single system. > Usually I see the assumption that the salt is "random". I > don't see, however, why this is so. The desired property is a high "guessing entropy" [1], i.e. it should not be possible for an attacker to order the possible salts in such a way that searching them in that order has a non-negligable probability of success, with a feasible amount of work. This is the same property that is needed for security of cryptographic keys against (slightly generalised) brute force attacks. Salts don't *necessarily* need to be strongly random in the sense required for the output of a pseudo-random function, or the keystream of an additive stream cipher (i.e. that each bit cannot be feasibly predicted with probability significantly greater than 1/2, given all the other bits). OTOH, if they are random in this strong sense, the length of salt needed will be shorter. > For example, what would be wrong with using a simple counter to > generate salt values? It is predictable; see above. > Or, what if the salt were the concatenation of the user name > and the server name (or address)? Also predictable. > Is there a reason to change the salt when we change the password? Yes, if changing the password is intended to contribute to recovering from a password file compromise. Another desirable property of passphrase hashes, rather than salts, is that they be computationally expensive (variably so, so that increases in processor speed do not obsolete the hash), and no more cost-efficient to calculate in a dictionary attack using special-purpose hardware, than they are on a typical machine in normal use. (One way of attempting to achieve the latter is to make the hash memory-intensive.) A good overview of this is [2], which suggests two concrete passphrase hashes based on these criteria. [1] David Wagner, http://www.cs.berkeley.edu/~daw/my-posts/entropy-measures [2] Niels Provos and David Mazi=E8res, The OpenBSD Project "A Future-Adaptable Password Scheme," Presented at USENIX '99. http://www.usenix.org/events/usenix99/provos.html - -- = David Hopwood <hopwood@zetnet.co.uk> Home page & PGP public key: http://www.users.zetnet.co.uk/hopwood/ RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 0= 1 Nothing in this message is intended to be legally binding. If I revoke a public key but refuse to specify why, it is because the private key has b= een seized under the Regulation of Investigatory Powers Act; see www.fipr.org= /rip -----BEGIN PGP SIGNATURE----- Version: 2.6.3i Charset: noconv iQEVAwUBOaRhuTkCAxeYt5gVAQEHxQgAuKXYLSiWjq79d1S1seQouQ3pyuFBOFM7 ZPbpBEOTpWXbfsHtTb4WCtyce3zzFVzoey/JVCuRttTWphihoSul9Apz4bCiaacm YIUHS3eOZANpbnX8wb9StuMk3w8tH0nX+IHptKweScbxX8HZqHKvdOI+7IpTLhco 1laB6jSFiftWfn/81zUHbYEh9vAtrNWNxObc9Dd+IfaBY3HIvFC6BZJNVABMZOCE fqzTQ1rBG6EKlkLbo+5wy6lh2OqmUF+atIBPWev87oT47sGKVQpwZI1BuNGAlJXY 0/KtO2A/gckXrfRznsifS1ZOC3gmkn9V3h0Qdj6MGsK/aap7G0nhjg=3D=3D =3DgQtK -----END PGP SIGNATURE-----
Terry Ritter, his current address, and his top page.
Last updated: 2001-06-27