December 2003 - cypherpunks-legacy

Re: ID of anonymous posters via word analysis?
by jon＠balder.us.dell.com 17 Dec '03

17 Dec '03

People interested in fingerprinting anonymous posters might be interested in a Markov tuple analysis program that was posted to the net eons ago. It should be in the '85 or '86 comp.sources under the name markov3. I recall that this was a program that fed enough posts from a given poster would create another post in their "style"; it was kinda fun. Jon -- ,,, (o o) Jon Boede ----ooO-(_)-Ooo---- jon(a)dell.com +1 512 728-4802 Engineering, Dell Computer Corp. Server OS Development Austin, TX "The problem is that _they_ see us as *them*." -- John Gilmore, Cypherpunk

3 2

Get this (from alt.security.pgp)...
by mikeingl＠news.delphi.com 17 Dec '03

17 Dec '03

>Newsgroups: alt.security.pgp,talk.politics.crypto,comp.org.eff.talk >Path: news.delphi.com!noc.near.net!howland.reston.ans.net!spool.mu.edu!sgiblab!rtech!amdahl!netcomsv!netcom.com!strnlght >From: strnlght(a)netcom.com (David Sternlight) >Subject: L'Envoi >Message-ID: <strnlghtCFoIwF.IqG(a)netcom.com> >Followup-To: poster >Organization: DSI/USCRPAC >Date: Fri, 29 Oct 1993 22:09:50 GMT >Lines: 60 >Xref: news.delphi.com alt.security.pgp:5751 talk.politics.crypto:1071 comp.org.eff.talk:20845 When I began participating in cryto discussions here, there were several issues of interest to me. One was to encourage RSADSI to permit a "U.S.-legal" version of PGP. I have worked behind the scenes with RSA to encourage that, and it now appears that with ViaCrypt that goal has been reached for DOS, and one assumes soon for Unix and the Mac. Another was to make it clear that I thought both that pgp 1.x and 2.x were infringements of PKP's patents in the U.S. and those who encouraged or supported that were acting in a counterproductive way to RSA's permitting a licensed version. I've made my views very clear on this, and now that ViaCrypt is out, the issue is somewhat stale. A third was my concern that PGP2.x was the result of violating U.S. law. Since a Grand Jury is now investigating this matter, I am happy to leave it, whatever the outcome, in the hands of the professionals. I claim no personal credit for any of the above developments. Along the way I electronically met many colleages who vigorously but civilly disagreed with some of my views and advocacies. They have earned my undying respect and admiration. I also met some who were, not to put too fine a point on it, badly in need of having their mouths washed out with soap. They will remain in memory for who they have shown themselves to be. My biggest single disappointment was with Mike Godwin and EFF. I had considered them to be professionals working on issues I supported. I now believe they are petty special pleaders riding a particular hobby horse, and to some extent a toy of their major funders. They have, again in my view, shown themselves not above both inaccurate propaganda statements, and a complete inability to acknowledge and correct such errors when they arise. Thanks to the many who sent me e-mails of support during this whole experience. Thanks also also to the few who had genuine disagreements and expressed them civilly in e-mail. Since the main issues of concern to me now seem to be well in train, it's time to use my energies in other ways. Thus I am removing talk.politics.crypto and alt.security.pgp from my reading lists. I am always available via e-mail, and would welcome news from colleagues who wish to take the trouble to write me on how Phil Zimmerman is doing, how the Grand Jury proceedings are coming along and with what result, and when "U.S.-legal" Mac and Unix versions of PGP become available. For those who are curious, when I need encryption my current tools of choice are TechMail for correspondence flowing via POP Mail servers, and MacRipem for point-to-point traffic to other Macs. I am also experimenting with the new Mac System 7 Pro and an illustrative application Apple sent to developers that handles internet mail within it. I understand Ripem Mac will fit into this model and accept the System 7 Pro signer keys for encryption, and I'm going to work with that as well. David -- David Sternlight When the mouse laughs at the cat, there is a hole nearby.--Nigerian Proverb

1 0

ANON: anonymous mail
by remail＠tamsun.tamu.edu 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- The remailer at elee9sf(a)menudo.uh.edu now pads messages. So as not to be too annoying, messages under 1K are padded to 1K; larger messages are untouched. Padding is calculated by the size of the message body as it goes to sendmail - the header doesn't enter in the calculation. This remailer also caches messages until midnight; this is being mailed out early because I forced it. This message is shorter than 1K, so there will be some padding below (after the signature block). Coming soon: explanation of what I'm doing :-) Karl Barrus <klbarrus(a)owlnet.rice.edu> -----BEGIN PGP SIGNATURE----- Version: 2.3a iQCVAgUBLNEygIOA7OpLWtYzAQFTggP/ZNq3NbDzKAAwflRxtFBQ9XBohHnlnYWz gPY35v4tyLyalxMFLrjg2RXqRCZwwsMVKeXdq8x4m7m8LETV2cQyBJpHZUFJNRk6 9it59a47Uvk4MxSLWwsNE7NeBagjT4XluYjYBQqMxXc7Cu641IGUvPNpkwtBfEKy IklE0fm7Z0A= =eNuW -----END PGP SIGNATURE-----

1 0

Paranoid
by nobody＠Menudo.UH.EDU 17 Dec '03

17 Dec '03

>>> Does this allow a cracker to search for the compression's signature >>> after every attempt? >Every attempt? You mean every attempt at encryption? Well, yes and >no. Yes, there is a semi-known plaintext inside the encrypted data. >It is unknown if this can help an attacker. "unknown" doesn't provide anyone with very much reassurance. >>> Would using UUENCODE on the text and deleting the "begin/end" lines >>> before encrypting it have a synergistic effect on the difficulty of >>> cracking a secret key from that particular message? >This would give an attacker even MORE of a plaintext attack, since >this will create lines of 64 characters, starting with an "M", which >gives a regular pattern to the plaintext. Not all versions of UUENCODE start each line with an "M" and there are other programs similar to UUENCODE that can be used. The synergistic effect would also be due to the fact that the cracker would be clueless to the fact that UUENCODE was being used, but only if there is no type of checksum or compression signature that was being used instead of a spell checker. A spell checker?? This is insane. There has got to be some type of checksum code that verifies if the text was decrypted properly or not. Crackers can't possibly be trying keys and word searching for "the" or "and". Where have all the code writters vanished to? Doesn't the recursive use of DES have a synergistic effect? >>> Is there an easy way to generate keys larger than 1024 bits? >No. However given current technology and assuming no significant >breakthroughs in factoring algorithms, a 1024 bit key wont be broken >for over a million year (significantly more, if I recall). My opinion ---> What TotalFuckingBullshit(tm) <--- Technology is growing exponentially. Try: "for over 10 year[sic]" Any decent "personal computer" can crack mediocre DES encryptions in a semi reasonable amount of time. 10 years ago how many people do you think thought that this would be possible? Is there some type of design flaw that limits RSA keys to 1024 bits??

2 1

Re: Paranoid
by Mike Ingle 17 Dec '03

17 Dec '03

Warlord wrote: >You asked "Is there an easy way to generate keys larger than 1024 >bits?" I answered No. This is true, there is no way, currently, in >PGP, to generate keys larger than 1024 bits. Is there a design flaw? >No. It was an implementation decision. It does not mean that the key >size will not be increased in a future release. PGP23a for DOS will create a 1264 bit key if you enter the key size manually at the prompt. Key generation will take a long time, and secret key operations (decryption and signing) will be slow. Not that anyone actually needs a 1264 bit key, but it is possible.

1 0

Re: ID of anonymous posters via word analysis?
by felix＠hu.se 17 Dec '03

17 Dec '03

>Edward J OConnell writes: >One could also imagine a 'symantic scrambler' analogous to the word >analysis program, but designed to defeat it, by randomly altering the >syntax of a post. It doesn't have to be random. You could have a neural network style translation of sentences. You would train the network by having a known pre-written sentence as output, and a sentence with the same meaning, but with your personal syntactic style. It would also be possible to do lexical or paragraphical translation. With this scheme, you can have as many writing styles as you want (e.g. one for each poster). If you want to look like Shakespeare, just train the network with a couple of (pair of) sentences of Hamlet. ---------------------------------------------------------------------- True Name: Felix Ungman "Gen is god and your God is not"

1 0

ANON: anonymous mail
by nobody＠indirect.com 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- I thought I'd describe why you would want to pad anonymous mail. Currently, the destination and contents of email you send isn't private. It is possible for any number of people to snoop your mail as it travels to its destination. For privacy, you can encrypt your mail. Suppose Alice has an email account as learns that email is about as private as a postcard. She decides to encrypt all of her email, and all of her correspondents agree to do the same. So now, nobody can read her mail. But, who she communicates with still yeilds information. This is called traffic analysis, and I won't go into it here. So, enter anonymous remailers (see Chaum's "Untraceable Electronic Mail"). Currently several people on this list are experimenting with and running anonymous remailers. The remailers accept instructions (optionally encrypted) and resend messages, making it look as though the mail originates from the remailer. Now Alice sends and receives all her encrypted mail from an anonymous remailer. Somebody snooping Alice won't learn the contents of her mail, or even with whom she communicates. (She could even keep private what USENET news she reads by borrowing a trick from Mr. Slippery in "True Names" - just download everything and read what you want at home.) Another security enhancement is chaining the anonymous remailers, instructing one to mail to another, and so on, eventually delivering mail. Alice and her friends do the same, and they continue to privately communicate, keeping their various identities secret. If the snooper just watches the first remailer, he will learn that her mail goes to another remailer, etc. Now the snooper would need to watch more remailers to figure out who Alice is talking to. - From time to time, people suggest a probabalistic remailer, either forwarding mail to another remailer, or delivering it immediately. This actually reveals the final destination to more remailers than before. For example, if Alice chains mail A-B-C-final, then only the C remailer knows the final destination. But if the remailers implemented some probabalistic scheme, then each one will have to be given the final destination. To make it harder for a snooper, the remailers decide to cache their remailing requests, sending them out periodically instead of immediately. Now, a snooper would see a steady stream of mail into the remailer, and nothing coming out until suddenly, the remailer sends out all of its queued messages. If a large number of messages are stored to be remailed later, the snooper isn't able to easily match up incoming and outgoing messages. Now we come to message padding. If a snooper watches the incoming and outgoing mail, perhaps the size of the mail will provide enough information to link sender to destination, even if it is cached and remailed along with several other messages. So, to defeat this, the remailer can pad all messages to be a certain length. The best way for this to work is if a snooper can't figure out what is padding and what isn't. For plaintext and digitally signed (only) documents, this is not too difficult. But, for encrypted messages, if the remailer could insert padding into the encrypted text itself, or add in padding which would be ignored upon decryption, then it would be very difficult, if not impossible, for a snooper to determine what is and what isn't padding. The system implemented at the elee9sf(a)menudo.uh.edu remailer is a simple type - it pads the message body to a certain length. But it is pretty obvious what is padding and what isn't - so if a snooper is in a position to determine the length of a message (say they are trying to match up source and destination), they probably will be able to read the message and throw the padding out on their own. A better system would be one that pads inside encrypted text. This can be done with a pgp encrypted message by padding the end of ascii encrypted text and adjusting a few bytes (length fields, etc.). The message can still be decrypted, and the excess padding bytes will be ignored. Such a system is in the works... and it is reasonable to pad encrypted messages since it is much harder to detect and you will probably encrypt text sent through an anonymous remailer to get the maximum benefit. (If you don't mind everyone reading what you wrote you could use a dc-net and generate plaintext :-) Another useful technique is an anonymous pool, where everybody in the pool gets every message. Since everybody subscribing to the list receives every message, it would be extremely difficult for a snooper to determine to whom such a message is really intended for. You could use a newsgroup for the same purpose - post encrypted text to some group and your friend would read the group and retreive the message. Also, from time to time people wonder about errors and whether failed mail can be bounced back or whatever. The difficulty here is that the anonymous remailers try to keep information about source and destination to a minimum. For instance, a message may be routed through several remailers; the previous hop may be another remailer, so it wouldn't be useful to bounce the message back. Some remailers drop bounced mail, others wind up appending to a log file. A good solution currently implemented at extropia.wimsey.com is to use an anonymous pool for error reporting. Karl Barrus <klbarrus(a)owlnet.rice.edu> -----BEGIN PGP SIGNATURE----- Version: 2.3a iQCVAgUBLNH9eYOA7OpLWtYzAQEPzQP/QYeciQf7TKimj67xQRWScov848bcauF6 hlFOfoF4MFSm7mhD1bPks7xiwZuYO6P+MwkaeMqBKYQfWzBi37Blx5PNo3iK6Dmk pmeGsYqew34oPxk7Exvsu7uOcKhFAhBcEWvElJ+ytMjEbuY8EsHoGGETXpPVK87C OFkNxCrdqYY= =J/5q -----END PGP SIGNATURE-----

1 0

Re: Paranoid
by Karl Lui Barrus 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- I'm not exactly sure what this thread is about :-) but I do have some numbers: Differential cryptanalysis of DES requires 2^47 = 140737488355328 = 1.4 10^14 known plaintexts. The complexity of a brute force DES attack (keysearch) is 2^56 = 72057594037927936 = 7.2 10^16, or 2^55 = 36028797018963968 = 3.6 10^16 if you are efficient. Similary, brute forcing IDEA is 2^128 = 340282366920938463463374607431768211456 = 3.4 10^38 The best factoring algorithm (gopher plug: check in Misc/ for a recent "bits and difficulty factoring post") for a 1024 bit key is a complexity of 4.42 10^29. Somewhere around 1600 bits comes a point where it is "easier" to attack IDEA than factor the resulting number. Karl Barrus <klbarrus(a)owlnet.rice.edu> -----BEGIN PGP SIGNATURE----- Version: 2.3a iQCVAgUBLNKNqYOA7OpLWtYzAQFlkwP+PdenJNJOKm9zcxkL4Zaq22aujfa2SAgk 1NILjQzZI8uZe9FIn8p2uEoS3YjYskg40tEMeohhGqZ371s/ndlTjDDhga0PCXLj Q4UHoowTVR9hx/cVGzLhuZbyAwbbqAvygGQNKN1iXn3IqpLoNV3Do+TtUj0xLt1l 0j1gl055YL4= =Vl2r -----END PGP SIGNATURE-----

1 0

thanks...
by jdblair＠nextsrv.cas.muohio.EDU 17 Dec '03

17 Dec '03

Thanks to all of the people who answered my question on message signing. -john.

1 0

Macintosh PGP CDEV Idea
by jdblair＠nextsrv.cas.muohio.EDU 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- I have a proposal for a piece of code I'd like to try and put togethor over Xmas break, and I want to bounce it off of the group to make sure that I'm not duplicating anyone else's work. I work mostly on the Macintosh, and this program would be for the mac. It would be a CDEV (good 'ol desk accessory) which would contain a smaller version of PGP. By smaller, I don't mean less secure, I mean a little less functionality. All it would do would sign, encrypt, or decrypt text files. By being a desk accessory, it would allow a message that's been downloaded by whatever means (MS Mail, FTP, Kermit, etc.) to be quickly decrypted, or to encrypt files for uploading. The idea is to have a simple, easy graphical interface on a small floating pallete type window. Since it would be a CDEV, it could be used simultaneously with a communications program even if the machine was running 6.0 w/ the unary finder. Keys would still be generated in the full fledged version, but these keys would be accessible by the CDEV. A possible later version could also take advantage of Apple Events, thus becoming a module which other programs could send files to to become decrypted, or encrypted without worrying about the process themselves. I've begun poreing through the source code to see how easy or difficult this is going to be, but first I'd like to make sure that their aren't already projects like this in development, or if there is any body who would like to help with the development process. It must be made clear that I am a beginning C programmer and a beginning developer of hard-coded Macintosh applications. I've started to consider tackling this project as something that will force me to learn both. Anybody have any ideas, comments, proposals? E-mail me directly, unless you think its a discussion that should be posted to the group as a whole. later, - -john. -----BEGIN PGP SIGNATURE----- Version: 2.3 iQBVAgUBLNJm3qNqtARNqVmxAQGL2wH/dYM7nkpeNbrFniRseZUHEl0X1p4Cn5md iqPkZWhznhwa+QhcEm6s8RGSq/Kf/uEPsy1C58wVfFbwhMF23WfPhQ== =car+ -----END PGP SIGNATURE-----

1 0