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: [Clips] Schwarzenegger signs law to punish phishing
. On Sep 30, 2005, at 8:48 PM, R.A. Hettinga wrote: Schwarzenegger signs law to punish phishing Uhh... how is this to be enforced? I assume that the law states that the perpetrators will be charged, not the companies that are phished. Concrete example may clarify: Someone purporting to be eBay sends a note to me. I click on it, enter my credit card number, expiration date, and other information to make it possible to steal my identity. I'm in California. When said identity theft is discovered, I cite this law and the fact that I'm a victim of said phishing. Would I recover the US$500,000 from my credit card company, eBay, or the state government? Cheers, Hasan Diwan [EMAIL PROTECTED] PGP.sig Description: This is a digitally signed message part
Venona not all decrypted?
I just heard that the Venona intercepts haven't all been decrypted, and that the reason for that was there wasn't enough budget to do so. Is that not enough budget to apply the one-time pads they already have, or is that the once-and-futile exercise of decrypting ciphertext with no one-time pad to go with it? Cheers, RAH -- - R. A. Hettinga mailto: [EMAIL PROTECTED] The Internet Bearer Underwriting Corporation http://www.ibuc.com/ 44 Farquhar Street, Boston, MA 02131 USA ... however it may deserve respect for its usefulness and antiquity, [predicting the end of the world] has not been found agreeable to experience. -- Edward Gibbon, 'Decline and Fall of the Roman Empire' - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Hooking nym to wikipedia
I'm a bit concerned by this scheme. I'm not clear at the moment whether you're proposing imposing it on all wikipedia users or just those that want to access via Tor? On Mon, Oct 03, 2005 at 11:48:48AM +, Jason Holt wrote: * Lack of forward secrecy is indeed an issue, since our metaphorical Chinese dissident must keep around her cert to continue using it, which if discovered links her with all her past activities. This is a problem even if Wikipedia maps each client cert to a particular random value for public display, since the attackers can simply use the stolen cert to make an edit on wikipedia and then check to see if the identifier comes up the same. There's a big useability issue with client certs, in that they are part of a particular PC browser profile and are fiddly to move between PCs; while being moved (e.g. USB key) or at rest on the disk they are vulnerable to raids by the security services. I'd expect the mythical Chinese dissident to be using netcafes rather than his/her home PC which will have a keylogger installed on it / be taken as evidence in raids. (e.g. http://gizmonaut.net/bits/suspect.html ) (Also, I'd expect any serious repressive regimes to simply have anyone found using Tor taken out and shot; has this been addressed?) Pete -- Peter Clay | Campaign for _ _| .__ | Digital / / | | | Rights! \_ \_| | | http://www.ukcdr.org - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Venona not all decrypted?
At 16:20 2005-10-03 -0400, R.A. Hettinga wrote: I just heard that the Venona intercepts haven't all been decrypted, and that the reason for that was there wasn't enough budget to do so. Is that not enough budget to apply the one-time pads they already have, or is that the once-and-futile exercise of decrypting ciphertext with no one-time pad to go with it? Here's my understanding of how Venona worked, and why budget would be a problem. I could be completely off base, though. The OTPs were only very occasionally misused, by being used more than once. So the breaks occurred when two separate messages, or possibly fragments of messages, were combined in such a way as to cancel out the OTP, then the resulting running-key cipher was solved to yield the two messages. I don't think that the NSA had access to the pads themselves, except after having recovered the messages (and hence the pad for those messages). So there really isn't likelihood that that pad would be reused even more times. To detect that a pad has been reused, you basically have to line up two ciphertexts at the right places, combine them appropriately, and run a statistical test on the result to see if it shows significant bias. This is an O(n^2.m) problem, where n is the number of units to be tested (maybe whole messages, maybe pages of OTP, maybe at the character level? Who knows?) and m represents enough text to reliably detect a collision. There was a very large amount of intercepted data, and it's presumably all stored on tapes somewhere, so that n^2 factor probably involves actually mounting tapes and stuff. But in a way, you're right; it should, with today's technology, be possible to just read all the tapes once onto a big RAID, and set the cluster to work for a year or two. Greg. Greg RoseINTERNET: [EMAIL PROTECTED] Qualcomm Incorporated VOICE: +1-858-651-5733 FAX: +1-858-651-5766 5775 Morehouse Drivehttp://people.qualcomm.com/ggr/ San Diego, CA 92121 232B EC8F 44C6 C853 D68F E107 E6BF CD2F 1081 A37C - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Hooking nym to wikipedia
On 10/3/05, Jason Holt [EMAIL PROTECTED] wrote: More thoughts regarding the tokens vs. certs decision, and also multi-use: This is a good summary of the issues. With regard to turning client certs on and off: from many years of experience with anonymous and pseudonymous communication, the big usability problem is remembering which mode you are in - whether you are identified or anonymous. This relates to the technical problem of preventing data from one mode from leaking over into the other. The best solution is to use separate logins for the two modes. This prevents any technical leakage such as cookies or certificates. Separate desktop pictures and browser skins can be selected to provide constant cues about the mode. Using this method it would not be necessary to be asked on every certificate usage, so that problem with certs would not arise. (As far as the Chinese dissident using net cafes, if they are using Tor at all it might be via a USB token like the one (formerly?) available from virtualprivacymachine.com. The browser on the token can be configured to hold the cert, making it portable.) Network eavesdropping should not be a major issue for a pseudonym server. Attackers would have little to gain for all their work. The user is accessing the server via Tor so their anonymity is still protected. Any solution which waits for Wikimedia to make changes to their software will probably be long in coming. When Jimmy Wales was asked whether their software could allow logins for trusted users from otherwise blocked IPs, he didn't have any idea. The technical people are apparently in a separate part of the organization. Even if Jimmy endorsed an idea for changing Wikipedia, he would have to sell it to the technical guys, who would then have to implement and test it in their Wiki code base, then it would have to be deployed in Wikipedia (which is after all their flagship product and one which they would want to be sure not to break). Even once this happened, the problem is only solved for that one case (possibly also for other users of the Wiki code base). What about blogs or other web services that may decide to block Tor? It would be better to have a solution which does not require customization of the web service software. That approach tries to make the Tor tail wag the Internet dog. The alternative of running a pseudonym based web proxy that only lets good users pass through will avoid the need to customize web services on an individual basis, at the expense of requiring a pseudonym quality administrator who cancels nyms that misbehave. For forward secrecy, this service would expunge its records of which nyms had been active, after a day or two (long enough to make sure no complaints are going to come back). As far as the Unlinkable Serial Transactions proposal, the gist of it is to issue a new blinded token whenever one is used. That's a clever idea but it is not adequate for this situtation, because abuse information is not available until after the fact. By the time a complaint arises the miscreant will have long ago received his new blinded token and the service will have no way to stop him from continuing to use it. I could envision a complicated system whereby someone could use a token on Monday to access the net, then on Wednesday they would become eligible to exchange that token for a new one, provided that it had not been black-listed due to complaints in the interim. This adds considerable complexity, including the need to supply people with multiple initial tokens so that they could do multiple net accesses while waiting for their tokens to be eligible for exchange; the risk that exchange would often be followed immediately by use of the new token, harming unlinkability; the difficulty in fully black-listing a user who has multiple independent tokens, when each act of abuse essentially just takes one of his tokens away from him. Overall this would be too cumbersome and problematic to use for this purpose. Providing forward secrecy by having the nym-based web proxy erase its records every two days is certainly less secure than doing it by cryptographic means, but at the same time it is more secure than trusting every web service out there to take similar actions to protect its clients. Until a clean and unemcumbered technological approach is available, this looks like a reasonable compromise. CP - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
