Re: [Cryptography] Why is emailing me my password?
On Tue, Oct 01, 2013 at 10:28:48AM -0400, Greg wrote: So, my password, iPoopInYourHat, is being sent to me in the clear by your servers. All mailman lists do this by default. It does tell you on the sign up page that it will do so, and that you shouldn't use a 'valuable' (e.g. used elsewhere) password - see http://www.metzdowd.com/mailman/listinfo/cryptography It is an annoying default, but so long as you don't use a password attached to anything else you care about, I don't think it should be too much of a worry. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Crypto being blamed in the London riots.
Quoting from the New York Times: David Lammy, Britain's intellectual property minister, also called for a suspension of Blackberry's encrypted instant message service. Many rioters, exploiting that service, had been able to organize mobs and outrun the police, who were ill-equipped to monitor it. IIRC this came up last year when a Middle Eastern country (I forget which) were threatening to not let RIM operate unless they could intercept blackberry messages. However, as was pointed out then, apparently the encryption is to from RIM's servers, not the recipient. So RIM have access to all the 'secret' messages. I expect GCHQ the Met will make sure said systems are patched in to their surveillance programme in no time. Unfortunately the present climate in England is such that I can't imagine such measures being anything but lauded. pgp802VCPEo9M.pgp Description: PGP signature ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Passwords jump-started Fumo probe
http://www.philly.com/mld/inquirer/news/local/states/pennsylvania/counties/philadelphia_county/philadelphia/15727557.htm The feds were unable to break the encrypted email files until one admin came up with a password list on a portable drive. I wonder if they tried to brute-force the password? nick -- Nick Owen WiKID Systems, Inc. 404.962.8983 http://www.wikidsystems.com Commercial/Open Source Two-Factor Authentication https://www.linkedin.com/in/nickowen - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: NSA knows who you've called.
Perry E. Metzger wrote: [EMAIL PROTECTED] writes: While I agree with you, the public does not, so far as I can tell, find itself willing to risk insecurity for the benefit of preserving privacy, as this article in today's Boston Globe would tend to confirm. I'm sure. On the other hand, I think it is our place, as security professionals, to explain why the tradeoff is a false one. Respect for individual rights is not something we do in good times because it is a luxury we can afford when there is stability. It is something we need most in bad times, because it is what keeps us safe and maintains stability itself. Or to teach pollsters to ask the correct questions. Take this survey: http://www.washingtonpost.com/wp-srv/politics/polls/postpoll_nsa_051206.htm What it this question from the poll: It's been reported that the National Security Agency has been collecting the phone call records of tens of millions of Americans. It then analyzes calling patterns in an effort to identify possible terrorism suspects, without listening to or recording the conversations. Would you consider this an acceptable or unacceptable way for the federal government to investigate terrorism? Do you feel that way strongly or somewhat? Was instead: The NSA has been collecting the phone call records of tens of millions of Americans possibly in violation of the law. Would you consider it acceptable for the government to break the law to investigate terrorism? Nick -- Nick Owen WiKID Systems, Inc. 404.962.8983 http://www.wikidsystems.com Commercial/Open Source Two-Factor Authentication https://www.linkedin.com/in/nickowen - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: HTTPS mutual authentication alpha release - please test
James A. Donald wrote: -- It seems to me that mutual authentication is pretty much irrelevant to HTTPS and certificates. You mutually authenticate by both knowing the password, as in SPEKE. Of course, SPEKE is patented, so is this scheme a way of getting around the patents? We're not that smart - well, perhaps I should speak only for myself. We originally developed WiKID to target corporate VPNs with the WiKID client running on a wireless device (the Wi in WiKID) with no thought of mutual authentication because phishing was only getting under way. Only after we added the client support for Windows, Mac linux and phishers started getting really active did we think about adding MA. --digsig James A. Donald 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG a5RzA9UesxiZw+cjRsz+8yPLKwJdTMfUjcQq0iZf 4ybo9wAzZZNG5YyF69jzKw/oXw3fL7FGj86oXey46 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED] -- Nick Owen WiKID Systems, Inc. 404.962.8983 (desk) 404.542.9453 (cell) http://www.wikidsystems.com At last, two-factor authentication, without the hassle factor Now open source: http://sourceforge.net/projects/wikid-twofactor/ - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: HTTPS mutual authentication alpha release - please test
cyphrpunk wrote: On 11/3/05, Nick Owen [EMAIL PROTECTED] wrote: The token client pulls down a hash of the certificate from the WiKID server. It pulls the certificate from the website and performs a hash on it. It compares the two hashes and if they match, presents the user with the OTP and the message: This URL has been validated. It is now safe to proceed. Let me see if I understand the attack this defends against. The user wants to access https://www.citibank.com. The phisher uses DNS poisoning to redirect this request away from the actual citibank machine to a machine he controls which puts up a bogus citibank page. To deal with the SSL, the phisher has also managed to acquire a fake citibank certificate from a trusted CA(!). He fooled or suborned the CA into granting him a cert on citibank.com even though the phisher has no connections with citibank. He can now use this bogus cert to fool the client when it sets up the SSL connection to citibank.com. Is this it? This is what your service will defend against, by remembering the hash of the true citibank certificate? No, this is not it. It is this attack and similar: http://tinyurl.com/a3b89 The phishers are not using valid certificates, but users are so immune to warnings about certificates that they don't pay attention to them. It may be a DNS cache poison or the typical email; it could be any mechanism to send the user to a fraudulent site. What is being provided is a mechanism to route the users to the correct site by providing a way to validate the certificate for them. nick -- Nick Owen WiKID Systems, Inc. 404.962.8983 (desk) 404.542.9453 (cell) http://www.wikidsystems.com At last, two-factor authentication, without the hassle factor Now open source: http://sourceforge.net/projects/wikid-twofactor/ - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: HTTPS mutual authentication alpha release - please test
cyphrpunk wrote: On 10/31/05, Nick Owen [EMAIL PROTECTED] wrote: The system works this way: Each WiKID domain now can include a 'registered URL' field and a hash that website's SSL certificate. When a user wants to log onto a secure web site, they start the WiKID token and enter their PIN. The PIN is encrypted and sent to the WiKID server along with a one-time use AES key and the registered URL. The server responds with a hash of the website's SSL certificate. The token client fetches the SSL certificate of the website and compares it the hash. If the hashes don't match, the user gets an error. If they match, the user is presented with registered URL and the passcode. On supported systems, the token client will launch the default browser to the registered URL. What threat is this supposed to defend against? Is it phishing? I don't see how it will help, if the bogus site has a valid certificate. Yes, phishing. The token client isn't checking to see if the cert is valid, it's only checking to see if it's the same as the one that is on the WiKID authentication server. The cert doesn't have to be valid or have the root CA in the browser. Most one-time-password systems suffer from man-in-the-middle attacks primarily due to difficulties users have with validating SSL certificates. The goal of this release is to validate certificates for the end user, providing an SSH-esque security for web-enabled applications such as online banking. What does it mean to validate a certificate? Aren't certs self-validating, based on the key of the issuer? Again, what is this protecting against? Bad choice of words on my part - validate is a loaded word vis-a-vis certs. The token client pulls down a hash of the certificate from the WiKID server. It pulls the certificate from the website and performs a hash on it. It compares the two hashes and if they match, presents the user with the OTP and the message: This URL has been validated. It is now safe to proceed. Does that clarify? CP -- Nick Owen WiKID Systems, Inc. 404.962.8983 (desk) 404.542.9453 (cell) http://www.wikidsystems.com At last, two-factor authentication, without the hassle factor Now open source: http://sourceforge.net/projects/wikid-twofactor/ - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: HTTPS mutual authentication alpha release - please test
What threat is this supposed to defend against? Is it phishing? I don't see how it will help, if the bogus site has a valid certificate. Yes, phishing. The token client isn't checking to see if the cert is valid, it's only checking to see if it's the same as the one that is on the WiKID authentication server. The cert doesn't have to be valid or have the root CA in the browser. But this would only help in the case that an old URL is used and a new certificate appears, right? That's what would be necessary to get a match in your database, pull down an old certificate, and find that it doesn't match the new certificate. The token client has the true URL as well, so the traditional phish of sending users to the wrong site shouldn't work either. The user would have to ignore the launched browser and use the fake site. Phishers don't do this. They don't send people to legitimate URLs while somehow contriving to substitute their own bogus certificates. They send people to wrong URLs that may have perfectly valid certificates issued for them. I don't see how your system defends against what phishers actually do. They do this too by attacking DNS servers with cache poisoning. In this case the token client will not be able to validate the certificate. nick -- Nick Owen WiKID Systems, Inc. 404.962.8983 (desk) 404.542.9453 (cell) http://www.wikidsystems.com At last, two-factor authentication, without the hassle factor Now open source: http://sourceforge.net/projects/wikid-twofactor/ - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: US Banks: Training the next generation of phishing victims
Peter Gutmann wrote: Can anyone who knows Javascript better than I do figure out what the mess of script on those pages is doing? It looks like it's taking the username and password and posting it to an HTTPS URL, but it's rather spaghetti-ish code so it's a bit hard to follow what's going where. Why have the log on your homepage at all? Why not just a link to the https login??? If the goal is to not have SSL overhead on the homepage, don't. Or is there some extra overhead for login processing that I don't know about? Is there some user dissatisfaction with an extra click to login? I suppose if you really wanted non-SSL logins, you could use a one-time passcodes system with variable length passcodes to prevent race attacks. -- Nick Owen WiKID Systems, Inc. 404.962.8983 (desk) 404.542.9453 (cell) http://www.wikidsystems.com At last, two-factor authentication, without the hassle factor - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
update: GPL'd two-factor system
Greetings: Here is a brief update on the open source version of the WiKID Strong Authentication System: * New PHP network client released * SugarCRM network client released (based on PHP network client) * Citrix Web Interface network client released * Java token client binary released * Minor code fixes and clean up on the server * Added the WiKID white paper to the downloads section All this and more available for download on sf.net: http://sourceforge.net/projects/wikid-twofactor/ The project home page is http://www.wikidsystems.net/, which includes a poll on what applications people would like to see WiKID-enabled. Work is progressing on C and Python network clients to add to the Java and COM objects and those listed above. Our focus is on adding network clients in new languages and implementing those into applications. Regards, Nick -- Nick Owen WiKID Systems, Inc. 404.962.8983 (desk) 404.542.9453 (cell) http://www.wikidsystems.com At last, two-factor authentication, without the hassle factor - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: ECC patents?
James A. Donald wrote: -- Whyte, William: It hints that only some particular curves have been licensed. It could be that NSA has decided not to buy a license for the other curves, or it could be that operations on those curves aren't patented. The presentation doesn't give enough information to establish which. If the NSA paid anything significant for any of the curves, we would be told. Therefore the NSA paid nothing or almost nothing, and therefore if the NSA licensed anything, it would have licensed everything. I doubt that the NSA paid any money whatsoever for this license, making it profoundly unimpressive as evidence that *any* curves have a plausible valid patent. If the NSA paid real money, the patent holders would be sticking it in our face as a price setting precedent. I had a recent discussion with a person in a government agency that indicated we would not be able to use them as a reference and that they would probably want an unlimited license - because there could be no reference to a number of users within the agency. They did say that they would get GSA pricing. I suspect that Certicom got GSA pricing for the deal as is, I assume, required by law. Nick -- Nick Owen WiKID Systems, Inc. 404.962.8983 (desk) 404.542.9453 (cell) http://www.wikidsystems.com https://sourceforge.net/projects/wikid-twofactor/ - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Another entry in the internet security hall of shame....
I would appreciate your thoughts on WiKID. We use asymmetric keys to encrypt PINs and one-time passcodes between a client and the server. The server talks to various network clients using protocols such as LDAP, Radius, or using our own SSL-tunneled wAuth protocol. We believe that replacing passwords is the right economic model to fund PK deployment widely to consumers. The client can then be extended to provide encryption for apps such as the credit card app described below. We have just released version of WiKID under the GPL. The GPL client uses RSA encryption. The non-GPL version uses Ntru, making it suitable for wireless clients (RSA key gen on a java cell phone is a bitch). We have set up http://www.wikidsystems.net as our open source home page and https://sourceforge.net/projects/wikid-twofactor/ is the sourceforge project page as well - which includes a white paper and documentation. Comments and contributions are much appreciated. tia, Nick Ian G wrote: Anne Lynn Wheeler wrote: the major ISPs are already starting to provide a lot of security software to their customers. a very straight forward one would be if they provided public key software ... to (generate if necessary) and register a public key in lieu of password ... and also support the PPP radius option of having digital signature authentication in lieu of password checking http://www.garlic.com/~lynn/subpubkey.html#radius Right. And do the primary authentication of the key using some other mechanism that is outside the strict crypto. (IOW, Dave, your plan will work, as long as it is built from ground up with no prior baggage! IMHO!) This is such a no-brainer that when I first came across the solution over a decade ago now, I never gave a thought as to how it could be anything but the one way to do things. It just works, and very little else works anywhere as well. Yet, we are still grubbing around like cavemen in the mud. And then there is this: http://www.business2.com/b2/web/articles/print/0,17925,1096807,00.html $5M Mobile ID for Credit Card Purchases WHO: John Occhipinti, Woodside Fund, Redwood Shores, Calif. WHO HE IS: A former executive at Oracle and Netscape, Occhipinti is a managing director and security specialist, leading investments in BorderWare and Tacit. WHAT HE WANTS: Fraudproof credit card authorization via cell phones and PDAs. WHY IT'S SMART: Credit card fraud is more rampant than ever, and consumers aren't the only ones feeling the pain. Last year banks and merchants lost more than $2 billion to fraud. Most of that could be eliminated if they offered two-part authentication with credit and debit purchases -- something akin to using a SecureID code as well as a password to access e-mail. Occhipinti thinks the cell phone, packaged with the right software, presents an ideal solution. Imagine getting a text message on your phone from a merchant, prompting you for a password or code to approve the $100 purchase you just made on your home PC or at the mall. It's an extra step, but one that most consumers would be happy to take to safeguard their privacy. More important, Occhipinti says, big banks would pay dearly to be able to offer the service. It's a killer app no one's touched yet, Occhipinti says, but the technology's within reach. WHAT HE WANTS FROM YOU: A finished prototype application within eight months. I'm looking for the best technologists in security and wireless, the top 2 percent in their industry, Occhipinti says. The team would need to be working with a handful of banks and merchants ready to start trials, in hopes of licensing the technology or selling the company. SEND YOUR PLAN TO: [EMAIL PROTECTED] The funniest part of all is that even though we know how to do it in our sleep, Paypal actually built one as their original offering and threw it away... at that point your public key is now registered with your ISP ... and possibly could be used for other things as well ... and scaffolding for a certificateless trust infrastructure. Yup. But this will only work if you go back to basics and build the structure naturally around the keys. IOW, not using anything from PKI. lots lots of past postings on SSL landscape http://www.garlic.com/~lynn/subpubkey.html#sslcert Watching security thinking advance is like watching primates evolve from close distance. Either we die of old age before anything happens, or we get clubbed to death... iang - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED] -- Nick Owen WiKID Systems, Inc. 404.962.8983 (desk) 404.542.9453 (cell) http://www.wikidsystems.com At last, two-factor authentication, without the hassle factor - The Cryptography Mailing List Unsubscribe by sending
Re: the limits of crypto and authentication
I think the failure of Amex Blue is due to poor timing and the requirement for hardware on the end-user's PC. At the time of it's introduction ecommerce and online banking were just getting started and consumers were more worried about whether the store was real or not than having their card stolen. It wasn't until identity theft and the rush of disclosures due to SB1386 et al here in the US that people cared about security and privacy (in some way). What I can't understand is why Visa and Amex haven't started to push their one-time credit card software solutions again - this time as protection for your privacy. I would think people would be much more receptive to it now. Little has changed, except the market's perception of the risk of using credit cards online. Amex actually pulled their program in 2004, IIRC. [EMAIL PROTECTED] wrote: Nick Owen writes: | I think that the cost of two-factor authentication will plummet in the | face of the volumes offered by e-banking. Would you or anyone here care to analyze what I am presuming is the market failure of Amex Blue in the sense of its chipcard and reader combo? --dan - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED] -- Nick Owen WiKID Systems, Inc. 404.962.8983 (desk) 404.542.9453 (cell) http://www.wikidsystems.com At last, two-factor authentication, without the hassle factor - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: the limits of crypto and authentication
I think the difference now is the number of vendors entering the market, the variety of solutions ( and their relative security), and demand outside of Europe. When we started in mid-2001, we were looking at the existing hardware guys and that is it. Now there a handful of venture-backed software players with different solutions all targeting the banking market, which didn't exist then. We have not seen any interest in our two-factor solution from Germany or any country where they have some form of two-factor authentication. Perhaps this is similar to the US corporate market where companies that have tokens aren't very interested in switching to save money - the CSO only takes risk in switching and sees no personal benefit in reducing costs (my theory at least) so there's no true vetting, only beating up the current vendor for a slightly better deal. Thus your banks will still complain that the price of mailing paper is too high, which of course it is when compared to software tokens. We are, however, seeing interest from US and South American banks and the numbers are huge and we will be very aggressive in pricing. We also see that we are competing against companies that use IP address verification, secure cookies and other things that are readily compromised, but apparently easy to roll-out and maintain and inexpensive. So, we have to compete against those substitutes that don't even use cryptography or two-factor authentication but would be better termed as fraud detection and prevention. Florian Weimer wrote: * Nick Owen: I think that the cost of two-factor authentication will plummet in the face of the volumes offered by e-banking. I doubt this is true. In Germany, we already use some form of two-factor authentication for Internet banking transaction (account number/password and a one-time password for each transaction). Yet banks are desperately looking for alternatives because distributing those one-time password lists is too expensive (!). To me, this was quite surprising because it's just one sheet of paper every 200 transactions or so. Even worse, this scheme has failed, and there are successful attacks in the wild (involving compromised client PCs). Right now, time-dependent tokens do help, but only because you outrun the other guy. The real-time requirements imposed by them are not a fundamental obstacle to the attackers, and even now, the way they route the money makes it very hard to detect things in real-time (at least on the money side). Well, you can imagine my surprise when Howard Schmidt praised two-factor authentication as a solution to our current problems at the FIRST 2005 conference. 8-/ - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED] -- Nick Owen WiKID Systems, Inc. 404.962.8983 (desk) 404.542.9453 (cell) http://www.wikidsystems.com At last, two-factor authentication, without the hassle factor - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: the limits of crypto and authentication
It would seem simple to thwart such a trojan with strong authentication simply by requiring a second one-time passcode to validate the transaction itself in addition to the session. Steven M. Bellovin wrote: There's been a lot of discussion about how to strengthen cryptography and authentication, to get away from problems of phishing, pharming, etc. But such approaches can take you only so far, as this link indicates: http://www.lurhq.com/grams.html Briefly, it's a Trojan that waits for you to log int o E-Gold, checks your balance, and drains your account except for .004 grams of gold. --Steven M. Bellovin, http://www.cs.columbia.edu/~smb - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED] -- Nick Owen WiKID Systems, Inc. 404.962.8983 (desk) 404.542.9453 (cell) http://www.wikidsystems.com At last, two-factor authentication, without the hassle factor - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: the limits of crypto and authentication
To validate the transaction, a receipt could be sent to the user encrypted by the server's public key. If the receipt is correct, the user enters their PIN to 'sign' the transaction. I'm assuming an asymmetric authentication system here outside the browser. The attacker would have to steal the user's private key, their PIN and the server's private key, correct? I know that if the PC is compromised anything is possible, but I think this raises the bar significantly - perhaps to an unprofitably level. Steven M. Bellovin wrote: In message [EMAIL PROTECTED], Nick Owen writes: It would seem simple to thwart such a trojan with strong authentication simply by requiring a second one-time passcode to validate the transaction itself in addition to the session. How does the user know which transaction is really being authenticated? (I alluded to this in a 1997 panel session talk; see http://www.cs.columbia.edu/~smb/talks/ncsc-97/index.htm ) --Steven M. Bellovin, http://www.cs.columbia.edu/~smb -- Nick Owen WiKID Systems, Inc. 404.962.8983 (desk) 404.542.9453 (cell) http://www.wikidsystems.com At last, two-factor authentication, without the hassle factor - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: the limits of crypto and authentication
I think that the cost of two-factor authentication will plummet in the face of the volumes offered by e-banking. Also, the more uses for the token, the more shared the costs will be. The question to me is will the FIs go with a anything beyond secure cookies, IP address validation and unique images. Will they be forced to by the powers that be or by disclosure requirements after the basic systems are thwarted? I also think that the lower end cell phone is now capable of handling the task. While a PC client may not be very secure, it does offer some potential benefits such as auto-validating SSL certs. Whether the carriers will bother with a potential revenue stream in two-factor authentication when they can make more money in ringtones is another question - back to the business model ;). Ian Grigg wrote: FTR, e-gold were aware of the general makeup of this threat since 1998 and asked someone to look at it. The long and the short was that it was more difficult to solve than at first claimed, so the project was scrapped. This was a good risk-based decision. The first trojans that I know of for e-gold weren't spotted until 12-18 months ago, so it was also a profitable decision. What they are doing now I don't know. In the payments world we've known how to solve all this for some time, since the early 90s to my knowledge. The only question really is, have you got a business model that will pay for it, because any form of token is very expensive, and the form of token that is needed - a trusted device to put the application, display, keypad and net connection on - is even more expensive than the stop-gap two-factor authentication units commonly sold. iang -- Nick Owen WiKID Systems, Inc. 404.962.8983 (desk) 404.542.9453 (cell) http://www.wikidsystems.com At last, two-factor authentication, without the hassle factor - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Nullsoft's WASTE communication system
And now we see this when you go to the page... very interesting. nick ---begin--- NOTICE OF UNAUTHORIZED SOFTWARE An unauthorized copy of Nullsoft's copyrighted software was briefly posted on this website on or about Wednesday May 28, 2003. The software was identified as WASTE (the Software) and includes the files waste-setup.exe, waste-source.zip, waste-source.tar.gz and any additional files contained in these files. Nullsoft is the exclusive owner of all right, title and interest in the Software. The posting of the Software on this website was not authorized by Nullsoft. If you downloaded or otherwise obtained a copy of the Software, you acquired no lawful rights to the Software and must destroy any and all copies of the Software, including by deleting it from your computer. Any license that you may believe you acquired with the Software is void, revoked and terminated. Any reproduction, distribution, display or other use of the Software by you is unauthorized and an infringement of Nullsoft's copyright in the Software as well as a potential violation of other laws. Thank you. Nullsoft -end-- - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
