Re: [Cryptography] Opening Discussion: Speculation on "BULLRUN"
Hi all, If you read the articles carefully, you'll note that at no point does the NSA appear to have actually broken the *cryptography* in use. It's hard to get concrete details from such vague writing and no access to the the original documents, but it sounds like they've mostly gotten a lot of backdoors in *systems* (not algorithms, though they may have tried that with Dual_EC_DRBG in NIST SP 800-90 in 2006 ... which lasted barely a year before public cryptographers flagged it). Basically, the summary of this new information appears to be best given by Paul Kocher, who noted that the NSA had pushed for a backdoor key escrow system with the Clipper Chip, was denied, "... and they went and did it anyway, without telling anyone." In this case, it wasn't a mandated key escrow backdoor, but through a combination of targeted interception and strong-arming companies like Google and Microsoft, they got enough. It's the same old story of crypto in the real world: Don't attack the algorithm; Attack the system. Better story here: http://www.schneier.com/blog/archives/2013/09/the_nsa_is_brea.html On Thu, Sep 5, 2013 at 3:58 PM, Perry E. Metzger wrote: > I would like to open the floor to *informed speculation* about > BULLRUN. > > Informed speculation means intelligent, technical ideas about what > has been done. It does not mean wild conspiracy theories and the > like. I will be instructing the moderators (yes, I have help these > days) to ruthlessly prune inappropriate material. > > At the same time, I will repeat that reasonably informed > technical speculation is appropriate, as is any solid information > available. > > > Perry > -- > Perry E. Metzgerpe...@piermont.com > ___ > The cryptography mailing list > cryptography@metzdowd.com > http://www.metzdowd.com/mailman/listinfo/cryptography > -- Lance James http://soundcloud.com/lancejames Office: 760-262-4141 l an...@gmail.com ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: RSA SecurID SID800 Token vulnerable by design
Hadmut Danisch wrote: > Hi Lance, > > On Fri, Sep 08, 2006 at 10:26:45AM -0700, Lance James wrote: >> Another problem from what I see with Malware that steals data is the >> formgrabbing and "on event" logging of data. Malware can detect if >> SecureID is being used based on targeted events, example: Say HSBC >> (Hypothetical example, not targeting HSBC) has two-factor logins in >> place, the problem with this is that it is vulnerable to session riding >> and trojan-in-the-middle attacks anyway, because the minute the user >> logs in, the malware could launder money out (unless transaction auth is >> in place, which in most cases it's not), or they could pharm the user >> with a fake website that resolves as HSBC but they go in within the time >> frame of that token being valid and have access. Either way, however you >> cut it, SecureID/Two-Factor User auth is not protected against malware, >> period. > > > Partly agreed. These kinds of attacks I usually teach in my > workshops. > > However, in all of these cases the attacker has to be online in the > moment you are logging in and you experience any failure, e.g. can't > login or something like that. > > But with the SID800 malware could silently sit in the background and > pass token codes to the attacker even if you do not login at this > moment. E.g. it could wait until you have logged in (or out) and grap > the next token code. > > Furthermore, the attack you described presumes that the attacker knows > where you want to login. But when you could use the current token code > as an indicator for searching login data in the input stream, then you > can find new places to login, e.g. your company VPN access point. > > While the attack you describe is more important for banking, the USB > attack is more against company logins. > Agreed, and since my research is focused on online banking I can see yours and my point, either way, SecurID should not be the only concept for dependence. > regards > Hadmut > > > -- Best Regards, Lance James Secure Science Corp. http://www.securescience.net - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: RSA SecurID SID800 Token vulnerable by design
Hadmut Danisch wrote: > Hi, > > I recently tested an RSA SecurID SID800 Token > http://www.rsasecurity.com/products/securid/datasheets/SID800_DS_0205.pdf > > > The token is bundled with some windows software designed to make > user's life easier. Interestingly, this software provides a function > which directly copies the current token code into the cut-and-paste > buffer, when the token is plugged in into USB. This is weak by design. > > The security of these tokens is based on what RSA calls "two-factor > user authentication": It takes both a secret (PIN) and the > time-dependend Token-Code to authenticate. The security of the > Token-Code depends on the assumption that the token is resistant > against malware or intruders on the computer used for communication > (web browser, VPN client,...). Hi Hadmut, Another problem from what I see with Malware that steals data is the formgrabbing and "on event" logging of data. Malware can detect if SecureID is being used based on targeted events, example: Say HSBC (Hypothetical example, not targeting HSBC) has two-factor logins in place, the problem with this is that it is vulnerable to session riding and trojan-in-the-middle attacks anyway, because the minute the user logs in, the malware could launder money out (unless transaction auth is in place, which in most cases it's not), or they could pharm the user with a fake website that resolves as HSBC but they go in within the time frame of that token being valid and have access. Either way, however you cut it, SecureID/Two-Factor User auth is not protected against malware, period. > > However, if the Token Code can be read over the USB bus, this > assumption does not hold. A single attack on the PC where the token is > plugged in would compromise both the PIN (e.g. with a keylogger) and > the token itself (e.g. writing a daemon which continuously polls the > token and forwards the token in real time to a remote attacker. > > Ironically this could make an attack even easier: If some malware > simultaneously monitors the token and the keyboard, it is much easier > to detect that the keystrokes are actually related to some login > procedure: > > Whenever the 6-digit token code appears in the keyboard or > cut-and-paste input stream, you can be pretty sure that in a sliding > window of about the last 100-200 keystrokes both the PIN and the > address of the server to login is contained. Makes it really easy to > automatically detect secrets in the input stream. > > Thus, two different authentication methods are together weaker than > each single one. > > regards > Hadmut > > ----- > The Cryptography Mailing List > Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED] > -- Best Regards, Lance James Secure Science Corp. http://www.securescience.net - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
RE: Phishers Defeat 2-Factor Auth
Yep, the phishers finally started doing it. If it becomes a threat to them, they will adapt. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Anne & Lynn Wheeler Sent: Tuesday, July 11, 2006 10:39 AM To: cryptography@metzdowd.com Subject: Re: Phishers Defeat 2-Factor Auth Lance James wrote: > Full article at http: // blog.washingtonpost.com / securityfix / happen to mention more than a year ago ... that it would be subject to mitm-attacks ... recent comment on the subject http://www.garlic.com/~lynn/aadsm24.htm#33 Threatwatch - 2-factor tokens attacked by phishers. in thread in this mailing list more than year ago http://www.garlic.com/~lynn/aadsm19.htm#20 Citibank discloses private information to improve security http://www.garlic.com/~lynn/aadsm19.htm#21 Citibank discloses private information to improve security http://www.garlic.com/~lynn/aadsm19.htm#22 Citibank discloses private information to improve security http://www.garlic.com/~lynn/aadsm19.htm#23 Citibank discloses private information to improve security http://www.garlic.com/~lynn/aadsm19.htm#24 Citibank discloses private information to improve security ... and so on - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Phishers Defeat 2-Factor Auth
http://blog.washingtonpost.com/securityfix/2006/07/citibank_phish_spoofs_2fa ctor_1.html Thought this might interest some. -Lance James - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Phishers Defeat 2-Factor Auth
Full article at http: // blog.washingtonpost.com / securityfix / Citibank Phish Spoofs 2-Factor Authentication Security experts have long touted the need for financial Web sites to move beyond mere passwords and implement so-called "two-factor authentication" -- the second factor being something the user has in their physical possession like an access card -- as the answer to protecting customers from phishing attacks that use phony e-mails and bogus Web sites to trick users into forking over their personal and financial data. These methods work, however, only so long as the bad guys don't fake those as well. Take this latest phish, spotted by the people over at Secure Science Corp. It uses an impressively crafted Web-based e-mail that targets users of Citibank's Citibusiness service, which -- as its name suggests -- caters to businesses. Citibusiness also requires customers who want to log into their accounts online to use a supplied token in addition to their user name and password. The small device generates an additional password that changes every minute or so. The scam e-mail says someone (a nice touch added here -- the IP address of the imaginary suspect) has tried to to log in to your account and that you need to "confirm" your account info. Not a whole lot that's revolutionary there, but when you click on the link, you get a very convincing site that looks identical to the Citibusiness login page, complete with a longish Web address that at first glance appears to end in "Citibank.com," but in fact ends at a Web site in Russia called "Tufel-Club.ru." The site asks for your user name and password, as well as the token-generated key. If you visit the site and enter bogus information to test whether the site is legit -- a tactic used by some security-savvy people -- you might be fooled. That's because this site acts as the "man in the middle" -- it submits data provided by the user to the actual Citibusiness login site. If that data generates an error, so does the phishing site, thus making it look more real. Update, 4:41 p.m. ET: I forgot to mention that while this phishing site was active late last week and during the weekend, it has since been shut down. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Status of SRP
Here's where SRP fails: 1) SSL is built into the browser - doesn't stop phishers 2) Chrome or no chrome good luck getting it in there and having every user understand it. 3) Traditional phishing works, but if you force them to change, the malware propagation will only be higher than it is now, and I can give you the numbers on how much data is stolen with malware (over 2 million credit cards have been acquired since January via trojan software - how do I know this, I monitor their blind drops constantly and one group's daily take is over 150 megs of credentials on average. SRP suffers from a rollback attack, chrome or no chrome - humans don't know enough about this, and if the phisher does: "Hi, we're having a problem with your account system as our SRP database was corrupted, please login through the webpage to verify your information and reset your SRP account to working order". Surprisingly, many would fall for this. My 2 cents. -Lance James A. Donald wrote: > -- > James A. Donald wrote: > > > The obvious solution to the phishing crisis is the > > > widespread deployment of SRP > > Lance James > > I disagree here, I don't think this will stop phishing > > for many reasons. Please explain how it would. It will > > stop "man-in-the-middle" attacks on the protocol, but > > phishers aren't attacking the protocols themselves. > > To be useful, SRP has to be in the browser chrome. > > Consider a typical e-gold phish > : :You have just made a request to transfer all > : :the funds in your account. Please click here > : : and login to cancel > : :this request if it was made by someone other > : :than yourself > > Assume e-gold was using SRP login. The user would > attempt to login to www.e-golb.com through SRP, and the > login would fail. > > > It's still single-auth and I can still obtain the user > > password via phishing. > > How? > > SRP never reveals the login. It is zero knowledge. > Instead, both parties prove to each other than they know > the secret, without revealing the secret. > > The only way you can phish the user is to get him to not > use SRP. But if he is attempting to use SRP he is not > typing the password into a web page, but into client > software running on his own machine, which is going to > look visibly different from any web page. > > --digsig > James A. Donald > 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG > bhZzlPU6DtnwH9s5+PxwPlwhgvD/8iFEI9LcuRXA > 4x54cCglld16xbMxUa/22CBHVIxtb7yqM78rQ9Ul1 > > -- Best Regards, Lance James Secure Science Corporation www.securescience.net Author of 'Phishing Exposed' http://securescience.net/home/news/phishingexposed.html ** * New IntelliFound Service 2 weeks free * * Real-Time Identity Surveillance Service* * http://www.securescience.net/ * ** - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Status of SRP
Lance James wrote: > James A. Donald wrote: > >> The obvious solution to the phishing crisis is the widespread >> deployment of SRP, but this does not seem to happening. SASL-SRP was >> recently dropped. What is the problem? >> > > I want to clarify, because by typing to fast, i think my variables may be confusing since I was reading the spec of SRP from two diff docs. u and x in my sentence was username and password not x being typical derived secret. what it should be is u and p. please note corrections. Thanks. > I disagree here, I don't think this will stop phishing for many reasons. > Please explain how it would. It will stop "man-in-the-middle" attacks on > the protocol, but phishers aren't attacking the protocols themselves. > > It's still single-auth and I can still obtain the user password via > phishing. Please correct me if I'm wrong but phishing is before this > protocol will be accessed. > > if Mallory convinces Carol to log into a spoofed site that looks like > Steve not running SRP, then u and x are obtained by Mallory. Mallory > simply logs into Steve with U and X. > > In SRP what is preshared is g^x where x = H(s,p) where s is a salt and p > is the password. > > p would be a weakness here because the user knows it, and in phishing, > if the user knows it, the user is vulnerable. > > My 2 cents. > >> - >> The Cryptography Mailing List >> Unsubscribe by sending "unsubscribe cryptography" to >> [EMAIL PROTECTED] >> >> >> > > > -- Best Regards, Lance James Secure Science Corporation www.securescience.net Author of 'Phishing Exposed' http://securescience.net/home/news/phishingexposed.html ** * New IntelliFound Service 2 weeks free * * Real-Time Identity Surveillance Service* * http://www.securescience.net/ * ** - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Status of SRP
James A. Donald wrote: > The obvious solution to the phishing crisis is the widespread > deployment of SRP, but this does not seem to happening. SASL-SRP was > recently dropped. What is the problem? I disagree here, I don't think this will stop phishing for many reasons. Please explain how it would. It will stop "man-in-the-middle" attacks on the protocol, but phishers aren't attacking the protocols themselves. It's still single-auth and I can still obtain the user password via phishing. Please correct me if I'm wrong but phishing is before this protocol will be accessed. if Mallory convinces Carol to log into a spoofed site that looks like Steve not running SRP, then u and x are obtained by Mallory. Mallory simply logs into Steve with U and X. In SRP what is preshared is g^x where x = H(s,p) where s is a salt and p is the password. p would be a weakness here because the user knows it, and in phishing, if the user knows it, the user is vulnerable. My 2 cents. > > - > The Cryptography Mailing List > Unsubscribe by sending "unsubscribe cryptography" to > [EMAIL PROTECTED] > > -- Best Regards, Lance James Secure Science Corporation www.securescience.net Author of 'Phishing Exposed' http://securescience.net/home/news/phishingexposed.html ** * New IntelliFound Service 2 weeks free * * Real-Time Identity Surveillance Service* * http://www.securescience.net/ * ** - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Kama Sutra Spoofs Digital Certificates
Peter Gutmann wrote: >Anne & Lynn Wheeler <[EMAIL PROTECTED]> writes: > > > >>The Kama Sutra worm can fool WIndows into accepting a malicious ActiveX >>control >>by spoofing a digital signature, a security company said Tuesday. >> >> > >If you track down the original Fortinet advisory you'll see that the >Information- >Week text is slightly misleading, all it does is set the "this control is all >right" flags in the registry to make Windows think it's passed a signature >check >at some point in the past. > > Sounds like a "pseudo-Cache" attack then - is that not valid as a "spoof" though? There was an embedded SSL Cache attack a few years back, and that was considered a man-in-the-middle spoof attack. Is there a specific definition to that? >Peter. > > >- >The Cryptography Mailing List >Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED] > > > > -- Best Regards, Lance James Secure Science Corporation www.securescience.net Author of 'Phishing Exposed' http://www.securescience.net/amazon/ - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Diebold - might be of interest
Hi all, I don't know if this is appropriate on this list, but I know that diebold voting systems have been an issue in the cryptography community for a while now. Having said that, I'm pasting an article that I received (from my parents actually) that might be of interest to this group. If it is not, just moderate :) *Subject:* Black Box Darkness is settling over the election process in San Diego. I say get rid of anything electronic that has to do with elections. Realistic sentiment?! Gene VIEWING THE DIEBOLD VOTE-TALLYING SCREEN PROHIBITED Jim March, a member of the Black Box Voting board of directors, was arrested Tuesday evening for trying to observe the Diebold central tabulator (vote tallying machine) as the votes were being counted in San Diego's mayoral election (July 26). (- online discussion: http:/www.blackboxvoting.org -) According to Jim Hamilton, an elections integrity advocate from San Diego, he and March visited the office of the registrar of elections earlier in the day. During this visit, March made two requests, which were refused by Mikel Haas, the San Diego Registrar of elections. 1) March asked that the central tabulator, the computer that tallies up the votes from all the precincts, be positioned so that citizens could observe it. According to Hamilton, this would have required simply moving a table a few feet. 2) March also asked for a copy of the ".gbf" files -- the vote tally files collected during the course of tabulation - to be provided for examination after the election. During the tallying of the election, the Diebold computer was positioned too far away for citizens to read the screen. Citizens could not watch error messages, or even perceive significant anomalies or malfunctions. Unable to see the screen, March went into the office where the tabulator was housed. Two deputies followed him and escorted him out. According to Hamilton: "He was not belligerent, not at all. After he went inside the tabulator room he came [was escorted] out and he said clearly 'I'm not resisting.' They handcuffed him, took him out of the building. They put him in a squad car. They're going to take him to the police station, book him and take him to jail," said Hamilton. "He's getting charged with a felony, 'interfering with an election official.'" March's actions are the culmination of two years of increasing frustration with the refusal of election officials to respond to security deficiencies in the voting machines. The software that tallies the votes in San Diego is made by Diebold Election Systems, a company that has already paid the state of California $2.8 million for making false claims, due to a lawsuit filed by March and Black Box Voting founder Bev Harris. On July 4, a report was released by European computer security expert Harri Hursti, revealing that the Diebold voting system contains profound architectural flaws. "It is open for business," says Hursti, who demonstrated the flaws on Leon County, Florida Diebold machines. He penetrated the voting system in less than five minutes, manipulating vote reports in a way that was undetectable. Despite the critical security alert issued by Hursti, San Diego County sent 713 voting machines home with poll workers, increasing the risk that the "memory cards" housed in the machines could be hacked, and removing the argument that "inside access" was carefully safeguarded. The arrest of Jim March underlines a fundamental problem facing Americans today as, increasingly, they lose the ability to monitor, verify, or watch any part of the counting process. The San Diego registrar of elections knew of the security flaws in the voting system. Diebold has never denied the vulnerability identified in Hursti's report, found at http://www.blackboxvoting.org/BBVreport.pdf. Despite knowledge of the increased risks, Haas made the decision to create additional vulnerability by sending the machines home with hundreds of poll workers. While San Diego officials will no doubt point to a small seal on the compartment housing the memory card (the component exploited in Hursti's study), Black Box Voting has interviewed a former San Diego poll worker, who reported that all that is necessary to dislodge and then reaffix the seal is a small pair of pliers. IN A NUTSHELL: - The machines have been demonstrated to be vulnerable to undetected tampering - The San Diego registrar of voters chose not to take appropriate precautions - The main tally machine was placed in a location that was impossible for citizens to observe - Many voting integrity advocates have come to believe that voting machine reform now rivals the urgency of the Civil Rights movement in the 1960s. Jim March acted on those beliefs. * * * * * If you share the feelings that Jim March has expressed about voting system secrecy, please forward this message to your lists and to online blogs as appropriate. Permission granted to reprint, with link to http://www.blackboxvoting.org.
Re: New Credit Card Scam (fwd)
Jason Holt wrote: On Mon, 11 Jul 2005, Lance James wrote: [...] place to fend off these attacks. Soon phishers will just use the site itself to phish users, pushing away the dependency on tricking the user with a "spoofed" or "mirrored" site. [...] You dismiss too much with your "just". They already do attack plenty of sites, but they also phish because it has a larger return on investment. Security is the process of iteratively strengthening the weakest links in the chain. I'm being misunderstood - Cross-User attack concepts specifically is what I'm referring to. The straight on attacks on sites are definitely a processed phase within the many attack vectors they are performing, I'm just making clear that the businesses need to start working on those weak links. -Lance -J -- Best Regards, Lance James Secure Science Corporation www.securescience.net Author of 'Phishing Exposed' http://www.securescience.net/amazon/ Find out how malware is affecting your company: Get a DIA account today! https://slam.securescience.com/signup.cgi - it's free! - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: New Credit Card Scam (fwd)
Jason Holt wrote: I remember the first time a site asked for the number on the back of my credit card. It was a Walmart or Amazon purchase, and with no warning they redirected me to some site with a questionable domain. I thought for sure my session was being hijacked, and my bank had given me no idea what the number was for or whether it was something I was supposed to give out. To me, this is closely related to the discussions we have here about web browser security semantics. With a very good understanding of the underlying PKI, we can usually sort out "secure" from "suspicious" site behaviors with some discussion, but how is the average user (or even the average engineer) supposed to cope? Is there a standard or even just a document somewhere that defines best practices for both server and user behavior with respect to SSL web sites and credit card transactions? Or are we leaving them to forward emails to each other warning them not to give out their 3-digit codes over the phone, and that they had better make sure their Dell doesn't have a DHS keylogger installed... Even with standards in place for the consumer, that's only half of the circle. Phishers/Scammers are evolving rapidly and are either black hats themselves or have access to employing black hats to compromise sites, or perform cross-user attacks on the user. Companies like Amazon are only as secure as how they have devised their infrastructure - and as you and everyone else here knows, SSL is one layer of the "security in depth" infrastructure model. This threat vector has not been addressed by commercial entities that offer transaction services for many reasons, one being that the procurement process takes a long time just to get any security technology in place to fend off these attacks. Soon phishers will just use the site itself to phish users, pushing away the dependency on tricking the user with a "spoofed" or "mirrored" site. -J -- Forwarded message -- Date: Mon, 11 Jul 2005 11:28:50 -0700 To: undisclosed-recipients: ; Subject: New Credit Card Scam I got this from a co-worker today: Apparently, they don't ask for your number, just the 3 digit code on the back. They'll tell you they're calling from your Visa or Mastercard company and that they're trying to verify whether or not you've made a $497.99 purchase from a company in Arizona or something. They'll tell you to call your credit card company if you have any questions, etc, and they never ask for your card number, so it sounds pretty legit, but it's not. If it does happen to you, within a few minutes of the phone call you'll have a charge for $497.99 on your card. You can always call the credit card company yourself and make sure they're the ones wanting to check about fradulent charges, so if you get a call that sounds fishy, just tell them you'll call them back at the number on your card. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED] -- Best Regards, Lance James Secure Science Corporation www.securescience.net Author of 'Phishing Exposed' http://www.securescience.net/amazon/ Find out how malware is affecting your company: Get a DIA account today! https://slam.securescience.com/signup.cgi - it's free! - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Why Blockbuster looks at your ID.
Adam Shostack wrote: On Sun, Jul 10, 2005 at 12:13:42AM +0100, Peter Fairbrother wrote: | Perry E. Metzger wrote: | | > A system in which the credit card was replaced by a small, calculator | > style token with a smartcard style connector could effectively | > eliminate most of the in person and over the net fraud we experience, | > and thus get rid of large costs in the system and get rid of the need | > for every Tom, Dick and Harry to see your drivers license when you | > make a purchase. It would both improve personal privacy and help the | > economy by massively reducing transaction costs. | | I agree that it might well reduce costs and fraud - but how will it improve | privacy? Your name is already on the card ... and the issuer will still have | a list of your transactions. | | Not having to show ID may save annoyance, but it doesn't significantly | improve privacy. Most credit card issuers will happily give you extra cards, so your friends can spend your money. In whatever name you want. If you need to show ID, this can become, umm, complicated. This goes along with paypal's "send a friend a debit card" feature (I saw this two years ago, I don't know if this is still present), but this essentially allowed a user to add any name to the debit visa card (treated in most places like a credit card) which in some cases actually allowed online hijacking of domain names (depending on registrar) because the name was the same on the visa card used. -Lance -- Best Regards, Lance James Secure Science Corporation www.securescience.net Author of 'Phishing Exposed' http://www.securescience.net/amazon/ Find out how malware is affecting your company: Get a DIA account today! https://slam.securescience.com/signup.cgi - it's free! - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: the limits of crypto and authentication
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. There is a possible solution against an OLE event driven session rider such as this one. The solution I proposed was to use a variant of CAPTCHA that would add mutual authentication in the mix within the picture. Yes, there are some people that say CAPTCHA can be broken, but in the game of phishing, it's abouit numbers, not about silver bullets. The way to get around the "porn" CAPTCHA problem was to ask something that the user might only know and then ask the user about the activity they are performing. This would stop this instance of E-gold attacks. --Steven M. Bellovin, http://www.cs.columbia.edu/~smb - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED] -- Best Regards, Lance James Secure Science Corporation www.securescience.net Author of 'Phishing Exposed' http://www.securescience.net/amazon/ Find out how malware is affecting your company: Get a DIA account today! https://slam.securescience.com/signup.cgi - it's free! - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: [Anti-fraud] Re: Feature or Flaw?
Amir Herzberg wrote: Lance James wrote: Amir Herzberg wrote: Lance James wrote: ... > https://slam.securescience.com/threats/mixed.html This site is set so that there is a frame of https://www.bankone.com inside my https://slam.securescience.com/threats/mixed.html site. The imaginative part is that you may have to reverse the rolls to understand the impact of this (https://www.bankone.com with https://slam.securescience.com frame -> done via cross-user attacks Ok, I can do the `mental exercise` and understand the attack. But I'm not sure what is new here. Yes, if a web-site allows such XSS, then It's not the "new" issue - it's the concern that frames with other SSL protect information is not being indicated to the user, thus you can encrypt data with another valid cert within a frame(s) and the user will only know of the main cert from the domain that is indicated by the address bar. Well, but I don't see that this has much to do with SSL, really. The problem is that the attacker is able to cause the server to send a page controlled (partially or fully) by the attacker. This should not happen. SSL is only supposed to ensure that the client got the page as the server sent it - and this does happen. Of course, this cannot protect against an infinite list of possible errors and vulnerabilities of the server: -- XSS attacks -- Defacement -- an employee intentionally putting a script to do I agree that so far this issue only lies within an XSS or already compromisable setup against SSL - so again, the site is considered compromised - but, the fact that embedded objects can be called into play that are considered "protected" within another frame can not be identified by the user, in my opinion, may cause unforeseeable risks. ... I think that your complaint/observation is that browsers normally warn when displaying a page which is partially protected and partially not, but may not complain when displaying a page protected by cert X, but including frame protected by cert Y. Well, this can be fixed, but I'm not sure this is really important. The problem is really the fact that the page was modified in the first place. Instead of including a protected (or unprotected) frame with the rogue code, the attack could have sent the rogue code directly from the compromised site. This is technically true, the attacker can easily divise it's own forms and make it work rather easily (of course in the real world, the link would be a bit excessive when used in a phishing attack). I bring this up, for the same reason the "Secunia Javascript origin" vulnerability was brought up - is that really a flaw??? I'm not attempting to be alarmist, I'm trying to drive a point home. Thoughts? -- Best Regards, Lance James Secure Science Corporation www.securescience.net Author of 'Phishing Exposed' http://www.securescience.net/amazon/ Find out how malware is affecting your company: Get a DIA account today! https://slam.securescience.com/signup.cgi - it's free! - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Feature or Flaw?
Florian Weimer wrote: * Lance James: And as stated above, reverse the effect and it would be the banks in scenarios such as XSS. In case of XSS or CSRF, you have lost anyway. The web was not designed as a presentation service for transaction processing, especially if the transactions involve significant value. If you use the web for this purpose, it's always a tradeoff. Maybe it's time to realize that all these web applications together form a huge monoculture, and to move on and diversify again. Thank you - that was my point essentially. SSL is and always will be for web a broken concept. -- Best Regards, Lance James Secure Science Corporation www.securescience.net Author of 'Phishing Exposed' http://www.securescience.net/amazon/ Find out how malware is affecting your company: Get a DIA account today! https://slam.securescience.com/signup.cgi - it's free! - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Feature or Flaw?
Amir Herzberg wrote: Lance James wrote: ... > https://slam.securescience.com/threats/mixed.html This site is set so that there is a frame of https://www.bankone.com inside my https://slam.securescience.com/threats/mixed.html site. The imaginative part is that you may have to reverse the rolls to understand the impact of this (https://www.bankone.com with https://slam.securescience.com frame -> done via cross-user attacks Ok, I can do the `mental exercise` and understand the attack. But I'm not sure what is new here. Yes, if a web-site allows such XSS, then even SSL won't help it - it could end up sending the _wrong_ page, protected by SSL... And in this case I don't even think we can blame browser UI; the browser actually got this `bad` page from the server... It's not the "new" issue - it's the concern that frames with other SSL protect information is not being indicated to the user, thus you can encrypt data with another valid cert within a frame(s) and the user will only know of the main cert from the domain that is indicated by the address bar. Maybe I miss something? BTW, there is a new list focsed on such issues, at http://lists.cacert.org/cgi-bin/mailman/listinfo/anti-fraud -- Best Regards, Lance James Secure Science Corporation www.securescience.net Author of 'Phishing Exposed' http://www.securescience.net/amazon/ Find out how malware is affecting your company: Get a DIA account today! https://slam.securescience.com/signup.cgi - it's free! - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Feature or Flaw?
Florian Weimer wrote: * Lance James: Couldn't you just copy (or proxy all content) and get the same effect without using frames at all? How would you go about doing that and still get the SSL Lock to remain as the banks? Can you give an example? In both cases, you have the SSL lock on your own certificate. And as stated above, reverse the effect and it would be the banks in scenarios such as XSS. The Banks SSL cert is actually handling all the data, my concern is that the user is not aware of this and only trusts the domain that's indicated in the address bar's cert. At least my browser does not provide a user interface to access the certificates of the servers from which embedded objects (or frames) were downloaded. -- Best Regards, Lance James Secure Science Corporation www.securescience.net Author of 'Phishing Exposed' http://www.securescience.net/amazon/ Find out how malware is affecting your company: Get a DIA account today! https://slam.securescience.com/signup.cgi - it's free! - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Feature or Flaw?
Florian Weimer wrote: * Lance James: Feature, or flaw? Couldn't you just copy (or proxy all content) and get the same effect without using frames at all? How would you go about doing that and still get the SSL Lock to remain as the banks? Can you give an example? Maybe I'm just missing something. -- Best Regards, Lance James Secure Science Corporation www.securescience.net Author of 'Phishing Exposed' http://www.securescience.net/amazon/ Find out how malware is affecting your company: Get a DIA account today! https://slam.securescience.com/signup.cgi - it's free! - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Feature or Flaw?
Amir Herzberg wrote: Lance James wrote: ... > https://slam.securescience.com/threats/mixed.html This site is set so that there is a frame of https://www.bankone.com inside my https://slam.securescience.com/threats/mixed.html site. The imaginative part is that you may have to reverse the rolls to understand the impact of this (https://www.bankone.com with https://slam.securescience.com frame -> done via cross-user attacks Ok, I can do the `mental exercise` and understand the attack. But I'm not sure what is new here. Yes, if a web-site allows such XSS, then even SSL won't help it - it could end up sending the _wrong_ page, protected by SSL... And in this case I don't even think we can blame browser UI; the browser actually got this `bad` page from the server... Maybe I miss something? Ok, XSS or not, my concern is that you have multiple Certificates within a session, and the user is not aware of the others. Yes, they are valid, but define valid within SSL certs means, I go to geotrust or some CA, use my stolen credit card and buy a valid cert. BTW, there is a new list focsed on such issues, at http://lists.cacert.org/cgi-bin/mailman/listinfo/anti-fraud -- Best Regards, Lance James Secure Science Corporation www.securescience.net Author of 'Phishing Exposed' http://www.securescience.net/amazon/ Find out how malware is affecting your company: Get a DIA account today! https://slam.securescience.com/signup.cgi - it's free! - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Feature or Flaw?
Hi all, I wanted to introduce something that has probably been known for some time now, but has never been really addressed due to possible conflicting views of how SSL certificates should work, and where the CA's should (or should not) fit in. As we all know, the recent attention to the phishing threat vector has spawned some interesting views of how we look at certain responses that a web browser might appropriate in regards to certain conditions set by the server. Some of these include the recent "javascript dialog" box vulnerability, since there are requests that a javascript dialog box should display it's origin, etc... (see http://secunia.com/multiple_browsers_dialog_origin_vulnerability_test). In light of that, I thought it might be relevant to address a question that's been on my mind, and figure that the cryptography list may be the best place to find the answer. (the answer is 42, just kidding). I've set up a site that requires a bit of imagination since I don't wish to expose any financial institutions (bankone is just a random example that I chose) that may be vulnerable to cross-user attacks, but I can tell you that this discovery of impact was done within an audit that explicitly demonstrated a problem. Also, I use a thawte signed certificate, so some mozilla browsers do not seem to regard it as a valid CA, please ignore that if you get a warning, as it is only a distraction of the real problem (aka, if it were a verisign cert it would not warn). https://slam.securescience.com/threats/mixed.html This site is set so that there is a frame of https://www.bankone.com inside my https://slam.securescience.com/threats/mixed.html site. The imaginative part is that you may have to reverse the rolls to understand the impact of this (https://www.bankone.com with https://slam.securescience.com frame -> done via cross-user attacks trivially). At the bottom you will see the securescience.com certificate, but no indication of the bankone certificate. You will also not get any warnings due to the fact that the bankone certificate is validly signed by a CA. With the Cross-User threat vector, a phisher can easily use a validly signed Cert to perform a site takeover with no warning that an outside (the domain) certificate exists within the site. The lock does show that it's secure, and there are no indications that this site should not be "trusted" according to the rules that are dispersed to the mainstream public. Unfortunately, this "Mixed" attack in a cross-user scenario could be encrypting/decrypting the login page with the attacker cert and no one is the wiser without heavy inspection of the source code. Feature, or flaw? -- Best Regards, Lance James Secure Science Corporation www.securescience.net Author of 'Phishing Exposed' http://www.securescience.net/amazon/ Find out how malware is affecting your company: Get a DIA account today! https://slam.securescience.com/signup.cgi - it's free! - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Some companies are just asking for it.
Steve Furlong wrote: On 6/24/05, Perry E. Metzger <[EMAIL PROTECTED]> wrote: For the record, the guys at Fidelity Investments have always seemed to me to have their act together on security, unlike lots of other A few years ago I did some consulting at Fidelity Investments, writing code to spider their own websites for, among other things, security. The fact that they were willing to pay for a few months of my time, plus the obscene markup for the company I billed through and putting me up in Boston, suggests they were serious about it. I can vouch on that level as well, unfortunately what I can vouch for is covered under NDA - but I can tell you they are very serious about addressing security - mind you, no one is perfect. -- Best Regards, Lance James Secure Science Corporation www.securescience.net Author of 'Phishing Exposed' http://www.securescience.net/amazon/ Find out how malware is affecting your company: Get a DIA account today! https://slam.securescience.com/signup.cgi - it's free! - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Some companies are just asking for it.
John Levine wrote: My girlfriend just got an (apparently legitimate from what I can tell) HTML email from her credit card company, complete with lots of lovely images and an exhortation to sign up for their new secure online "ShopSafe" service that apparently generates one time credit card numbers on the fly. John, I have some serious samples of "Consumer Mis-education" as it's been dubbed - I actually provided some of the samples in Aaron's report. Side note, not only are the emails confusing, but every email that I get from a consumer, so far I've gotten (the american express in the powerpoint especially is really screwed) ebay, amex, bank of america all had major vulnerabilities that allow cross-user attacks within them. Not only that, to add to his report, with cross-user attacks (I'm probably preaching to the choir but, it's still interesting) you can foil SSL connections with the lock by using what I call a "Mixed-SSL" attack, where you have multiple frame control with your valid certs, but the domain url is https://www.americanexpress.com. This in essence only indicates one SSL cert, that being the banks site that you have injected code into and by walking the DOM you essentially use your certs to maintain the secure frame objects. (For a demo of this contact me offline). There was a point - oh yes, with the emails - in most of these cases, there can be what I call a bulk mail "replay" attack. Assume a phisher has a "BofA" account, and receives the bulk mailings of the legitimate Financial Institution (FI). This is a safe assumption because in the past we have seen a phisher utilize a real BofA email and just replaced the links with poisoned links that used BofA's site to phish the user. So with some timing, a "replay" attack can be organized - since we establish that say "BofA" has some vulnerabilities in XSS (This is just an example, no offense to BofA), the phisher can wait for a commerical legitimate marketing campaign and then mix in his poisoned mass mailing within the same time frame as these are going out. This will not only confuse the customer, but when reported may get underestimated because the FI did in fact send out a mass-mail to their customers*. The poisoned URL with the real domain and real (SSL-MIX) lock at the bottom of the screen belonging to Bank of America (even though the phisher took over the site) could potentially increase ROI by inducing "misplaced trust" or cause severe lack of confidence within the already troubling concept of online banking. -Lance *Ironically, i did find a vulnerability previously in a certain FI mass mailing campaign that allowed me to arbitrarily subscribe anyone's email address to their campaign list and control settings for whether they get the "Solicited" Commercial Email. This adds to the effect since phishers can subscribe anyone, not just their customers. Shopsafe is rather nice. I use it all the time, and it's written in flash which works on my FreeBSD laptop. On the other hand, MBNA's mail practices would be laughable if they weren't entirely in line with every other bank in the country. If you read Dave Farber's IP list, a couple of days ago Bob Frankston sent in an alarmed note saying that some info from his Bank of America account had apparently been stolen and used in a phish, and I wrote to tell him that no, the mail was real, from the service bureau they use which has a name nobody outside the banking industry knows. Aaron Emigh of Radix Labs wrote to tell me about a talk he gave earlier this year at an Anti-Phishing Working Group earlier this year on this topic, which starts with a set of examples of real bank mail each of which looks phishier than the last. This is 30MB due to the voiceover, but if you have a fast web connection, it's worth running. It needs Powerpoint: http://www.radixlabs.com/idtheft/aaron-emigh-education.pps Regards, John Levine, [EMAIL PROTECTED], Primary Perpetrator of "The Internet for Dummies", Information Superhighwayman wanna-be, http://www.johnlevine.com, Mayor "I dropped the toothpaste", said Tom, crestfallenly. ----- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED] -- Best Regards, Lance James Secure Science Corporation www.securescience.net Author of 'Phishing Exposed' http://www.securescience.net/amazon/ Find out how malware is affecting your company: Get a DIA account today! https://slam.securescience.com/signup.cgi - it's free! - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: WYTM - "but what if it was true?"
Adam Shostack wrote: On Wed, Jun 22, 2005 at 01:54:34PM +0100, Ian Grigg wrote: | A highly aspirated but otherwise normal watcher of black helicopters asked: | | > Any idea if this is true? | > (WockerWocker, Wed Jun 22 12:07:31 2005) | > http://c0x2.de/lol/lol.html | | Beats me. But what it if it was true. What's your advice to | clients? "Duuude, stop buying Dell." The Secret service isn't part of DHS. DHS seal is different. The photos don't really show that cable in a laptop, and if they do, they don't show it in a Dell laptop. Correction: The secret service IS part of DHS. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED] -- Best Regards, Lance James Secure Science Corporation www.securescience.net Author of 'Phishing Exposed' http://www.securescience.net/amazon/ Find out how malware is affecting your company: Get a DIA account today! https://slam.securescience.com/signup.cgi - it's free! - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
RE: AmEx unprotected login site
Protected or not, AmericanExpress.com has multiple web vulnerabilities - I wouldn't log into it with a ten-foot pole :) -Lance -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Perry E. Metzger Sent: Wednesday, June 08, 2005 12:16 PM To: Jerrold Leichter Cc: Amir Herzberg; cryptography@metzdowd.com Subject: Re: AmEx unprotected login site Jerrold Leichter <[EMAIL PROTECTED]> writes: > If you look at their site now, they *claim* to have fixed it: The login box > has a little lock symbol on it. Click on that, and you get a pop-up window > discussing the security of the page. It says that although the page itself > isn't protected, "your information is transmitted via a secure environment". > > No clue as to what exactly they are doing, hence if it really is secure. They're still doing the wrong thing. Unless the page was transmitted to you securely, you have no way to trust that your username and password are going to them and not to someone who cleverly sent you an altered version of the page. Perry - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Citibank discloses private information to improve security
Ed Gerck wrote: Suppose you choose "A4RT" as your codeword. The codeword has no privacy concern (it does not identify you) and is dynamic -- you can change it at will, if you suspect someone else got it. Compare with the other two identifiers that Citibank is using. Your full name is private and static. The ATM's last-four is private and static too (unless you want the burden to change your card often). I agree on the privacy issue, your point is well taken there. Lance James wrote: But from your point, the codeword would be in the clear as well. Respectively speaking, I don't see how either solution would solve this. Ed Gerck wrote: List, In an effort to stop phishing emails, Citibank is including in a plaintext email the full name of the account holder and the last four digits of the ATM card. -- Best Regards, Lance James Secure Science Corporation www.securescience.com Author of 'Phishing Exposed' http://www.securescience.net/amazon/ Have Phishers stolen your customers' logins? Find out with DIA https://slam.securescience.com/signup.cgi - it's free! - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Citibank discloses private information to improve security
But from your point, the codeword would be in the clear as well. Respectively speaking, I don't see how either solution would solve this. Ed Gerck wrote: List, In an effort to stop phishing emails, Citibank is including in a plaintext email the full name of the account holder and the last four digits of the ATM card. Not only are these personal identifiers sent in an insecure communication, such use is not authorized by the person they identify. Therefore, I believe that some points need to be made in regard to right to privacy and security expectations. It's the usual tactic of pushing the liability to the user. The account holder gets the full liability for the "security" procedure used by the bank. A better solution, along the same lines, would have been for Citibank to ask from their account holders when they login for Internet banking, whether they would like to set up a three- or four-character combination to be used in all emails from the bank to the account holder. This combination would not be static, because it could be changed by the user at will, and would not identify the user in any other way. Private, identifying information of customers have been used before by banks for customer login. The account holder's name, the ATM card number, the account number, and the SSN have all been used, and abandoned, for Internet banking login. Why? Because of the increased exposure creating additional risks. Now, with the unilateral disclosure by Citibank of the account holder's name as used in the account and the last four digits of the ATM number, Citibank is back tracking its own advances in user login (when they abandoned those identifiers). Of course, banks consider the ATM card their property, as well as the number they contain. However, the ATM card number is a unique personal identifier and should not be disclosed in a plaintext email without authorization. A much better solution (see above) exists, even using plaintext email -- use a codeword that is agreed beforehand with the user. This would be a win-win solution, with no additional privacy and security risk. Or is email becoming even more insecure, with our private information being more and more disclosed by those who should actually guard it, in the name of security? Cheers, Ed Gerck -- Best Regards, Lance James Secure Science Corporation www.securescience.com Author of 'Phishing Exposed' http://www.securescience.net/amazon/ Have Phishers stolen your customers' logins? Find out with DIA https://slam.securescience.com/signup.cgi - it's free! - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: DES FIPS is finally withdrawn.
Perry E. Metzger wrote: At long last, the DES FIPSes are withdrawn: http://cryptome.org/nist051905.txt Any comments on the NSA SHA-2 patents? -- Best Regards, Lance James Secure Science Corporation www.securescience.com Author of 'Phishing Exposed' http://www.securescience.net/amazon/ Have Phishers stolen your customers' logins? Find out with DIA https://slam.securescience.com/signup.cgi - it's free! - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Secure Science issues preview of their upcoming block cipher
David Wagner wrote: Seecure Science Corporation writes: Secure Science is offering a preview of one of the 3 ciphers they will be publishing througout the year. [...] This cipher is [...] provably just as secure as AES-128. Adam Shostack writes: Really? How does one go about proving the security of a block cipher? Lance James @ Secure Science Corporation writes: We will be proposing 2 hashes as well. Well, that is completely non-responsive to the point Adam made. You used the term "provably". Where is your proof? Did you understand the point Adam is making? In this field, the term "provably" means that there you have a mathematical proof. Do you have such a proof? I'm awfully skeptical Will you retract the claim that SS2 is "provably just as secure as AES-128"? David, There is a miswording here, we were trying to show that both AES and CS2-128 are resistant to the same class of attacks. We definitely did not try to state that they are equivalent. I recommend reading http://eprint.iacr.org/2004/085.pdf to see for yourself. -Lance As for your future hashes, will you be making similar claims? - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED] -- Best Regards, Lance James Secure Science Corporation [Have Phishers stolen your customers' logins? Find out with DIA] https://slam.securescience.com/signup.cgi - it's free! - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Secure Science issues preview of their upcoming block cipher
Adam Shostack wrote: Really? How does one go about proving the security of a block cipher? My understanding is that you, and others, perform attacks against it, and see how it holds up. Many of the very best minds out there attacked AES, so for your new CS2 cipher to be "provably just as secure as AES-128," all those people would have had to have spent as much time and energy as they did on AES. That strikes me as unlikely, there's a lot more interest in hash functions today. We will be proposing 2 hashes as well. Adam PS: I've added the cryptography mail list to this. Some of the folks over there may be interested in your claims. On Wed, Mar 23, 2005 at 05:00:25PM -0800, BugTraq wrote: | Secure Science is offering a preview of one of the 3 ciphers they will | be publishing througout the year. The CS2-128 cipher is a 128-bit block | cipher with a 128 bit key. This cipher is proposed as an alternative | hardware-based cipher to AES, being that it is more efficient in | hardware, simpler to implement, and provably just as secure as AES-128. | | http://www.securescience.net/ciphers/csc2/ | | -- | Best Regards, | Secure Science Corporation | [Have Phishers stolen your customers' logins? Find out with DIA] | https://slam.securescience.com/signup.cgi - it's free! | -- Best Regards, Lance James Secure Science Corporation [Have Phishers stolen your customers' logins? Find out with DIA] https://slam.securescience.com/signup.cgi - it's free! - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Off-list request
I don't know if it's inappropriate to ask on this list, but regarding http://www.securescience.net/ciphers/csc2/ Can I get off-list quotes regarding a formal professional review and possible assistance in the steps taken to establish this cipher into the review process. Thank you. -- Best Regards, Lance James Secure Science Corporation [Have Phishers stolen your customers' logins? Find out with DIA] https://slam.securescience.com/signup.cgi - it's free! - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Public Peer Review requests!
InvisibleNet has formed the Invisible Internet Project (I2P) to support the efforts of those trying to build a more free society by offering them an uncensorable, anonymous, and secure communication system. I2P is a development effort producing a variable latency, fully distributed, autonomous, scalable, anonymous, resilient, and secure network. The goal is to be able to operate successfully in arbitrarily hostile environments - even when an organization with unlimited financial and political resources attacks it. I2P is not a filesharing app. I2P is essentially an anonymizing and secure replacement IP stack, running on top of the existing network. There has already been progress made in writing applications on top of the network to enable generic TCP/IP applications to tunnel through the network transparently, as well as to enable nym lookup and management - two applications which, when paired together, would allow any web browser to point at http://www.[yournym].iip/ and communicate with your webserver anonymously and securely. There are many more ideas for what I2P could be used for, and its certain we won't think of the most interesting ones. I2P is an absurdly ambitious effort. Depending on what mailing lists you read or people you talk with, they'll either say its impossible or just insanely hard. To be perfectly frank, I2P by itself doesn't contribute anything really significant to the CS/P2P research community, but it does take the great work of other projects and research efforts - such as freenet, iip, kademlia, mnet, tarzan, the remailers, and many, many more - and attempts to apply good software engineering techniques to provide hard anonymity and security in a variable latency network. "Variable latency" is repeated so often because I2P doesn't try to operate with a one size fits all set of anonymity and security constraints, and different people will require different tradeoffs. Bin Laden will probably not be able to pull off live streaming video, but Joe and Jane Sixpack and should be able to. Is I2P ready to download and run with? No. So why bother mentioning it? Because we need more critical eyes to make sure we address the right issues the right ways. We think we've got things pegged so that it'll not only work, but also be secure and anonymous. We're moving forward on the development path towards getting an alpha network release out the door, but we need these specs reviewed for flaws that we've missed. Of course, we also need lots of other things, from coders to documenters to QA to network simulators to CS people, but it is your eyeballs that we're calling out for today. What we have ready for review: - Invisible Internet Network Protocol (I2NP) spec[1], describing how network "routers" operate and what messages they send to other routers - Common Data Structures spec[2], describing the serialization of objects described in other specs, as well as the encryption algorithms used. - Invisible Internet Client Protocol (I2CP) spec[3], describing a simple local client protocol for making use of the network. - Polling HTTP Transport spec[4], an example transport protocol for use with I2NP to allow actual communication between routers, regardless of firewall, NAT, or HTTP proxy. We also have the 0.2 release of a software development kit (I2P SDK)[5], which includes everything necessary to design, develop, and test applications to run over the network, as well as all of the above specs. It includes a Java client API implementing I2CP, a sample application (ATalk, a one to one chat app that supports file transfer), a Java router, and a Python router. There are also C and Python client API implementations of I2CP are on the way. These router are "local only" - meaning they don't talk to other routers. This can be used in the same way we can build normal networked applications - by running the server on the local machine and pointing the applications at it. We've been keeping this quiet because its too easy to hype up a vaporware product and we wanted to wait until there was something worth reading about before saying anything. So please read these specs and send in your comments - either to [EMAIL PROTECTED] or to the iip-dev mailing list[6]. Perhaps even jump on that list if you want to discuss things (archives are linked to from the web page), browse the wiki[7], or join us on IIP for development meetings - every tuesday at 9P GMT in #iip- dev (archives[8] since meeting 48 are pretty much I2P specific). Thanks for your time, and we look forward to any responses. - The InvisibleNet team [1] http://www.invisiblenet.net/i2p/I2NP_spec.pdf [2] http://www.invisiblenet.net/i2p/datastructures.pdf [3] http://www.invisiblenet.net/i2p/I2CP_spec.pdf [4] http://www.invisiblenet.net/i2p/polling_http_transport.pdf [5] http://www.invisiblenet.net/i2p/I2P_SDK.zip [6] http://www.invisiblenet.net/iip/devMailinglist.php [7] http://wiki.invisiblenet.net/iip-wiki?I2P [8] http://