December 2003 - cypherpunks-legacy

Re: Hardware-random-bits interface
by tcmay＠got.net 17 Dec '03

17 Dec '03

At 3:17 PM 11/15/95, David K. Merriman wrote: >At 02:31 PM 11/14/95 -0800, you wrote: >>I've been thinking about physically random bits recently, so >>I'd like to offer a simple, easily implementable interface to a >>source of such bits, along with a design sketch using a common >>radio receiver chip as the noise source. > >It sounds like a fairly decent idea, _as long as you shield the bejeebers >(technical term :-) out of it_. Otherwise, anybody with a signal generator >could skew your numbers however they saw fit: any component lead can act as >an antenna, no matter now small that lead is. But if you "shield the bejeebers out of it," then all the radio receiver generates is whatever signal manages to sneak through--which, ironically, would make it _easier_ for an outside attacker to drive--and some amount of internal receiver/amplifier noise, such as the Johnson noise talked about here. (Every receiver has an "equivalent noise temperature," recall.) And if one is left with only internal noise, why not simply use a nice clean source like a Zener diode? --Tim May Views here are not the views of my Internet Service Provider or Government. ---------:---------:---------:---------:---------:---------:---------:---- Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay(a)got.net 408-728-0152 | anonymous networks, digital pseudonyms, zero Corralitos, CA | knowledge, reputations, information markets, Higher Power: 2^756839 | black markets, collapse of governments. "National borders are just speed bumps on the information superhighway."

3 2

encryption in BeOS kernel
by cpunk＠remail.ecafe.org 17 Dec '03

17 Dec '03

This also corresponds to IBM's development of its "IPC" "network appliance" (also due out 1Q '96) to challenge the desktop PC for Internet use. It parallels as well IBM's reported work on a "Microkernal" which may feature encryption, authentication and security hooks. IBM's IPC will probably use an Intel chip (WSJ today). Which leads to speculation: Would chip-fabbers covertly Fortezza chips to get export ok? Motorola, HP, IBM, others long-linked to USG are ever ready to gobble international market share in the national interest. Intel, sure, world-class fab plants planting chip-secrets. Wonder if that key escrow protest to Gore is a cover for economic actions authorized by National Security D&D?

1 0

Re: Q: Bookshop in Seattle
by blancw＠accessone.com 17 Dec '03

17 Dec '03

Can someone point me towards a bookshop in Seattle that is likely to have the second edition of Applied Cyptography ? ....................................... Tower Books (I've seen it advertised there) The University BookStore (probably) Barnes & Noble (potentially) .. Blanc

2 1

4096 bit strong prime for Diffle-Hellman
by Eric Young 17 Dec '03

17 Dec '03

A bit of a ramble about Diffle-Hellman parameters..... Just for anyone interested, I 'found' a suspected 4096 strong prime (p and (p-1)/2 are prime) for use with Diffie-Hellman, generator of 2. If any-one wants for testing the primality, please let me know if it passes. I'm currently using the Miller-Rabin primality test with my own bignum library. I'm just generating some 'default' DH parameter sets for distribution with the next version of my crypto library (SSLeay), I'll send out Phil Karn's 1024 and 2048 bit values and this one if other people are happy with it. Some quick times (in seconds) for the use of a 4096 bit prime with DH on a SGI (200mhz R4400). The RSA operation is PKCS#1 private key encrypt, the DH operation is a PKCS#3 public/private key generation followed by the generation of session key, the maths routines are from SSLeay. modulus DH RSA 512 0.23 0.041 1024 1.71 0.248 2048 12.88 1.702 4096 102.18 13.150 The RSA times as you will notice are about the same speed for twice the DH bit size. This is due to the RSA operation being reduced to 2 a^b%m operation where m has the values of p and q where (p-1)*(q-1) is the RSA modulus, half the bit size. The DH operation is 2 a^b%m operations, (generating the 'public key' and then raising by the peer's public key). Does any-one know of any tricks to speeding the DH operation up (not counting implementing a better a^b%m function, I'm going to do this later when I have time :-). From what I can see, there is not much that can be done except perhaps some tricks in the initial g^rand%p, since the generator is a known value. Even if the private DH values are pre-calculated, this will only halve the time of the DH operation and if this is done it looses the advantage of DH in that if the private/public pair are 'generated on the fly', pre-recorded session will not be able to be decoded if the private key is revealed at a later point in time. This is the major advantage I can see of a DH key exchange over the use of an RSA based system so I would object to loosing this feature. With these times I think that 4096 bit DH is not going to be used for quite a while :-). eric The suspected 4096 bit strong prime. In C, first byte is most significate (big endian) unsigned char dh4096_p={ 0xFE,0xEA,0xD1,0x9D,0xBE,0xAF,0x90,0xF6,0x1C,0xFC,0xA1,0x06, 0x5D,0x69,0xDB,0x08,0x83,0x9A,0x2A,0x2B,0x6A,0xEF,0x24,0x88, 0xAB,0xD7,0x53,0x1F,0xBB,0x3E,0x46,0x2E,0x7D,0xCE,0xCE,0xFB, 0xCE,0xDC,0xBB,0xBD,0xF5,0x65,0x49,0xEE,0x95,0x15,0x30,0x56, 0x81,0x88,0xC3,0xD9,0x72,0x94,0x16,0x6B,0x6A,0xAB,0xA0,0xAA, 0x5C,0xC8,0x55,0x5F,0x91,0x25,0x50,0x3A,0x18,0x0E,0x90,0x32, 0x4C,0x7F,0x39,0xC6,0xA3,0x45,0x2F,0x31,0x42,0xEE,0x72,0xAB, 0x7D,0xFF,0xC7,0x4C,0x52,0x8D,0xB6,0xDA,0x76,0xD9,0xC6,0x44, 0xF5,0x5D,0x08,0x3E,0x9C,0xDE,0x74,0xF7,0xE7,0x42,0x41,0x3B, 0x69,0x47,0x66,0x17,0xD2,0x67,0x0F,0x2B,0xF6,0xD5,0x9F,0xFC, 0xD7,0xC3,0xBD,0xDE,0xED,0x41,0xE2,0xBD,0x2C,0xCD,0xD9,0xE6, 0x12,0xF1,0x05,0x6C,0xAB,0x88,0xC4,0x41,0xD7,0xF9,0xBA,0x74, 0x65,0x1E,0xD1,0xA8,0x4D,0x40,0x7A,0x27,0xD7,0x18,0x95,0xF7, 0x77,0xAB,0x6C,0x77,0x63,0xCC,0x00,0xE6,0xF1,0xC3,0x0B,0x2F, 0xE7,0x94,0x46,0x92,0x7E,0x74,0xBC,0x73,0xB8,0x43,0x1B,0x53, 0x01,0x1A,0xF5,0xAD,0x15,0x15,0xE6,0x3D,0xC1,0xDE,0x83,0xCC, 0x80,0x2E,0xCE,0x7D,0xFC,0x71,0xFB,0xDF,0x17,0x9F,0x8E,0x41, 0xD7,0xF1,0xB4,0x3E,0xBA,0x75,0xD5,0xA9,0xC3,0xB1,0x1D,0x4F, 0x1B,0x0B,0x5A,0x09,0x88,0xA9,0xAA,0xCB,0xCC,0xC1,0x05,0x12, 0x26,0xDC,0x84,0x10,0xE4,0x16,0x93,0xEC,0x85,0x91,0xE3,0x1E, 0xE2,0xF5,0xAF,0xDF,0xAE,0xDE,0x12,0x2D,0x12,0x77,0xFC,0x27, 0x0B,0xE4,0xD2,0x5C,0x11,0x37,0xA5,0x8B,0xE9,0x61,0xEA,0xC9, 0xF2,0x7D,0x4C,0x71,0xE2,0x39,0x19,0x04,0xDD,0x6A,0xB2,0x7B, 0xEC,0xE5,0xBD,0x6C,0x64,0xC7,0x9B,0x14,0x6C,0x2D,0x20,0x8C, 0xD6,0x3A,0x4B,0x74,0xF8,0xDA,0xE6,0x38,0xDB,0xE2,0xC8,0x80, 0x6B,0xA1,0x07,0x73,0x8A,0x8D,0xF5,0xCF,0xE2,0x14,0xA4,0xB7, 0x3D,0x03,0xC9,0x12,0x75,0xFB,0xA5,0x72,0x81,0x46,0xCE,0x5F, 0xEC,0x01,0x77,0x5B,0x74,0x48,0x1A,0xDF,0x86,0xF4,0x85,0x4D, 0x65,0xF5,0xDA,0x4B,0xB6,0x7F,0x88,0x2A,0x60,0xCE,0x0B,0xCA, 0x0A,0xCD,0x15,0x7A,0xA3,0x77,0xF1,0x0B,0x09,0x1A,0xD0,0xB5, 0x68,0x89,0x30,0x39,0xEC,0xA3,0x3C,0xDC,0xB6,0x1B,0xA8,0xC9, 0xE3,0x2A,0x87,0xA2,0xF5,0xD8,0xB7,0xFD,0x26,0x73,0x4D,0x2F, 0x09,0x67,0x92,0x35,0x2D,0x70,0xAD,0xE9,0xF4,0xA5,0x1D,0x84, 0x88,0xBC,0x57,0xD3,0x2A,0x63,0x8E,0x0B,0x14,0xD6,0x69,0x3F, 0x67,0x76,0xFF,0xFB,0x35,0x5F,0xED,0xF6,0x52,0x20,0x1F,0xA7, 0x0C,0xB8,0xDB,0x34,0xFB,0x54,0x94,0x90,0x95,0x1A,0x70,0x1E, 0x04,0xAD,0x49,0xD6,0x71,0xB7,0x4D,0x08,0x9C,0xAA,0x8C,0x0E, 0x5E,0x83,0x3A,0x21,0x29,0x1D,0x69,0x78,0xF9,0x18,0xF2,0x5D, 0x5C,0x76,0x9B,0xDB,0xE4,0xBB,0x72,0xA8,0x4A,0x1A,0xFE,0x6A, 0x0B,0xBA,0xD1,0x8D,0x3E,0xAC,0xC7,0xB4,0x54,0xAF,0x40,0x8D, 0x4F,0x1C,0xCB,0x23,0xB9,0xAE,0x57,0x6F,0xDA,0xE2,0xD1,0xA6, 0x8F,0x43,0xD2,0x75,0x74,0x1D,0xB1,0x9E,0xED,0xC3,0xB8,0x1B, 0x5E,0x56,0x96,0x4F,0x5F,0x8C,0x33,0x63, }; unsigned char dh4096_g={ 0x02, }; Or as a ASN.1 encoded pkcs#3 object. -----BEGIN DH PARAMETERS----- MIICCAKCAgEA/urRnb6vkPYc/KEGXWnbCIOaKitq7ySIq9dTH7s+Ri59zs77zty7 vfVlSe6VFTBWgYjD2XKUFmtqq6CqXMhVX5ElUDoYDpAyTH85xqNFLzFC7nKrff/H TFKNttp22cZE9V0IPpzedPfnQkE7aUdmF9JnDyv21Z/818O93u1B4r0szdnmEvEF bKuIxEHX+bp0ZR7RqE1AeifXGJX3d6tsd2PMAObxwwsv55RGkn50vHO4QxtTARr1 rRUV5j3B3oPMgC7Offxx+98Xn45B1/G0Prp11anDsR1PGwtaCYipqsvMwQUSJtyE EOQWk+yFkeMe4vWv367eEi0Sd/wnC+TSXBE3pYvpYerJ8n1MceI5GQTdarJ77OW9 bGTHmxRsLSCM1jpLdPja5jjb4siAa6EHc4qN9c/iFKS3PQPJEnX7pXKBRs5f7AF3 W3RIGt+G9IVNZfXaS7Z/iCpgzgvKCs0VeqN38QsJGtC1aIkwOeyjPNy2G6jJ4yqH ovXYt/0mc00vCWeSNS1wren0pR2EiLxX0ypjjgsU1mk/Z3b/+zVf7fZSIB+nDLjb NPtUlJCVGnAeBK1J1nG3TQicqowOXoM6ISkdaXj5GPJdXHab2+S7cqhKGv5qC7rR jT6sx7RUr0CNTxzLI7muV2/a4tGmj0PSdXQdsZ7tw7gbXlaWT1+MM2MCAQI= -----END DH PARAMETERS----- eric -- Eric Young | Signature removed since it was generating AARNet: eay(a)mincom.oz.au | more followups than the message contents :-)

2 3

Re: Repeated Words/characters in Password/Phrase
by tcmay＠got.net 17 Dec '03

17 Dec '03

At 11:11 PM 11/14/95, Ted Cabeen wrote: >Do repeated words in a PGP passphrase make the pass phrase less secure than >a passphrase without any repeated words? And on the same note, do repeated >letters in a UNIX password make that password easier to break? I can't seem >to find anything in my books on cryptography that mention this. Thanks. More of an information theory question than a crypto question. There are no simple answers to this question, but some examples will help: The password "foo" is not very good, and "foofoo" is only slightly better. And "foofoofoo" is slightly better, and so on, to a point. But "foofoo....foo" is not N times better than a single "foo," because the _pattern_ is simply desribed: "repeat "foo" N times." Thus, the information content or entropy of "foofoofoo....foo" is not N times greater than the entropy of "foo." A some dictionary attacks which would trivially find "foo" will not find "foofoo," or "foofoofoo," etc., so this could be a great help. More sophisticated dictionary attacks may of course take the 30,000 or so most common names, words, places, and then do various permutations, reversals, repetitions, etc. So this is why there is not likely to be a simple answer to your question. Repeating words in a passphrase can make the passphrase easier to remember (such as "thequickquickbrownfox") and make certain kinds of attacks harder, but with not as much of an increase in entropy at the increased number of raw characters might otherwise suggest. Other "heuristics" (simple rules of thumb) for passphrases are contained in the PGP documents, and in numerous other places: avoid names, add nonstandard English keyboard characters liberally (even if using real words), etc. The "best" passphrases, it almost goes without saying, are the longest and most "unpredictable," so that "7f#qp)djQ10hB%3t+1?U4SVp5" is much superior to "%foo%foo". In the real world, where passphrases must be memorized, "long and random" is an elusive goal, which has to be weighed against the risk of other attacks (such as capturing keystrokes with a sofware monitor, or from afar with a van Eyk antenna, etc.). Me, I use a nonsense phrase which has meaning to me, with a few garbage characters added to confuse things further. I don't think my passphrase is the weak link. --Tim May Views here are not the views of my Internet Service Provider or Government. ---------:---------:---------:---------:---------:---------:---------:---- Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay(a)got.net 408-728-0152 | anonymous networks, digital pseudonyms, zero Corralitos, CA | knowledge, reputations, information markets, Higher Power: 2^756839 | black markets, collapse of governments. "National borders are just speed bumps on the information superhighway."

2 1

Re: MED_vac
by Thomas M. Swiss 17 Dec '03

17 Dec '03

John Young <jya(a)pipeline.com> writes: > > 11-15-95. NYPaper Page One: > > "When Patients' Records Are Commodities for Sale." > > Individual medical records, carrying more sensitive > personal information than ever before, are increasingly > being gathered and stored by the tens of thousands in > commercial databanks maintained by institutions like > hospital networks, health maintenance organizations and > drug companies. And although there is a Federal law that > protects the privacy of video rental lists, private > medical information is being bought and sold freely. A (possibly stupid) thought: could commercial key escrow help here? I very much want hospitals to have fast access to my medical data if my broken and bleeding body should come through their door, even if I am unconscious and my personal physician cannot be reached. On the other hand, I don't want anyone to be snooping through them right now. One solution is for me to carry my records around with me on a smartcard or some such device. But there are problem with that approach; for example, do I want that personal information to be in my wallet if it's stolen? Do I want to add another item to the list of physical items I have to keep secure? So, what if my records were available on the net, but encrypted with a an key known to my physician and an escrow agency? (Equivalently, they could be on that smartcard, but encrypted.) If an emergency occurs, the hospital fetches my encrypted records from my physician's server, then sends a message (signed with the hospital's key) to Keys R Us, the escrow agent, saying "This is Dr. McCoy at Frobnitz Memorial Hospital, we need the key for FooBar Medix, Inc., patient number 147258369." (My FooBar Medix, Inc., insurance card lists my physician's server, the escrow agency, and my patient number.) Keys R Us verifies the message and sends the key. Perhaps there's also an alias to notify of the release, one that reports to but is not traceable to my physician or me. Keys R Us only has a number and a key; they don't know who my physician is and therefore don't know where to find the actual records. Anyone who gets my insurance card can find the records, but has to convince Keys R Us to release they key; and if I've done my homework in picking the agency, they won't. Does this give an advantage over just having a copy of my records kept by a trusted third party? Maybe so; I think maybe less trust of the escrow agency is necessary. No snooper can slip someone at the escrow agency a couple of cyberbucks to get a copy of my records, unless they've managed to match "FooBar Medix, Inc. patient number 147258369" with "Tom Swiss" and the location of my physician's server. (What if FooBar Medix, Inc., lets this information out? I dunno. I guess I visit their office with a shotgun. Better idea: FMI doesn't know what escrow agency I use. I fill in Keys R Us on the card myself.) No minimum wage slave can just casually browse my records for fun. Thoughts? [Since TIS is in the CKE field, I should note that this is my own boneheaded idea, not affiliated with the company in any way.] -Tom Swiss / tms(a)tis.com

3 3

Secrets of the Internet
by James M. Cobb 17 Dec '03

17 Dec '03

Friend, 11 21 95 Times of London screams that Pedophiles use encoding devices to make secret use of Internet Its newsstory reports an Interpol conference was told that International pedophile rings are borrowing an encryption system known as PGP -- Pretty Good Privacy -- developed in [where else!] America and Experts estimate that it could take 10 years for computer systems to crack the individual codes. If that's not enough to reduce you to jelly, Police [are] also concerned at the use of a "remailing" service being provided by an Internet expert in Finland who will take material sent to him and remove identifica- tion marks before sending it out again. On Monday, at the start of the two-day conference in Lon- don on crime against children, Detective Chief Inspector Bryan Drew of the UK's National National Criminal Intelli- gence Service said ...although police increasingly realised the difficulties posed by the Internet...as yet no one in Britain had de- cided on a policy for dealing with them. and ...the Internet and computers were among a number [of] subjects being looked at by his unit. Interim measures for "dealing with" computers and the 'Net abound: As part of the Interpol work, a network of 64 liaison offi- cers had been set up round the world to keep contact on investigations. And when the State ("no one") DECIDES...? Cordially, Jim NOTE. The NandO News website URL is: http;//www.nando.net The newsstory's dateline is: LONDON (Nov 21, 1995 - 01:24 EST) Its online filename is: info429_4.html

2 1

Applied Cryptography case filings on the Web
by Phil Karn 17 Dec '03

17 Dec '03

The government has filed its Motion to Dismiss, or In The Alternative, For Summary Judgment in the case of Karn vs State Dept. This case challenges the arbitrary Commodity Jurisdiction Request rulings made for the book Applied Cryptography and for a floppy disk containing the same source code printed in the book. I've begun scanning in and HTMLizing the various government documents, some of which are sizeable. As I finish them I'm putting them up on my web page. Please feel free to pass around this URL: http://www.qualcomm.com/people/pkarn/export/index.html --Phil

1 0

PKZIP - Encryption
by L. DEkel 17 Dec '03

17 Dec '03

PKZIP Encryption - Practical approach ===================================== Note: I am discussing PKZIP ver. 2.xx encryption, but the abstracts isn't about a particular encryption. ABSTRACT: Practical security often differs from Theoretical security. If I asked you, would you make the effort of renting a box at the bank's safe for putting only $1 inside, then when you want it you'll have to drive to town, at opening hours, and be escorted by an armed guard to the safe, just to get the $1, I can guess what your answer will be. The same thing goes for Cryptography, What you are trying to protect, it's importance, price, value, determines the steps you would be wiling to take to ensure a safe and strong encryption. If you want to hide a game from your kid brother, you can use some basic algorithm of encryption (say XOR), but say want to hide proofs that you killed someone you better use a stronger algorithm (say IDEA). To conclude: The system you should choose for security depends on: 1. How sensitive is the data you want to hide. 2. Who is the potential cracker of your system. 3. How convenient is the Crypto system for use. (*) (*) This is not so trivial, as security = 1/convenience, you can, for example force users to change their passwords every 2 min. very secure, but that not very Practical. PKZIP Encryption: PKZIP encryption is often said to be: Weak, "a joke" ,"a deception" etc. Maybe it's time to put things in the right perspective. One must realize (yet again) the difference between: Theoretical Cryptography - and - Practical Cryptography: >From the Theoretical side, there is an excellent article: "A Known Plaintext Attack on the PKZIP Stream Cipher", by Eli Biham and Paul C. Kocher., that proposes an attack on the algorithm using known plaintext method. The writers come to the conclusion that: "The PKZIP cipher is weak, and should not be used to protect valuable data". Criticism: 0). Only the you can define what is "valuable data" for yourself, this could be an abstract question. [see above ABSTRACT discussion] 1). The proposed attack is largely Theoretical, in "laboratory conditions", whereas a ciphertext-only attack, more like what we often find in the real world, is Harder. The article doesn't propose any effective ciphertext-only attack. (It seems the writers only tried to give a general assessment of the algorithm strength, which they did very well). Note: A Very limited Known-plaintext attack is possible against PKZIP, as specific information about the Header of the archive file is Known, but this attack is of complexity 2^38 or higher, so it's not very effective, however it is a possible for an expert Cryptanalyst. (This is still Easier than ciphertext-only attack - we meet in the street). Thus, the theoretical attack is good in telling us about the encryption algorithm, it's strength and weaknesses, and knowledge is always better then ignorance, But, in real world, such an attack can be rendered ineffective, or impractical in terms of resources consumed, time spent, money etc. Don't get the wrong impression, in general, Cryptographic research is Good, it helps determine the overall strength of an algorithm, make suggestions as to possible improvements, warn against weak keys, back-doors etc. But we must separate the Practical from the Theoretical, and it works both ways too. A one-time-pad (OTP) for example, is considered theoretically unbreakable, but in practice OTP systems has been broken more than once, as long as there are people making Human mistakes: loosing secret keys, encryption a message with the OTP more than once, etc. So: Theoretical encryption strength != Practical encryption Strength 2). Considering the "many" cracking utilities in the market: there is almost NO ready made, software that really crack the PKZIP algorithm (crack = cryptanalysis, that is Really analyzing the algorithm, not guessing games), in fact there is No software that can really crack Any modern algorithm such as DES, IDEA etc, That is except maybe CBW which is the closest thing to Really cracking the crypt(1) for unix, or some commercial products for cracking WordPerfect encryption or so. (The strength of PKZIP 1.xx/2.xx encryption is much greater than the above crypt(1) and WordPerfect). All the "Great" utilities are just fancy passwords guessers at best, none of them analyze the ciphertext. True, some of them are good guessers, but their "strength" depends on the Weakness of the password (password = The cryptographic Key). The stronger the password the less chance the "cracker-util" will crack it. The best crackers in the market performs a "limited" brute force attack, if they are good. "limited" is referred to "dictionary attacks", such as the cracker doesn't perform a complete Keyspace (brute-force) search, instead it perform a "Subset keysapce search", i.e. choosing some elements of the Keysapce (say english words) and trying them. (There is the option, in some crackers, including crackers for PKZIP, such as FZC, to perform a more "orderd" Keyspace, that is checking sequences of Keys, e.g: All-5-uppercase letters only- keys). The conclusion from this section is, that if you choose a Long enough, Hard to find (say random chars) password such as "x@J60!fv_Zd4%", then you are quite safe from these "horrid" crackers. That last statement is good for choosing passwords in general. Final note: PKZIP is not a crypto system it's an Archiver with a password protection option. If You want to protect your secret cherry cake recipe from your mother, you can safely use PKZIP protection (assuming your mother isn't a top cryptographer working for NSA). If you want to hide the formula for Cold fusion - use PGP. And remember, there is always the "rubber hose" cryptography option. ,,,,, DEkel '''''

2 1

Re: Get your own ITAR
by droelke＠spirit.aud.alcatel.com 17 Dec '03

17 Dec '03

I just called this number and was given the following instructions: Fax your request to (703)875-6647 Attn Donna Davis, include your name and address. Allow 10-15 days for US mail or include your Fed-Ex account number for faster service. Enjoy, Dan > > 1 703 875 6644. > The kindly administrative assistant there will take your name and address > and send you a hardcopy of the ITAR regulations. I don't know about > overseas mailings. I also imagine you will have to wait until the current > US budget stale-mate is resolved. (Thanks to digest-reader walt(a)osf.org > for the phone number.) > /r$ > ------------------------------------------------------------------ Dan Oelke Alcatel Network Systems droelke(a)aud.alcatel.com Richardson, TX

1 0