From: Shawn McMahon Area: Public Key Encryption To: All 29 Sep 94 13:46:26 Subject: SecDev, SFS, etc. UpdReq Is there an OS/2-based counterpart to any of the secure drive programs? SecDrv, SecDev, SFS, anything? I know there's no OS/2 version of SFS yet, but is there anything along these lines available other than custom programming jobs from the consultants? 201434369420143436942014343694201434369420143436942014343694718 From: Shawn McMahon Area: Public Key Encryption To: Jess Williams 29 Sep 94 13:57:58 Subject: ENCRYPTION... UpdReq Despite the stern warnings of the tribal elders, Jess Williams said this to Shawn Mcmahon: JW> like the RSA key size. Why not make it able to generate a key JW> as big as you want?? Because if you make it's possible key size infinite in one version (not actually possible, BTW, there has to be SOME limit, which is operating-system and compiler-dependant, although that limit could be "keep going until you run out of address space") then you have to make EVERY version handle keys that size. PGP isn't supposed to be an "MS-DOS only" program; it's supposed to be easily platform-portable. People are using it under MS-DOS, OS/2, the Mac System, Unix, the Amiga OS, the Atari ST OS, and countless others. There thus has to be some kind of restriction on key size. As for why 1024-bits was chosen; I'm not certain, but I suspect it has to do with the fact that by the time computing power reaches a point where that's not enough, some better algorithm will probably have been found anyway. However, higher sizes can be "ramped up" to, as indeed MIT is trying to do now, by making PGP handle 2048-bit keys but not generate them. Never mind the fact that they screwed up and it doesn't handle them... :-) BTW, 1024-bit operations are tolerably short on my 486DX40; I suspect that 2048-bit operations would truly suck. I doubt Phil Zimmerman expects the average PGP user to be on equipment at least an order of magnitude faster than mine. Not that that'd be hard... :-) 201434369420143436942014343694201434369420143436942014343694718 From: jason carr Area: Public Key Encryption To: Shawn McMahon 29 Sep 94 10:02:42 Subject: Re: PGP Signatures UpdReq -----BEGIN PGP SIGNED MESSAGE----- Shawn McMahon wrote in a message to jason carr: SM> Despite the stern warnings of the tribal elders, jason carr SM> said this to all: jc> What do you guys think about this idea? SM> It's too Fidonet-specific. Well, yeah. But that's the purpose. Maybe someone could code in a switch that would hide the sig in a FTN msg. ??? jason ... I am here. Wish you were fine. -----BEGIN PGP SIGNATURE----- Version: 2.61 Comment: PGP_ECHO: Encryption, sigs, and fun in D-FtW... iQCVAwUBLorzlEjhGzlN9lCZAQHuUwQAowWXZcRDlKJ/V9BfkVmXGAoksI5C/0f+ KqmqblTOdEsjw8ljNA9yYJBcdhb4zFoPT37sp6JlOiIeBzrOUuYfKLOX6BcoaVW2 VV4PMhczXSMJBeQdUubHx0o8tu3jJ7vtJuK2Z0hghLadsW4XxaWOjV1Q6kwBKaGJ FiGopHbGQFs= =Tz2m -----END PGP SIGNATURE----- 201434369420143436942014343694201434369420143436942014343694718 From: John Schofield Area: Public Key Encryption To: All 28 Sep 94 17:35:20 Subject: Bug in PGP signatures UpdReq -----BEGIN PGP SIGNED MESSAGE----- Hello, all. I just wanted to report a bug in PGP I've found out about on ALT.SECURITY.PGP. I verified it, and it really works. The bug causes signatures to be verified as valid, EVEN THOUGH THEY ARE NOT. Yes, this is a very serious bug that apparently affects all versions of PGP, on every platform, including Viacrypt PGP. Here is how I replicated the bug: 1) Created a test text file, with two lines: This is a test of PGP. This is a two-line paragraph. If you see anything else in this pgp-signed message, there are serious problems here. 2) Clear-signed the message with PGP, producing: - -----BEGIN PGP SIGNED MESSAGE----- This is a test of PGP. This is a two-line paragraph. If you see anything else in this pgp-signed message, there are serious problems here. - -----BEGIN PGP SIGNATURE----- Version: 2.7 Comment: Call 818-345-8640 voice for info on Keep Out magazine. iQCVAwUBLooJVGj9fvT+ukJdAQEjGgQAmr5HZRVmrpXbrCc0gXhFMuKwrdlO9712 UThzUFCge6COg9LR1qvqkJMoQtUCkzND7DYTqA4j4/OBpsizd5FoyhVtH1ZZ39IR VifQvZgfORdJ4wxP2GYEJ7XKHJRUIRqom4kKCOZjf+8U/v2ZVDuq+UARoDLx+ZCR 9ve6V4e8hds= =kOPb - -----END PGP SIGNATURE----- 3) Now I added some text above the signed text. It is important that there be no blank lines in the bogus text, and that there be a blank line between the bogus text and the authentic text. - -----BEGIN PGP SIGNED MESSAGE----- This is text that will verify as signed, BUT IT WAS NOT PART OF THE ORIGINAL SIGNATURE. This text is BOGUS! This is a test of PGP. This is a two-line paragraph. If you see anything else in this pgp-signed message, there are serious problems here. - -----BEGIN PGP SIGNATURE----- Version: 2.7 Comment: Call 818-345-8640 voice for info on Keep Out magazine. iQCVAwUBLooJVGj9fvT+ukJdAQEjGgQAmr5HZRVmrpXbrCc0gXhFMuKwrdlO9712 UThzUFCge6COg9LR1qvqkJMoQtUCkzND7DYTqA4j4/OBpsizd5FoyhVtH1ZZ39IR VifQvZgfORdJ4wxP2GYEJ7XKHJRUIRqom4kKCOZjf+8U/v2ZVDuq+UARoDLx+ZCR 9ve6V4e8hds= =kOPb - -----END PGP SIGNATURE----- 4) Then I ran PGP on the first (unmodified) file. The signature checked out, and it produced the correct plaintext file. Then I rean PGP on the modified file. The signature checked out, and it produced the correct plaintext file. In both cases, the files PGP produced were correct. Conclusion: When checking a signature, If the first line after the "-----BEGIN PGP SIGNED MESSAGE-----" line is NOT BLANK, PGP will ignore everything UP TO the first blank line. This is NOT an error in the way PGP checks a signature--only an error in the way PGP decides what to check in the signature. The mathematical methods PGP uses to check signatures (the MD5 algorithm) are not affected by this bug, and are apparently still strong. Moral: When checking a signature, do NOT trust PGP when it says the signature is good. If PGP says a signature is bad, it is bad. If PGP says a signature is good, *LOOK AT THE OUTPUT FILE*. Everything in that output file is valid and signed. If there is any text that is in the clearsigned text, but NOT in the output file, you know there was an attempted forgery. JMS -----BEGIN PGP SIGNATURE----- Version: 2.7 Comment: Call 818-345-8640 voice for info on Keep Out magazine. iQCVAwUBLooLuGj9fvT+ukJdAQH8OQP/f04sEkdK6OFGoO6nNsX1rsJkmXBr6PUQ dP1k1YjvC7gQ3C4Iujc/STynKutz+bBuUbdzpaG7CGUnEzwIxqMOc/TEw/UHpSAc 7llLXt5lMVro2nvFBcjX74Xr/F1KFMOzri72PN9wA1Fi7antZ7JCfpGICNaj5QNt Xadku/LBY1s= =O6fD -----END PGP SIGNATURE----- **EZ-PGP v1.07 ... There is nothing so permanent as a temporary government program. 201434369420143436942014343694201434369420143436942014343694718 From: John Schofield Area: Public Key Encryption To: Tim Bradley 28 Sep 94 10:09:06 Subject: RC4 Revealed! UpdReq -----BEGIN PGP SIGNED MESSAGE----- --====-- TB> Not to mention that this is TOTALLY irrelevent, as the original TB> algorythm was published in an academic trade journal -- that's how the TB> whole dustup with Phil Zimmerman & RSA/PKP started in the FIRST place: TB> Phil read the PUBLICALLY AVAILABLE algorythm, and wrote PGP, unaware TB> that three months AFTER the article was published, the author decided TB> to apply for a Patent. I have *NO* clue why anyone even BOTHERED to TB> hack out the RSA algorythm's -- the gist of the data was already TB> published... The RC4 algorithm is not the same as the RSA algorithm used in PGP. JMS -----BEGIN PGP SIGNATURE----- Version: 2.7 Comment: Call 818-345-8640 voice for info on Keep Out magazine. iQCVAwUBLomQbWj9fvT+ukJdAQFF+AP/Uhf610sVnsrkMRs56ddSZJEoBdoNHmqH Tbvuk4Fwm+Gec9arXLo24ulLN9fL6PsdlHTge7GYAP3XuzxMCry29Fl4tnIiSYt+ 9aU8JsPGn7SoXUxOdSlDzSwaQvVABsrFi+l32KCELsK/vmnYRyEQUBkpvg+NuvXc DuNVytfPYbI= =EHdp -----END PGP SIGNATURE----- **EZ-PGP v1.07 ... What is the speed of dark? 201434369420143436942014343694201434369420143436942014343694718 From: John Schofield Area: Public Key Encryption To: Tim Bradley 28 Sep 94 10:09:06 Subject: RSA Broken UpdReq -----BEGIN PGP SIGNED MESSAGE----- --====-- RP> BTW, the 129 digit key that was broken recently was not only small, but RP> weak, in the sense that p and q were much too close one to another. JG> So, here we go. Weak IDEA keys have been discovered by a trio of JG> cryptographers in Belgium, although if you read Lai's original JG> thesis he talks a bit about this problem as well. [much explanation by Schneier deleted] TB> I do *NOT* have specific documentation that the key "broken" was TB> definately in this class, only that it was a "Weak" key. Since this TB> seems to be the professional cryptographer's definition of Weak IDEA TB> keys, I'd say it's a good bet... I haven't heard whether the key used in the broken message was weak or not. However, the message was encrypted with RSA, not IDEA, so potential weaknesses in IDEA are irrelevant to the discussion. JMS -----BEGIN PGP SIGNATURE----- Version: 2.7 Comment: Call 818-345-8640 voice for info on Keep Out magazine. iQCVAwUBLomRg2j9fvT+ukJdAQF4JwP9GO5Dll4PHbEUP78XxffrtL3w0FW2I4tj A4q+zb+P4u1vcanpdAkRY9y2p4ANDigkukXq9JcyDzlOgWSnQDBUqIiOEXU0ABdZ rGUi4aQrOGZNmyMMuQ8r0P5KvCfSqzDkuiQqujRveuGxibCdTajujVPBJ0P0Hzcv 48sgi/CEmQM= =3MpL -----END PGP SIGNATURE----- **EZ-PGP v1.07 ... There is nothing so permanent as a temporary government program. 201434369420143436942014343694201434369420143436942014343694718 From: John Schofield Area: Public Key Encryption To: Tim Bradley 28 Sep 94 10:09:06 Subject: Getting Started w/PGP UpdReq -----BEGIN PGP SIGNED MESSAGE----- --====-- TB> Speaking of PGPSort -- is the source code available? In the version I have, Pascal source is included in the archive. PGPSRT.ZIP from 1:102/903 (14.4k bps) 1:102/904 (28.8k bps) JMS -----BEGIN PGP SIGNATURE----- Version: 2.7 Comment: Call 818-345-8640 voice for info on Keep Out magazine. iQCVAwUBLomR2mj9fvT+ukJdAQGZkwQAmNJDO7w+ZMaqgXS1PmMjWCtzfUOjzFPB tWiKcGkI5uihKjDi8MwhZYgHHuswzh6O2hnHLUCQlLm67JCUm6guWOdXbL/JkelX JhbgLcn/Aypw4/8GJDmpz97SWvl2sDM41ExsSQM03uqn0T7K02Ll/NzST9RYGGtj 4waCsR64sgs= =mBhJ -----END PGP SIGNATURE----- **EZ-PGP v1.07 ... Call 818-345-8640 for info on Keep Out, the Electronic Privacy Journal 201434369420143436942014343694201434369420143436942014343694718 From: John Schofield Area: Public Key Encryption To: Wes Landaker 28 Sep 94 10:09:06 Subject: Net 106 still at it? UpdReq -----BEGIN PGP SIGNED MESSAGE----- --====-- WL> I never said it was illegal to not route it. It's illegal to WL> read it. And if they can tell if it's encrypted or not, then WL> they're LOOKING at it. :) RW> I disagree completely. WL> I'm very glad that you are not part of the routed-netmail WL> system, Richard, as obviously you haven't much of a grasp on WL> it's concept. Why do you want to destroy routed netmail so WL> much? RW> Oh, I understand the technical details quite well, thank you very RW> much. You may believe there is some special "philosophy" about RW> what routed netmail is about, I don't. I feel that routed The moderator has asked you to stop this stupidity, and you have not. Since you two insist on continuing this insipid argument, I am putting you both in my kill-file. This is a shame, because you might have something of interest to say later, but I can't put up with this anymore. Send comments through e-mail, because I won't see them here. JMS -----BEGIN PGP SIGNATURE----- Version: 2.7 Comment: Call 818-345-8640 voice for info on Keep Out magazine. iQCVAwUBLomS82j9fvT+ukJdAQG36wP/d2RzGkzMiLH84H6Yio0qPQPN/K0y+Fr9 uo0HVuEdLR43aE42tjrGiEUcPy8Gcr+qitLUZ/UP7srGGzKkhPMBc9QYMzKc+LJK SsIm7FbqShTjefADNEMiyu1kkh27GqHU5CBZYhQbXgan/0zFozEzVepyAI+XnZ1G edI2Lgohegk= =E728 -----END PGP SIGNATURE----- **EZ-PGP v1.07 ... "It's not frozen up, it's just resting." -- John Schofield 201434369420143436942014343694201434369420143436942014343694718 From: Rich Veraa Area: Public Key Encryption To: Raymond Paquin 29 Sep 94 10:16:12 Subject: RSA Broken UpdReq Raymond Paquin wrote in a message to Rich Veraa: RP> However, *THIS MAY CHANGE* (emphasis mine). New factoring RP> algorithms may be discovered that work better on numbers RP> with certain properties than on numbers without them. If RP> so, strong primes may be required once again.... RP> I recommend using strong primes even though they are not RP> necessary to make factoring difficult (my note: with RP> *PUBLISHED* factoring algorithms)...." RP> RP> Please read the last paragraph again and the *last* line in RP> it carefully... Thanks for the update... Actually, I've been compiling my "rv" versions with STRONGPRIMES defined. But am changing over to OS/2 and can't compile for that yet... Cheers, Rich 201434369420143436942014343694201434369420143436942014343694718 From: David Chessler Area: Public Key Encryption To: Shawn Mcmahon 26 Sep 94 23:21:00 Subject: Re: signing my own key. UpdReq On 09-23-94 (01:29), Shawn Mcmahon, in a message to David Chessler about "RE: SIGNING MY OWN KEY.", stated the following: SM>I'm still learning this stuff; the math is a little beyond me, and most >of my knowledge comes from Schneier's book. That isn't the place to start. Read and re-read the documentation, and get copies of the FAQs. To understand what IDEA does, get the article that ran last December in Dr. Dobbs. Once you understand the basics, in laymans terms, then you can approach the math books. BTW, get SFS110, and read the documentation. It's very good, and you will learn a lot, again, without a bunch of math. ___ __ chessler@trinitydc.edu d_)--/d chessler@cap.gwu.edu * SLMR 2.1b * E-mail: ->132 1:109/459 david.chessler@neteast.com 201434369420143436942014343694201434369420143436942014343694718 From: David Chessler Area: Public Key Encryption To: Shawn Mcmahon 26 Sep 94 11:37:00 Subject: Need recommendations UpdReq On 09-23-94 (01:57), Shawn Mcmahon, in a message to David Chessler about "NEED RECOMMENDATIONS", stated the following: SM> DC> Securing the computer physically is always a better idea. Think > DC> again about why it can't be done in this case. SM>I absolutely agree, David, but the client doesn't want to do what it >takes. Tell the client he's going to have to do something, and whatever he does is inconvenient. That's life. Making something secure also makes it less convenient. SM> DC> Actually, SFS may be more secure than SecureDrive, if the docs > DC> can be beleived. SM>Basically, it comes down to whether the NSA can be believed; they wrote >the hash algorithm he uses. Not relevant. You're trying to secure against a hacker. SFS is preferable because it *enforces* a minimum 10-character Key. From talking to other consultants, key security is the *real* problem with encryption. You will have to teach them pass-phrases and how to use them. SM>Personally, I suspect they have a way to beat it; but the resources of >the likely attackers are PCs and non-cryptographers. Guttmann, who is pretty well respected in the PGP community, thinks it's better than IDEA, and apparently has a lot of support. Since the hash algorithm was never intended to be an encryption mechanism, there's no reason to beleive there is a trap door. Hash algorithms are irreversable. SM> DC> I should hope not. Can this drive be a removeable and just put > DC> it in the safe at night? That's what the Pentagon does. SM>Nope; in fact, I can guarantee you that he'll use lousy passwords. I >did manage to get him to consider a couple tips, but they'll do no more >than double the time necessary to crack it by brute-force search. Then you must use SFS which won't let him use a weak passphrase. A 10 letter minimum won't be a single word, which will secure it against most brute-force attacks, including dictionary attacks. SM> DC> Will the client put the passphrase on paper? In his desk? On a > DC> post it note on the monitor? SM>Probably. I made sure to tell him that I could not guarantee that Tell him that if he puts it on paper *anywhere* in the office (home is probably OK), then he can forget about the whole thing. SM> DC> Most clients are lousy about passwords. And is the client > DC> one person or a staff? How many people have to have access? SM>Far too many. Hell, the fact that *I* know the password with which he >began (dunno if he's changed it) means too many people know. Well, actually it's important that at least 2 people know any passphrase, in case one dies or leaves the firm. What you can do is come in monthly and change the password for him. That helps security. >the data and take it home, and if he does he'll most likely be throwing >a dictionary at it on a 486-based home PC. SM>Eventually, he'll get in; but most likely not in time. Not with SFS and a good password, which SFS enforces. Make sure there is at least one digit or punctuation mark in the passphrase. ___ __ chessler@trinitydc.edu d_)--/d chessler@cap.gwu.edu * SLMR 2.1b * E-mail: ->132 1:109/459 david.chessler@neteast.com 201434369420143436942014343694201434369420143436942014343694718 From: David Chessler Area: Public Key Encryption To: Raymond Paquin 26 Sep 94 19:20:00 Subject: Rsa broken UpdReq On 09-18-94 (19:31), Raymond Paquin, in a message to Jim Bell about "RSA BROKEN", stated the following: RP>Um ... not quite. But you are right: there is such a thing as a weak >prime number: i.e. not all prime numbers are created equal. >Unfortunately, PGP does not check for weak prime numbers. Pity ... According to the RSA FAQ, recent methods of factoring do not distinguish between strong and weak primes, so it is no longer necessary or helpful to test for strong primes. ___ __ chessler@trinitydc.edu d_)--/d chessler@cap.gwu.edu * SLMR 2.1b * E-mail: ->132 1:109/459 david.chessler@neteast.com 201434369420143436942014343694201434369420143436942014343694718 From: David Chessler Area: Public Key Encryption To: All 26 Sep 94 23:19:00 Subject: Os/2 version of 2.6.1 UpdReq This message was from KAI UWE ROMMEL to ALL, originally in conference alt.security.pgp and was forwarded to you by DAVID CHESSLER. ----------------------------- Subject: Re: OS/2 version of 2.6.1 Message-ID: From: rommel@ars.muc.de (Kai Uwe Rommel) Newsgroups: alt.security.pgp <2e7b566a.415253@ars.muc.de> Date: Sat, 17 Sep 1994 22:49:46 +0200 References: <35332q$bn7@search01.news.aol.com> Distribution: world Organization: Private Lines: 19 X-Posting-Software: UUPC/extended 1.12j inews ( 3Jun94 11:06) davideagen@aol.com (DavidEagen) writes in article <35332q$bn7@search01.news.aol .com>: >Is there an OS/2 version out yet of 2.6.1? I tried compiling the source >code but I ran into a bunch of problems that I don't have time to fix >right now. Besides, I don't want to start messing with the code without >knowing exactly what I am doing. Thanks. It is now available outside the U.S. on ftp.informatik.uni-hamburg.de:/pub/virus/crypt/pgp/2.6.1/pgp261-os2.zip Kai Uwe Rommel -- /* Kai Uwe Rommel Muenchen, Germany * * rommel@ars.muc.de CompuServe 100265,2651 * * rommel@informatik.tu-muenchen.de Fax +49 89 324 4524 */ DOS ... is still a real mode only non-reentrant interrupt handler, and always will be. -Russell Williams * SLMR 2.1b * E-mail: ->132 1:109/459 david.chessler@neteast.com 201434369420143436942014343694201434369420143436942014343694718 From: David Chessler Area: Public Key Encryption To: All 26 Sep 94 23:20:00 Subject: Pgp 2.6.1 for atari avail UpdReq This message was from ERIC JOLLEY to ALL, originally in conference alt.security.pgp and was forwarded to you by DAVID CHESSLER. ------------------------- From: ewj8218@u.cc.utah.edu (Eric Jolley) Newsgroups: alt.security.pgp Subject: PGP 2.6.1 for Atari Available Message-ID: <35l24n$c17@u.cc.utah.edu> Date: 19 Sep 1994 16:08:23 -0600 Organization: University Of Utah Computer Center Lines: 9 NNTP-Posting-Host: u.cc.utah.edu X-Newsreader: TIN [version 1.2 PL0] MIT's PGP 2.6.1 is now available for the Atari ST. Check atari.archive.umich.edu in the atari/Newitems directory soon. -- \ Eric Jolley \ Mail me at: \ \ Film Studies Major, U. of U. \ Eric.Jolley@m.cc.utah.edu \ \ For PGP Public Key, \ or \ \ finger ewj8218@u.cc.utah.edu \ en351@cleveland.freenet.edu \ * SLMR 2.1b * E-mail: ->132 1:109/459 david.chessler@neteast.com 201434369420143436942014343694201434369420143436942014343694718 From: Carl Hudkins Area: Public Key Encryption To: Christopher Baker 29 Sep 94 06:20:12 Subject: Key? What key? :) UpdReq On (24 Sep 94) Christopher Baker wrote to Carl Hudkins... CB> let me know when and as what your key is available for freq. i like to CB> get them directly. 1:135/808 PGPKEY That will get you SPARKPGP.ARJ, which contains my key and those of any other PGP users on this system who have put their keys up, in separate .ASC files. At this time, I think I'm the only one. carl Boca Chica, Florida carl.hudkins@lunatic.com RIME ->1282 PGP: 2D1E1E39 Fido: 1:124/2113; 1:135/808 ... "Damn John Whorfin and the horse he rode in on!" --John Bigbootee 201434369420143436942014343694201434369420143436942014343694718 From: Carl Hudkins Area: Public Key Encryption To: Tim Bradley 29 Sep 94 13:39:00 Subject: PGPsort - source code? UpdReq 25 Sep 94 11:20, Tim Bradley wrote to Carl Hudkins: CH>> Just for the humorous value, I thought you might like to know CH>> that today I ran PGPSORT on a big Internet keyring I got by mistake a CH>> few months back (don't you love unattended FREQs?) and it found three CH>> =secret= keys in there! One was from a Steve Jackson. TB> Speaking of PGPSort -- is the source code available? I don't know. You can write the programmer, Staale Schumacher, at staalesc@ifi.uio.no and ask him, though. He's the maker of the popular Offline AutoPGP program, and usually answers his mail fairly promptly. carl Boca Chica, Florida carl.hudkins@lunatic.com RIME ->1282 PGP: 2D1E1E39 Fido: 1:124/2113; 1:135/808 201434369420143436942014343694201434369420143436942014343694718 From: Carl Hudkins Area: Public Key Encryption To: Christopher Baker 29 Sep 94 13:51:00 Subject: readers [Was: New To Pgp] UpdReq 26 Sep 94 16:58, Christopher Baker wrote to John Schofield: CB> In a message dated: 22 Sep 94, John Schofield was quoted as saying: JS>> No current mail-reader that I know of supports a decrypt function-- CB> GenMsg will decrypt a msg prior to replying if you wish. when you say CB> 'mail-reader' are you just talking about offline readers? What sort of software is GenMsg? Would it be suitable for use in a point system? I was doing ok with PPoint, but I run into a memory wall when trying to use PGP. This GoldEd thing is nice and fancy, and leaves plenty of memory free when shelling out (though it claimed to run out of memory the other day with 53 messages in this echo), but currently I can't keep it from re-wrapping my stuff, which pretty much hashes PGP sigs. As a result, I'm still searching for good software to use. Currently I have Hudson message bases, maintained with FastEcho. (I tried Squish because someone said it was a less buggy format, but couldn't get my various programs to talk to each other about the Squish bases. I have a very small message base, so Hudson should be fine.) Should I try GenMsg, and where can I get it? carl Boca Chica, Florida carl.hudkins@lunatic.com RIME ->1282 PGP: 2D1E1E39 Fido: 1:124/2113; 1:135/808 201434369420143436942014343694201434369420143436942014343694718 From: Rich Veraa Area: Public Key Encryption To: Tim Devore 29 Sep 94 18:12:48 Subject: Who's This Ashworth? UpdReq Tim Devore wrote in a message to Christopher Baker: TD> Slight correction in FidoNet a POINT is the lowest level TD> serving off a NODE. Nope. As far as FidoNet Policy is concerned, a point has no more standing than any user. Cheers, Rich 201434369420143436942014343694201434369420143436942014343694718 From: Christopher Baker Area: Public Key Encryption To: Tim Devore 30 Sep 94 00:59:22 Subject: making a point? [Was: Who's This Ashworth?]UpdReq -----BEGIN PGP SIGNED MESSAGE----- In a message dated: 28 Sep 94, Tim Devore was quoted as saying: CB> in FidoNet, a Node is the lowest level of the organization. a CB> Node is a TD> Slight correction in FidoNet a POINT is the lowest level serving TD> off a NODE. a point is nothing more than a User with a mailer. FidoNet is comprised of Nodes. what those Nodes do with their points is not part of FidoNet except the effect they may have on the standing of that Node. nothing personal against points. they are just Users as far as FidoNet Policy is concerned. TTFN. Chris -----BEGIN PGP SIGNATURE----- Version: 2.61 Comment: PGP 2.6.1 is LEGAL in Zone 1! So USE it! [grin] iQCVAwUBLoubMMsQPBL4miT5AQGlxAP/SDmjVrwfeKkKBGT+32Tyy28khgpro3l0 1tUR2rFFDoGrmkdYrsfcKjkJD/EK3GidrCnSb3tiUSSB4nHUaSsTH+C3Bcf6XfTH MB7Nzle49JNK8bf2MZxwlZ8CBU19v6mMIMDRMhRl/QDQpOOG9GDVioXIMWbvpVYP 419MbdBemxE= =6uWJ -----END PGP SIGNATURE----- 201434369420143436942014343694201434369420143436942014343694718 From: Christopher Baker Area: Public Key Encryption To: All 1 Oct 94 00:13:48 Subject: PUBLIC_KEYS Echo Guidelines - regular repostUpdReq -----BEGIN PGP SIGNED MESSAGE----- This is the PUBLIC_KEYS Echo. The purpose of the Echo is to provide a place to discuss public-keys for data privacy within FidoNet and elsewhere. We also consider electronic signature possibilities using public-keys and discuss data and software encryption and the various schemes and programs that produce them. This is a technical Echo with very few rules. Those very few rules are: 1. Stay on-topic. Topics of keys and encryption and related privacy and electronic signature issues are welcome. Others are not. 2. No politics [except as it relates to privacy issues] and no religion. 3. No personal attacks, slurs or innuendo. Stick to issues not personalities. 4. No Private flagged messages in Echomail! Encrypted traffic using public-keys is permitted for the exercise so long as it is on-topic. Don't send person-specific encrypted traffic. Such specific traffic belongs in direct Netmail. Encrypted traffic should be in the form of public-keys or public-key signed messages that can be read by anyone with PGP 2.4+ and your public-key. Include your public-key when sending such messages in case the other end doesn't have it or make them aware of how to get it from your system. 5. This Echo may be traveling around the world so try to be concise. Avoid excessive quoting for one-liner responses. 6. Be aware that Echomail is NOT secure. Don't take anything at face value. 7. The posts in this Echo are the sole responsiblity of the poster. If you need verification, use Netmail. 8. The Moderators will deal with off-topic traffic. Don't respond for them. Links to this Echo will only be curtailed when absolutely necessary so please don't make it necessary. [grin] The Moderators are Christopher Baker [KeyID: 1024/F89A24F9 1994/05/18] and GK Pace [KeyID: 1024/EE38FB41 1994/05/14] at 1:374/14 and 1:374/26, respectively. It is Gated into Zone 2 by Jens Mueller at 2:24/24 who sends it on to Harry Bush at 2:51/2. Consult Jens or Harry for Zone 2 feeds. The Echo is gated into Zone 3 by Jackson Harding at 3:800/857. [thanks, guys!] The other Zones are open [hint, hint]. It is recommended that individual, public-keys be made available via Netmail or by file-request with the magic filename: PGPKEY and that the public-key provided for that request by given a distinctive filename using part or all of each provider's name and address. For example, on my system, a file-request of PGPKEY will give BAK37414.ASC to the requesting system. A magic filename of KEYRING will yield extracts from my Public Keyring as BAKPUB14.ASC. This will avoid duplicate overwriting and make it easier to track the keys. Using standard magic filenames will make it easier to find keys and keyrings on different systems. The PGP and Privacy and encryption related files on each system should be maintained with a magic filename for file request. PGPFILES should be set on all participating systems to allow your current related files to be picked up at any time. It is suggested that the actual filename indicate the origin of the list to avoid confusion and overwriting. PGPFILES requested from this system gets the requestor a file called: PGP37414.LST. The contents of this Echo are archived on 1:374/14 as the area is purged. The current past traffic is in the file PUBKEY.ECO. Archived volumes of past traffic [P_ECHO1.ZIP - P_ECHO99.ZIP for example]. Files on this system are available anytime except 0100-0130 ET and Zone 1 ZMH at 1200-9600+ HST/V32 for FidoNet listed systems only. Request FILES for complete listings. This Echo is currently available on the Zone 1 Backbone. It has been EListed as of ELIST211. Please feel free to announce this Echo in all Nets and Networks. A companion Echo for the purpose of submitting public-keys only is now available as PKEY_DROP Echo. PKEY_DROP may be obtained via the same channels as PUBLIC_KEYS. NOTE: If you lose your secret-key password [or forget it] or your secret-key in a drive crash [because you failed to back it up on floppy], you cannot issue a revocation certificate. In that case, you should make a general announcement in all related Echos that your old key should be disabled using the PGP disable command [PGP -kd userid] for your userid. That keeps your useless key on their keyrings [so they won't be replaced from other lists who didn't get the word] and permits them to add a new key from you without one interfering with the other. Thanks. TTFN. Christopher Baker & GK Pace Moderators -----BEGIN PGP SIGNATURE----- Version: 2.61 Comment: PGP 2.6.1 is LEGAL in Zone 1! So USE it! [grin] iQCVAwUBLoziAMsQPBL4miT5AQEfpQP9Ft+/vZAb41nWTaIcN34s/wgkOTxsdHbf nmwYZI+VbH4MqL4BlrhDpswhQ17U0pkGZhyPfgZUXD8Zy/lJxSj7WxAnCDmUAncS LoubAv0MHrtP/AW6kRDmaFwWP8S88VcaWNFSiRD8kCBopyKiOvb5Ky4KErwpLN6z ST6uovKLjBA= =NojD -----END PGP SIGNATURE----- 201434369420143436942014343694201434369420143436942014343694718 From: Christopher Baker Area: Public Key Encryption To: All 1 Oct 94 00:14:36 Subject: PGP-related filename conventions UpdReq -----BEGIN PGP SIGNED MESSAGE----- [the following are the standard magicnames for various PGP-related files available from participating FidoNet systems. please adjust your magicnames to match those in the list. this will make it much simpler for folks to find PGP-related stuff they need. thanks] the following is the list of standard PGP-related magic filenames that should be used for uniformity by all who provide such files: PGPKEY for your public-key. make the filename distinctive with your Node number or name. mine is BAK37414.ASC. KEYRING for your public-keyring. make the filename distinctive likewise. mine is BAKPUB14.ASC. REVOKE for any key revocation certificates you might issue. mine is BAKREVOK.ASC. PGPFILES for your PGP/privacy/encryption filelist. mine is PGP37414.LST. PGP for the current version of MSDOS PGP executables and docs. PGPSRC for the current version of PGP source files. PGPALL for both executable and source. PGPAMIGA for Amiga version of PGP. PGPATARI for Atari version of PGP. PGPMAC for Macintosh version of PGP. PGPOS2 for OS/2 version of PGP. PGPUNIX for Unix version [if there ever is one] PGPVAX for Vax version [likewise] [send them the source if they request a Unix or VAX version!] if we all use the same conventions, it will be easy for anyone anywhere to file-request just what they want and get what they expect. [grin] thanks. TTFN. Chris p.s. in addition, some of us compiled PEM public-keys for Internet use. those keys and rings are available as: PEMKEY for your PEM public-key PEMRING for you PEM public-keyring C. -----BEGIN PGP SIGNATURE----- Version: 2.61 Comment: PGP 2.6.1 is LEGAL in Zone 1! So USE it! [grin] iQCVAwUBLoziMssQPBL4miT5AQH5PwQAi0fvR7xBRN/GE5ZzEiBQUeRPcq/CvuCd OBLPOyIl3R1nJcTCBHrn4RHy1dlt9E1nqLYHQigdkOPsEygl3mxecSIkhIMjHIhj gde0mexTuqJrTaAUKHC4EE/5M5RdBlEx+EX2U9LmaXheLXOz1FGcow9S/yQ+esr0 XiJdzfREQo8= =3pvf -----END PGP SIGNATURE----- 201434369420143436942014343694201434369420143436942014343694718 From: Christopher Baker Area: Public Key Encryption To: All 1 Oct 94 00:16:14 Subject: SecureMail Host Routing info UpdReq -----BEGIN PGP SIGNED MESSAGE----- The FidoNet (r) SecureMail System 30 Mar 94 Copyright (C) 1994 Jim Cannell [Source: GK Pace, 1993; Christopher Baker, 1994] Introduction: This document describes the SecureMail FidoNet (r) Routing System, its Statement of Purpose, and defines the principles by which it shall be operated. It should be noted that FidoNet is a registered trademark owned by Tom Jennings, used by permission to refer to the FidoNet, a hobbyist network of amateur, independent, interconnected systems (Nodes) providing E-Mail transfer services world-wide. Definition: SecureMail can be defined as a group of FidoNet Sysops who have volunteered to provide an alternative E-Mail routing service within the FidoNet Network. The SecureMail System is a component of the FidoNet Network. SecureMail is NOT an alternative, separate, or distinct network. Statement of Purpose: The primary purpose of Securemail, and reason for its creation is the desire for providing increased privacy in the routing of FidoNet E-Mail. The term privacy as used in the transfer of E-Mail is an arbitrary one. Absolute privacy cannot be expected. The degree of privacy obtained will always be related to the procedure(s), effort used to insure privacy, and should not be expected to be absolute if data is to be communicated from one place to another. Routing of E-Mail, as compared to sending it direct, cannot be expected to have as high of a degree of privacy as might be expected when sending it direct. Those who are engaged in operating the Securemail system do so with the primary goal of insuring that all E-Mail routed thru it be afforded the highest degree of privacy technically possible. Those using the Securemail System can expect to enjoy a higher degree of privacy than other forms of routing, but should not expect absolute privacy. Functional Description: The SecureMail System is a group of individual FidoNet Sysops who have volunteered to work together to provide the SecureMail Routing Service to FidoNet Sysops. This group is organized, but does not have authoritative positions. Each SecureMail Sysop is an independent volunteer furnishing a service. There are no monetary rewards, each Sysop contributes the resources he or she uses to provide the service, including all costs incurred in providing it. The operational structure may appear to have hierarchical order and indeed it does, however such structure implements a routing matrix, not positions of authority. The SecureMail operational philosophy can be described as cooperative autocracy. Each SecureMail Sysop is an independent operator who has volunteered to assume the various responsibilities required of an organized effort. No one is compelled to participate, but participation requires the performance of certain agreed upon functions, standards, and of course interaction as a group. Most of the activities parallel or are incidental to normal FidoNet activities. Routing Hierarchy: The basic routing strategy follows the normal FidoNet pattern of routing thru Zones, Regions, Nets, to Nodes. The difference is that SecureMail traffic is routed thru SecureMail Hosts rather than the FidoNet Hosts. A SecureMail Sysop serving in each position is referred to as a Host. There are functional (not Authoritative) positions such as Zone SecureMail Host (ZSMH) Region SecureMail Host (RSMH) and Net SecureMail Host (NSMH). An International SecureMail Host (ISMH) functions as a central coordinator for this functional hierarchy and maintains the routing lists and this document of intent and mission. Note that at any given time, all positions may not be filled, due to the fact that positions are filled by those who have the means and desire to provide the service of each position. Operational Practices: Each SecureMail Host (SMH) has agreed to route E-Mail (referred to as In-Transit mail) in a manner which provides the highest degree of privacy technically possible. Some variances can be expected, as the technical characteristics of each system differ, however each SecureMail Host strives to provide the best service possible. Specific operational practices include: - In-Transit mail shall not be read. Note that some systems do not provide the ability to restrict a Sysop from viewing In-Transit mail. In such cases the Sysop makes every effort to avoid noticing the content of such E-Mail as they scan thru their message bases. - The content of In-Transit mail shall not be disclosed, or given to anyone but the addressee, except as required for routing thru the SecureMail System. - All SecureMail Hosts agree to route any In-Transit mail they receive. This includes encrypted and clear-signed traffic now refused by some systems in FidoNet. In-Transit mail that cannot be delivered shall be returned to the sender along with a brief explanation of why it could not be delivered. If no local routing via another SMH is available, the mail will be sent directly to its destination by the receiving SMH. - In-Transit mail shall not be censored. Routing of In-Transit mail shall not be refused for any reason even remotely associated to the content of such E-Mail. Note: how could it be if it isn't read in the first place? Avoidance of Liability: Those participating in the SecureMail Routing System do so to provide a service at no cost to those who choose to make use of it. There is no guarantee of performance implied nor accepted by the SecureMail System as an organization, nor by the individuals who voluntarily participate to provide this service. Those who choose to make use of this service should recognize that although we strive to provide the best service possible, we cannot and will not offer any guarantees, nor do we accept any obligation for providing any service, or the performance of any service to a defined standard. Those who provide this service specifically deny any liability for the content of In-Transit E-Mail. Any liability that may apply must rest upon the originator. It is the stated practice of those who participate to provide this service, that In-Transit E-Mail is not read. On that basis, those who participate in the SecureMail Routing System will not have knowledge of the content of In-Transit E-Mail, will not censor, make judgements as to the legality, morality, nor suitability of any In-Transit E-Mail to be routed, before during or after having any contact with it. Those who participate in the SecureMail Routing System do so for the purpose of providing a service to others using the FidoNet E-Mail System. It is specifically denied that such service is supplied for the purpose of promoting, enhancement, implementation, or aiding the accomplishment of any illegal activity. No one participating in the SecureMail Routing System will knowingly allow its use to aid, abet, or otherwise participate in illegal activities, or make use of the SecureMail System for any illegal purpose. Further it is our stated operational practice that we shall not be engaged in viewing In-Transit E-Mail for the purposes of knowing whether or not the content of such could be considered illegal, and specifically deny that we could have any such knowledge. Those engaged in SecureMail Routing are constrained by the ECPA [Electronic Communication Protection Act] and FidoNet Policy in their ultimate handling of In-Transit E-Mail in regard to disclosure. Anyone who supports the goal of E-Mail privacy and who agrees to abide by the standards herein proclaimed, may apply to act as a SecureMail Host Routing System at their own expense and without regard to In-Transit E-Mail content. A list of current SMH Nodes is contained in the file SECUREML.MAP which accompanies this document. Applications may be made via direct Netmail to the ZSMH, RSMH, or NSMH closest to your area. International applications may be sent to the ISMH as listed in the map. Most SMH Nodes are identified by the flags listed above in the FidoNet Nodelist. Any questions regarding the SecureMail Routing System may be directed to any SMH listed Node. A FidoNet Echomail conference for all participating SecureMail Hosts is available as SECUREMAIL from any listed SMH. -30- TTFN. Chris -----BEGIN PGP SIGNATURE----- Version: 2.61 Comment: PGP 2.6.1 is LEGAL in Zone 1! So USE it! [grin] iQCVAwUBLozikcsQPBL4miT5AQFL3QP/UuudPPDJvPylvJUnMcJGOf+dPJ44HVos +eL/A3xIjSoVnocaLvnLX/9AvgLd1zTTH7SIfIcNCjwTw7dsO7k6YZxvkdOupb2X /S3xEijv9ZDpSEbH/b9MosN89gw/KRB+CBT6PLvI+orJarneRvJMA3VdIAVZ+ANo DlMetymyDk8= =JMGu -----END PGP SIGNATURE----- 201434369420143436942014343694201434369420143436942014343694718 From: Christopher Baker Area: Public Key Encryption To: All 1 Oct 94 00:17:22 Subject: SecureMail Host Routing topography UpdReq -----BEGIN PGP SIGNED MESSAGE----- SecureMail Host Systems Zone Sysop Address |--ISMH Jim Cannell 1:216/21 | | |--Z6SMH Open | |--Z5SMH Open | |--Z4SMH Open | |=================================================================== | |--Z1SMH Jim Cannell 1:216/21 | | RSMH Net Sysop Address Flag | |--- 10 Radi Shourbaji 1:143/110 X | | | SMH |-- 102 Dave Lord 1:102/338 | |-- 119 *none at present* | |-- 125 Barry Kapke 1:125/33 X | | |-- 352 John Burrows 1:352/333 X | | | |-- 143 Radi Shourbaji 1:143/110 X | |-- 161 Bill Faust 1:215/228 | | |-- 215 Joe Pye 1:215/25 | | | |-- 202 *none at present* | |-- 203 Lee Dohm 1:203/111 | |-- 205 Zorch Frezberg 1:205/1701 X | |-- 206 Dan Wilson 1:206/2507 X | |-- 207* Dave Sparks 1:207/212 | |-- 210 Steve Garcia 1:210/11 X | |-- 216 Jim Cannell 1:216/21 X | | |--- 11 Jeffrey Oxenreider 1:226/560 | | | |-- 120 Ryan Anderson 1:120/379 | |-- 226 Jeffrey Oxenreider 1:226/560 | |-- 2202 Ryan Anderson 1:120/379 | |-- 2215 Jim Bailey 1:2215/480 | |-- 2240 Ryan Anderson 1:120/379 | |-- 2410 Ryan Anderson 1:120/379 | | |--- 12 Jesse David Hollington 1:225/1 X | | | SMH |-- 167 Frederic Giroux 1:167/535 | |-- 221 Paul Henry 1:221/279 X | |-- 225 Brett Dubroy 1:225/100 X | |-- 252 *none at present* | | |--- 13 Marc Stuart 1:2624/402 X | | | |-- 107 *none at present* | |-- 267 Matthew Landry 1:267/109 | |-- 2613 Jack Mooney 1:2613/108 X | |-- 2624 Marc Stuart 1:2624/402 X | | |--- 14 Jason Buchanan 1:286/702 X | | | SMH |-- 285 Mike Riddle 1:285/27 X | |-- 286 Jason Buchanan 1:286/702 X | |-- 287 Danny Walters 1:287/507 X | |-- 291 *none at present* | |-- 296 *none at present* | | |--- 15 Dave Munhollon 1:128/86 X | | | SMH |-- 114 Allen Borovkoff 1:114/169 | |-- 128 Dave Munhollon 1:128/86 X | |-- 303 Thomas Lange 1:303/5 | |-- 314 Doug Preston 1:314/5 | | |--- 16 Todd Rourke 1:323/110 | | | |-- 323 Todd Rourke 1:323/110 | |-- 325 Frank Perricone 1:325/611 | | |--- 17 Ted Rolle 1:105/36 | | | SMH |-- 105 *none at present* | |-- 340 *none at present* | |-- 346 *none at present* | | | |--- 18 Christopher Baker 1:374/14 X | | [cbak.rights@opus.global.org] | | | |---- 3:800/857 Jackson Harding 3:800/857 X | | | |------- 285 Mike Riddle 1:285/27 X | | | SMH |-- 116 *none at present* | |-- 123 Scott Miller 1:123/416 X | |-- 135 Tom Cropper 1:135/327 [Down] | |-- 135* David Bobo 1:135/110 | |-- 151 James Barrett 1:151/132 X | |-- 360 Stephen Frazier 1:360/23 X | |-- 362 Jack Whaley 1:362/940 X | |-- 365 Chris Britton 1:365/200 X | |-- 366 Rob Buckman 1:366/844 X | |-- 369 *none at present* | |-- 374 GK Pace 1:374/26 X | |-- 375 Tom Jones 1:375/1 X | |-- 378 Sydney Marcus 1:378/10 X | |-- 379 *none at present* | |-- 3647 Gale D. Wilkerson 1:3647/1 X | |-- 3649 Chris Hunter 1:3649/17 X | | |--- 19 Mike Lenker 1:106/1776 X | | | SMH |-- 106 Mike Lenker 1:106/1776 X | |-- 124 Bob Ratliff 1:124/7020 | |-- 130 Dale Hopkins 1:130/908 | |-- 147 Bill Teasley 1:147/3660 X | |-- 170* Jim Watson 1:170/610 | |-- 382 Chuck Haynes 1:382/502 X | | |=================================================================== | | |--Z2SMH Harry Bush 2:51/2 | | | RSMH Net Sysop Address Flag | |--- 50 (Russia) Dmitry Kiselev 2:5026/3 | | | |-- 5022 Dmitry Turevsky 2:5022/8 | SMH |-- 5026 Dmitry Kiselev 2:5026/3 | | |--- 51 (Latvia) Egons Bush 2:5100/8 | | | SMH |-- 5100 Egons Bush 2:5100/8 | | |=================================================================== | |--Z3SMH Jackson Harding 3:800/857 | | RSMH Net Sysop Address Flag | |--- 51 Jackson Harding 3:800/857 | | | |-- 800 Jackson Harding 3:800/857 Note: Those nodes listed with an asterisk "*" are accepting SecureMail for their Nets, but do not currently route mail from their Nets thru SecureMail channels. SecureMail Hosts are identified by the following flags in the FidoNet Nodelist: ISMH - International SecureMail Host ZSMH - Zone SecureMail Host RSMH - Region Securemail Host NSMH - Net Securemail Host SMH - SecureMail participating Node [these flags may or may not be preceded by a U in the Nodelist.] SecureMail Hosts are requested to ask their Local Coordinator for the appropriate UserFlag for their primary Node number. Those currently flying the ?SMH flag in the nodelist are show with an X by their node number. Complete information on the FidoNet SecureMail Host routing system is available by file-request or first-time download as SECUREML.ZIP from the ISMH or any of the RSMH systems. -30- TTFN. Chris -----BEGIN PGP SIGNATURE----- Version: 2.61 Comment: PGP 2.6.1 is LEGAL in Zone 1! So USE it! [grin] iQCVAwUBLozi1csQPBL4miT5AQE1ogQAmUIirBmS8/dV2dP/jz9lUfDdMjGc+SVk HgAimU/ErUkGMuzQbBa+6vK/24r1Ekfkw9zWbuclYi/v+safPFu62qvyv/3iL0J4 mO64qllIk5DcywSzX8Hy5HI+rsETgaXdT9n5XACC+4IlDFGz50odEk/OHY8SkOXN qFsfE98YG+o= =GFk8 -----END PGP SIGNATURE----- 201434369420143436942014343694201434369420143436942014343694718 From: Jackson Harding Area: Public Key Encryption To: Richard Godbee 24 Sep 94 18:06:00 Subject: Signing Messages and Other 'Newbie' Questions...UpdReq Hello Richard! Thursday September 22 1994, Richard Godbee writes to All: RG> --CUT HERE-8<-- RG> To sign a plaintext file with your secret key: RG> pgp -s textfile [-u your_userid] RG> --CUT HERE-8<-- RG> Okay, I think this is how most of you here sign all of your messages, but RG> (I'm probably wrong here; I just want to make sure) would this give away RG> your secret key? Why not sign it with your public key? Signing a message does encrypt the message, it provides a method of confirming authenticity of authorship and content. It does not reveal the secret key, it merely creates a signature based on the contents of the message and the secret key. The public key and only the public key can be used to extract the message information from the signature and compare it to the text of the message, if they match then only the person to whom the public key comes from could have signed the message. If you signed the message with your public key then only the secret key could be used to check the message, not a good way of confirming authenticity since only you have the secret key. Bye for now, Jackson 201434369420143436942014343694201434369420143436942014343694718 From: Jackson Harding Area: Public Key Encryption To: Joe Noel 24 Sep 94 18:07:00 Subject: PGP Signatures UpdReq Hello Joe! Thursday September 22 1994, Joe Noel writes to ALL: JN> Got a couple questions for all you moderators. How many of you allow JN> encrypted messages in your echos? If you do not allow encrypted messages, JN> do you allow the PGP ENCRYPTED SIGNATURE lines? I allow signatures, I don't see that encrypted echomail serves any purpose, if you want to send encrypted mail why not send it direct to the recipient via netmail? JN> What brought this up is that our net recently had a couple people start JN> sending netmail with PGP thru me. I bounced them, had a vote and the net JN> as a whole decided not to allow encrypted messages in our net. NOW they JN> are claiming that a signature is not an encrypted message. From what I JN> can see, encryption is encryption whether it be a message or a signature. No, an encrypted message is an encrypted message, a signature is a digital construct made from the text of the message and the secret key of the person signing the message. This uniqueness lets you confirm that the person claiming authorship is the person who holds that secret key and that the message has not been altered since signing. It does not contain any hidden text or useful information and is usually deleted by programs that verify sigs. All it adds is extra bytes to the message. And since you can still read the entire message, and nothing is hidden, how can the message be said to be encrypted? JN> Further, does anyone that uses PGP happen to know (or can test for me), if JN> a person already has the correct signature (possibly sent in another JN> message), could they actually put the message where the signature should JN> be and then the receiving person just edit the message stripping the old JN> PGP SIGNATURE lines add the correct signature back to the bottom? To me JN> it looks like it would be easy to do. I'm sorry what exactly do you mean here? Each signature is unique for each message and secret key. If I sign two different messages the signatures will be different and if two people sign the same message with their own secret keys then those signatures would differ also. Someone could strip the signatures off, add their own but then the name of the author and the name of the key used to check it would be different, all that would do is confirm that someone had done something to the message, sort of like a bank robber spray painting his name, address and phone number on the inside of the vault :-) Bye for now, Jackson 201434369420143436942014343694201434369420143436942014343694718 From: Jim Cannell Area: Public Key Encryption To: John Schofield 30 Sep 94 18:27:04 Subject: Bug in PGP signatures UpdReq -----BEGIN PGP SIGNED MESSAGE----- In a msg on , John Schofield of 1:102/903 writes: JS> Hello, all. I just wanted to report a bug in PGP I've found out JS> about on ALT.SECURITY.PGP. I verified it, and it really JS> works. The bug causes signatures to be verified as valid, JS> EVEN THOUGH THEY ARE NOT. Yes, this is a very serious bug JS> that apparently affects all versions of PGP, on every JS> platform, including Viacrypt PGP. JS> When checking a signature, If the first line after the JS> "-----BEGIN PGP SIGNED MESSAGE-----" line is NOT BLANK, PGP JS> will ignore everything UP TO the first blank line. This is JS> NOT an error in the way PGP checks a signature--only an error JS> in the way PGP decides what to check in the signature. JS> The mathematical methods PGP uses to check signatures (the MD5 JS> algorithm) are not affected by this bug, and are apparently JS> still strong. It looks like a work around would be to always make sure that the first line in any PGP signed plaintext is blank. Don't trust anything in which the first line is nonblank. I'll play with this idea to see if it works. Jim - International SecureMail Host (ISMH) PGP key 1024/B7822B3D fingerprint = 0F F4 79 06 3B 33 99 D1 07 36 66 66 80 85 76 B3 Protect your right to privacy. Say no to GAK. -----BEGIN PGP SIGNATURE----- Version: 2.6 iQCVAwUBLoy75CWTIMO3gis9AQFRsgP/XCdIdZqO6ig56zGi6lXq5tKqNerHciUb 8rQPSgJS21Ekf4BGspkBxhcLCt82azz7Mm5QS2J0UiTIEev0LuLxlj9IfrAF2jsS FI34+dzuzFGzEzIWTGIbQkarTz4R9V1T0OuPIh1xyGLMH5J3DAXfL6hLlifnH77s ds0CLk8yugw= =b0lx -----END PGP SIGNATURE----- 201434369420143436942014343694201434369420143436942014343694718 From: John Nieder Area: Public Key Encryption To: mark lewis 28 Sep 94 16:31:08 Subject: Securemail UpdReq -=> Quoting mark lewis to John Nieder <=- ml> the solution you are looking for is the one that the SysOp has to ml> provide. ml> talk to your sysop... if you can persuade him to reconfigure then ml> you'll have the "problem" licked... Sysop's response is that it's too much trouble to change the outgoing netmail destination, even though it's a local call to the SECUREMAIL hub. No further explanation seems to be forthcoming. Disgusting. 201434369420143436942014343694201434369420143436942014343694718 From: John Nieder Area: Public Key Encryption To: Christopher Baker 29 Sep 94 22:33:30 Subject: Re: Securemail UpdReq -=> Quoting Christopher Baker to John Nieder <=- JN> Back to Square One and the redoubtable Mr. Ashworth. CB> i asked him directly what the problem was. he advised me that the CB> person in question was 'demanding' his traffic be routed. For what it's worth, that is an absolute, baldfaced lie. I saw copies of all the correspondence. The original poster received a note from Ashworth threatening action if Ashworth saw any more PGP messages from him (there had been only the one). Ashworth did not identify himself as any variety of netgod, and was not the intended recipient of the message. My friend wrote Ashworth asking for clarification, not only of the problem, but also of who Ashworth was and what he was doing intercepting his private mail (certainly a couple of valid questions). No "demand" was made save for a well-deserved explanation. CB> or you could start your own system. [grin] Not bloody likely... CB> you don't have to have a BBS to be a FidoNet Node. I'll pass; this whole mess has reconfirmed my worst impressions of Fidonet. I'm going back to Internet. JN 201434369420143436942014343694201434369420143436942014343694718 From: Tim Bradley Area: Public Key Encryption To: Shawn McMahon 30 Sep 94 02:34:22 Subject: RC4 Revealed! UpdReq In a message of 28 Sep 94 Shawn McMahon wrote to me: SM> And here's the first of the many messages I predicted, mistakenly SM> thinking the author was referring to RSA. Might that be because the author was terminally unclear as to what he WAS refering to? As you didn't quote the original text, I will: JB> San Francisco-- In an act of business espionage whose effects are nto JB> yet clear, someone has anonymously circulated the underlying formula JB> of one of the most popular coding systems used to protect information JB> sent over computer networks. JB> JB> The formula, which has been a closely guarded trade secret, belongs JB> to RSA Data Security Inc. a small, privately held software company in JB> Redwood City, Calif... [Executive whimpers deleted...] JB> The formula, which is known as RC4, has become the de facto coding JB> standard for many popular software programs. The clear implication is that the reporter considers them one & the same (ie, that the official label FOR the "RSA Encryption Algorythm" *IS* RC4). While this may not be true, the fact that the reporter BELIEVES it to be true DOES throw the significance of this "Espionage" into question. Which is all I said. SM> Note the subject line, Tim. Like subject lines bear any causal relationship to ACTUAL message content? That's kind of like the frictionless pulleys you do high-school physics problems with, right ? SM> Thank you for proving my point. :-) You're welcome, as long as your point was that the original article was unclear and only marginally significant in terms of actual industry impact ... otherwise, see my above comment . Later Daze, -- Tim Bradley 201434369420143436942014343694201434369420143436942014343694718 From: Tim Bradley Area: Public Key Encryption To: Raymond Paquin 29 Sep 94 14:29:30 Subject: RSA Broken UpdReq In a message of 27 Sep 94 Raymond Paquin wrote to me: TB>> I do *NOT* have specific documentation that the key "broken" was TB>> definately in this class, only that it was a "Weak" TB>> key. Since this seems TB>> to be the professional cryptographer's definition TB>> of Weak IDEA keys, I'd TB>> say it's a good bet... TB>> Later Daze, RP> Before we get too far on this subject, I would like to emphasize that RP> we were NOT discussing weak IDEA *keys* but rather weak RSA prime RP> numbers, two entirely unrelated subjects. RP> Ciao... Actually, the ORIGINAL question was concerning weak *PGP* keys ... and I'll freely admit that I don't have the cyptographic expertise to determine how EITHER of those subjects (IDEA Keys os RSA Primes) relate to the original issue if they aren't the same thing ... :) Later Daze, -- Tim Bradley 201434369420143436942014343694201434369420143436942014343694718 From: Charles Senescall Area: Public Key Encryption To: Christopher Baker 30 Sep 94 18:44:00 Subject: SecureMail Routing Mission statement UpdReq Hi Chris, > The FidoNet (r) SecureMail System > 30 Mar 94 > Copyright (C) 1994 Jim Cannell > [Source: GK Pace, 1993; Christopher Baker, 1994] > Avoidance of Liability: [...] > Those engaged in SecureMail Routing are constrained by > the ECPA [Electronic Communication Protection Act] and > FidoNet Policy in their ultimate handling of In-Transit > E-Mail in regard to disclosure. Could this paragraph be amended to the effect that nodes will be constrained by ECPA, where applicable, (say in the US or whatever) and other relevant legislation as may apply from time to time in respect of relevant participating nodes in other jurisdictions? Regards.......Charles (FidoNet 3:640/217.111) 201434369420143436942014343694201434369420143436942014343694718