Security

LAS VEGAS--Two researchers have separately uncovered flaws in the way domain names are verified on the Internet that could allow attackers to impersonate a site and steal information from unsuspecting Web surfers.

Moxie Marlinspike

(Credit: Elinor Mills/CNET News)

Dan Kaminsky, who discovered a serious flaw in the Domain Name System (DNS) last year, and Moxie Marlinspike gave presentations at the Black Hat security conference on Wednesday about how someone could acquire certificates for domains they don't own and thus trick people into visiting those illegitimate sites or inadvertently sharing information.

Marlinspike, an independent researcher, said a flaw in the way browsers and mail clients implement Secure Sockets Layer (SSL) allows for so-called man-in-the-middle attacks in which an attacker could trick browsers into presenting the site as legitimate.

The attacker can ensure continued interception of a victim's data, as well, by intercepting the Firefox auto update requests, which depend on SSL, he said in an interview. Marlinspike wrote a software tool to enable this, working with a modified version of Firefox "so that anytime you submit something to a site it sends me a copy," he said.

"The diabolical thing is this is a vulnerability, but the update mechanisms themselves cannot be trusted," Marlinspike added.

Chrome and Internet Explorer are also vulnerable to such an attack, but it would be harder on IE since that browser employs an additional step of using code signing certificates, he said. Marlinspike said he had not analyzed Chrome enough to see how serious of an issue it would be.

"They all need to change their implementation of SSL," he said, adding that he has been working with Mozilla.

Marlinspike said he will release his tool as soon as a Firefox patch is out, possibly in the next week or so.

And until Mozilla changes the way its auto update system handles SSL he suggested users turn off the auto update function on Firefox.

Dan Kaminsky

(Credit: Elinor Mills/CNET News)

Meanwhile, Kaminsky, director of penetration testing for IOActive, said he was able to trick a Certificate Authority into providing a certificate verifying authenticity for a domain that belongs to someone else. He tested his attack using a fake Defcon.org domain and was able to use a naming trick to convince the Certification Authority running SSL to not contact the domain owner to verify the validity of the request.

Kaminsky was able to do this by exploiting a vulnerability in X.509, the protocol for generating SSL connections.

"If a Certificate Authority and a browser disagree about a name being validated, an attacker could impersonate any domain name," he said in an interview following a press conference after his talk.

The vulnerability undermines the system of trust that the Web relies on for e-commerce and other activities, according to Kaminsky. By uncovering it, a crisis may have been averted, he said.

"This is our best technology for doing authentication and it failed," he said. "We'll fix it, but it's another sign that we need to revisit how we do the basics; how we do authentication on the Internet."

Kaminsky said extended certificate validation--to prove the identity of the organization behind a Web site--should be used for any site at which phishing is a threat. He also suggested that much of the problem could be solved with the use of DNSSEC, extensions to DNS that provide additional information to servers about the data communication and its origin.

He said he was able to use several different types of attacks to exploit the X.509 vulnerability that has been resolved and one involving the MD2 hash algorithm standard to sign certificates that is being phased out.

VeriSign no longer uses the MD2 standard, having transitioned to the SHA-1 algorithm on May 17, said Tim Callan, a vice president of product marketing at the domain registrar.

"We're completely behind any efforts to improve X.509" and DNSSEC, he said.

Updated on July 30 at 2:27 p.m. PDT: Marlinspike said the issue he presented has been fixed in Firefox 3.5 and that Mozilla is working on packporting the patch into the 3.0.x series now.

Meanwhile, a Mozilla representative said: "We strongly disagree with the suggestion that users turn off security updates. Regular security updates are one of the best protections users have against newly discovered vulnerabilities in any piece of software. They are the path by which problems like the ones Moxie identified get quickly remedied before they can be exploited."

At the RSA Conference last month in San Francisco, Taher Elgamal was conferred the Lifetime Achievement Award--only the third recipient of the award since its inception in 2004.

Taher Elgamals

The chief security officer of Axway has more than 25 years of experience in the security industry, starting out as a cryptographic expert. Egypt-born Elgamal has been credited as an inventor of SSL (Secure Sockets Layer), having joined Netscape in early 1995 to release the protocol, which later came under the oversight of the Internet Engineering Task Force.

In a phone interview with ZDNet Asia, Elgamal shares his concern that "SSL gets blamed for all the stuff" and explains what needs to be done to boost security on the Internet.

Q: We've heard about SSL man-in-the-middle attacks and the ability to intercept session cookies. Has the sophistication of attacks grown too rapidly for Internet security standards?
Elgamal: First, it's important to identify the pieces of the solution, and who's responsible for which pieces. SSL is the protocol between two points, usually browser and server. The weaknesses in the system usually are due to the browser, not the protocol. The protocol says (servers) would identify themselves to each other, and it's up to both sites to accept whether this is a good site or not. Unfortunately, the browser trust model...allows end users to accept things without actually understanding what they are accepting, unrelated to the protocol as it stands.

Man-in-the-middle attacks are not actually part of SSL; (they) are network design issues where somebody designs the network and puts in a proxy that makes the browser believe that the server is a different place and then substitutes a different certificate to both sides.

That's a trust issue, actually, and not a man-in-the-middle attack. Because the trust model and the browser are not designed correctly, you can convince the browser that this is the right certificate and convince the server something else, and then look like you actually broke the protocol. You actually did not break the protocol; you terminated the protocol at the wrong point because the browser trust model is broken.

I think all of these problems have to do with browser design rather than security or protocol. It's interesting because SSL gets blamed for all the stuff, but (they are) actually not even related to SSL. (The issue is) which certificate the browser should trust or should not trust.

The cookie (incident) has nothing to do with SSL. The cookie is something that is associated with an HTTP session--it's actually a Web standard. The cookie idea was invented to make sure that you can have a long session on the Web, before SSL (came into the picture).

It also turns out that the secure sessions also use same cookie design to maintain sessions. Some cookies are well-designed, and people cannot hijack the sessions. Some cookies are really badly designed. This has nothing to do with the SSL protocol at all.

I think we need to send Web site and software developers to cookie design school so that they can design cookies correctly. We know very well (which) cookies are good and which cookies are bad, and there are ways to design cookies so that people cannot actually hijack the session.

A security researcher has also pointed out that users still log on to sites that have expired SSL certificates, and that poses a problem. Accepting the expired certificate is a browser problem.
We had this fight early on in the Internet days: What do we tell the user to do when there is an expired certificate? Security professionals always struggle with the general public because usability always wins. When you get an expired certificate, the site owner or organization would always prefer to allow the user to do things rather than disallow. This is just an unfortunate fact.

Unrelated to what the protocol really is, or whether something is good or bad, the browser allows the end user to say "Yes, I want to accept this anyway." That, in my opinion as a security professional, is the wrong thing to do. I think this is something that the browser makers need to consider better. Of course, (Microsoft Internet Explorer has) 80 percent (share) of the browsers, and then we have (Mozilla) Firefox and Apple (Safari). Again, there's no security issue to deal with, as far as the encryption or SSL protocol itself--I think the (browser makers) need to convey these messages better to the end users.

But I know for a fact that Microsoft would never turn off a site because the certificate has expired. Because maybe it expired, and (the owners) are working on getting an extension...you turn the site off, and they lose half a million dollars. There is a commercial issue here that is just hard to deal with.

From a technical standpoint, (however), it should be the case that the certificate would warn the Web server owner that (it will) expire in seven days (and to) go and get the certificate renewed. There should be a process to do that better, but the automation hasn't happened yet.

What is the solution then? How can browser makers keep users and protect them?
There needs to be another control in the browser (in which), for important sites--banking or payment--it refuses to let the users do something, if the certificate is not valid. For simple sites, maybe you give the users the control to continue. We don't do that differentiation these days--there is no difference between an important site...and a site (where you are) looking for information.

Microsoft (and the other browser makers have) the notion of security zones--there is a differentiation between different kinds of sites--but it is really very hard to do from a user standpoint. Most end users don't understand what a security zone means. End users are not very security-savvy, unfortunately. When users walk into a bank branch, they assume that it's trusted. And they make the same assumption when they go to the online bank branch.

There are things that the ecosystem needs to do to help the users not be in a situation where they are compromised. I'm sure there will be solutions that come up...because the Internet itself needs to fix that.

With the development in browser technology, we haven't achieved such a stage yet?
Because usability always wins. Being in security for such a long time, I knew that it was going to be a problem. I had that discussion inside of Netscape for a while, and I had that discussion with Microsoft people--we had that discussion at various times for a very long time. What do you do if the certificate is expired? What do you do if the certificate is wrong? (The latter is) actually a more (serious) problem.

The browser does certain checks when the certificate comes in--(it) will check (whether) the name of the certificate and the URL matches or not. The checks are not enough, as there are certain cases where somebody can fool the browser into thinking that this is the right URL. You can design sessions where that check is very tight--where the connection will not happen--but the general browser basically allows the user to trust things. And the user doesn't understand what that means, of course, so the user will always say yes.

The current security issues are finally bringing up things that we knew about in the security world a long time ago...because (now) the size of the economy of the Internet is growing. The industry needs to deal with this in a better way.

SSL was invented over a decade ago. How different do you think it would be if it had been invented in the current security landscape?
Actually, I honestly do not think it would be different. If 15 years ago, we knew what it would look like (today), we would change the design of the client--the browser. But the protocol itself is actually quite good. The protocol allows the client and the server to agree on which algorithms should be used in a particular session, and it's intentionally done this way.

Twenty years from now, we will find out that different protocols are no longer considered secure, and we should not use them, but we cannot design that protocol to use only a particular set of security algorithms, because I would not know, really, 20 years from now, what would be secure and what would not be secure. Fifteen years ago, certain algorithms were considered good, and we used them in the early Internet days, and then a few years later, we found out that (they) were not secure and should not be used.

All security protocols allow the use of multiple algorithms because we have to (design) the protocol (for use) over a long period of time. The (SSL) protocol is pretty solid...changes in the protocol have been minimum (over the years).

What are you most dissatisfied about in the current security landscape?
The biggest issue with Internet security today is that there are databases with a lot of important info that are available from the Internet, from the outside. Designing secure networks has not been progressed enough. Most of the security problems that you see today (occur) because hackers or insiders are able to access information that they are not authorized to get access to. This is the reality of what today's security environment looks like.

There are attempts (at control)--for example, Visa and MasterCard will force merchants to go through the PCI DSS (Payment Card Industry Data Security Standards) regulations. These are useful--they force Web site owners to go through particular security testing and design to make the site better. There needs to be a more collaborative effort that, whenever a site looks like it has a security deficiency, the Internet tries to help. Whether that's from governments, partners, industry, or associations--it almost doesn't matter--I think a collaborative effort is really important. That's really the only way to fix a large network like the Internet from a security standpoint.

Vivian Yeo of ZDNet Asia reported from Singapore.

The prototype SSL crack in action: It's a supposedly secure Web site (note "https:" in the menu bar). But the SSL certificate is issued by MD5 Collisions Inc.

(Credit: Jonathan Stray)

By Jonathan Stray

Updated at 3:30 p.m. PST with Microsoft comment, at 1:50 p.m. PST with VeriSign comment, at 10 a.m. PST with comment from cryptography expert Paul Kocher, and at 9 a.m. PST to reflect that presentation has taken place and include comment from cryptography expert Bruce Schneier.

BERLIN--A key piece of Internet technology that banks, e-commerce sites, and financial institutions rely on to keep transactions safe suffers from a serious security vulnerability, an international team of researchers announced on Tuesday.

They demonstrated how to forge security certificates used by secure Web sites, a process that would allow a sufficiently sophisticated criminal to fool the built-in verification methods used by all modern Web browsers--without the user being alerted that anything was amiss.

The problem is unlikely to affect most Internet users in the near future because taking advantage of the vulnerability requires discovering some techniques that are not expected to be made public as well as overcoming engineering hurdles: performing the initial digital forgery consumed approximately two weeks of computing time on a cluster of 200 PlayStation 3 consoles. In addition, a criminal needs to find a way to reroute traffic from a legitimate Web site to his own, perhaps through techniques that have become well-known in the last few years.

Yet if one group can do it today, others eventually will. "We have a proof-of-concept that allows us to impersonate any supposedly secure Web site on the Internet," said David Molnar, a doctoral student in computer science at the University of California at Berkeley.

Molnar and six other researchers presented their findings during an afternoon session of the Chaos Computer Club's annual conference here on Tuesday. Other team members include Jacob Appelbaum and Alexander Sotirov.

Their work has focused on finding vulnerabilities in a technology known as Secure Sockets Layer, or SSL, which was designed to provide Internet users with two guarantees: first, that the Web site they're connecting to isn't being spoofed, and second, that the connection is encrypted and is proof against eavesdropping. SSL is used whenever a user navigates to an address beginning with "https://". SSL certificates essentially stand for the claim that, for instance, etrade.com actually belongs to E-Trade Inc., and is not being operated by a thief hoping to steal account passwords.

Most browsers indicate that SSL is active by displaying a small padlock icon. An attack using a forged authentication certificate--which is what the researchers say they have done--is insidious because the browser can't detect it and the padlock icon would still appear.

Talk announcement on the CCC schedule in Berlin.

(Credit: Jonathan Stray)

Unlike most security issues, this problem cannot be fixed with a simple software update. "The bug is not in anyone's software," Sotirov said. "It's not the browser that's at fault. The browser does exactly what it's supposed to do... The problem is that what it's supposed to do is wrong."

The attack exploits a mathematical vulnerability in the MD5 algorithm, one of the standard cryptographic functions used to check that SSL certificates (and thus the corresponding Web sites) are valid. This function has been publicly known to be weak since 2004, but until now no one had figured out how to turn this theoretical weakness into a practical attack.

An SSL certificate is a small file that ties a real-world corporate identity to a Web site address and a corresponding public encryption key. This is presented to a private certificate authority firm, which is supposed to verify the link between identity and domain name and then cryptographically "sign" the certificate to vouch for it.

The problem arises when someone else is able to forge the same signature.

VeriSign, which operates the largest certificate authority in the world, learned of the vulnerability early on Tuesday and acted quickly to close the hole in its certificates, according to Tim Callan, vice president of product marketing at the company.

"We went into our systems and removed the MD5 algorith and replaced it with SHA-1 (Secure Hashing Algorith)," he said. "You can not get an SSL certificate from VeriSign now that is subject to this attack." More information from VeriSign is available on Callan's SSL blog.

VeriSign was in the process of phasing out MD5 before the issue came up and is now on track to have it entirely out of commission in January, Callan said. "On balance, public key infrastructure works extraordinarily well," he said when asked if the vulnerability illustrated a need to change the trust model.

Microsoft, while noting that the issue wasn't a vulnerability with one of its products, tried to downplay the threat to users in a security advisory Monday.

"This new disclosure does not increase risk to customers significantly, as the researchers have not published the cryptographic background to the attack, and the attack is not repeatable without this information," the advisory said.

A 1991-era protocol, but modern problems
When MIT professor Ron Rivest developed MD5 in 1991, it was considered sufficiently secure. But starting in 1996, a series of increasingly serious flaws started calling the continued viability of MD5 into question.

As CNET News reported in 2004, flaws discovered at that time "could eventually make it easier for intruders to insert undetectable back doors into computer code or to forge an electronic signature--unless a different, more secure algorithm is used." Then, in 2007, Arjen Lenstra of Bell Laboratories Switzerland, with Marc Stevens and Benne de Weger of TU Eindhoven, demonstrated a technique to construct two new certificates with different content but the same fingerprint.

Although security researchers had been worrying, and recommending that other alternatives be considered, nobody had yet demonstrated how to exploit this theoretical flaw in a practical attack.

The researchers who attacked SSL authentication. Left to right: David Molnar, Alexander Sotirov, Marc Stevens, Arjen Lenstra, Jacob Appelbaum. Not pictured: Benne de Weger and Dag Arne Osvik.

(Credit: Jonathan Stray)

Molnar, Appelbaum, and Sotirov joined forces with the European MD5 research team in mid-2008, along with Swiss cryptographer Dag Arne Osvik. They realized that the co-construction technique could be used to simultaneously generate one normal SSL certificate and one forged certificate, which could be used to sign and vouch for any other. They purchased a signature for the legitimate certificate from an established company that was still using MD5 for signing, and then applied the legitimate signature to the forged certificate. Because the legitimate and forged certificates had the same MD5 value, the legitimate signature also marked the forged one as acceptable.

The process amounted to transferring a photograph from a real ID to a fake by carefully matching the holographic security markers.

The rogue certificate can then be used to sign any other certificate of the attacker's choosing--such as one which assures Web browsers that a malicious phishing site is actually the legitimate etrade.com or bankofamerica.com.

After three unsuccessful attempts, each of which required approximately three days of compute time on a cluster of 200 PlayStation 3s, the researchers obtained a forged certificate authority in early November, at which time they notified browser developers and certificate authorities, or CAs, about the security flaw. Molnar estimates that the same processing time could be purchased from Amazon for about $1,500.

The team decided to disclose the vulnerability at the Berlin conference in hopes that the news will encourage everyone involved to fix the problem quickly. "The main message here is to stop issuing MD5 certificates, now," said Molnar. He believes that MD5 is so weak it no longer should be used for any applications: "More secure, freely available alternatives exist." (In November 2005, the U.S. government announced plans to find successors to MD5 and SHA-1, an official federal standard with its own problems. The new federal standard will be called SHA-3.)

By itself, the MD5-certificate-forging vulnerability wouldn't be too worrisome. That's because it relies on criminals being able to capture Web traffic to display a fraudulent Web site. But setting up a fake wireless access point to lure unsuspecting neighbors or business travelers is trivial, and a program released earlier this year to attack the domain name system (DNS) provides another way to direct Internet traffic for malicious purposes.

While only a few CAs currently sign certificates with MD5, Appelbaum estimates that 30 percent to 35 percent of all SSL certificates currently in use have an MD5 signature somewhere in their authentication chain. "The CAs should contact every customer that currently uses an MD5-signed certificate and offer a free replacement."

In an interview on Tuesday morning, cryptography expert Bruce Schneier praised the research but downplayed the real-world consequences of the findings.

"SSL protects data in transit but the problem isn't eavesdropping on the transmission. Someone can steal the credit card on some server somewhere. The real risk is data in storage. SSL protects against the wrong problem," he said.

"This is good work, great cryptography. I love the research, but this doesn't matter a whit," Schneier added. "There are half a dozen ways to forge certificates and nobody checks them anyway."

Paul Kocher, president of Cryptography Research and an architect of the SSL 3.0 protocol, said the exploit highlights the need for a new universal hash function "that everyone is comfortable with."

"The paper is not a surprise, but at the same time it's the crispest demonstration for why it's necessary to remove this broken algorithm everywhere it is being used," he said, before adding "there are bigger things to worry about, like browser bugs and operating security bugs."

The researchers have created a Web site signed with a forged certificate which can be viewed here. The forged certificate was backdated so that it could not be used maliciously even if stolen from researchers, so you have to reset your system clock to August 2004 to view it.

Even though their work may be controversial, the researchers view their efforts as fundamental to creating a more secure Internet. "I don't want to be hit by this type of attack either," Sotirov said. "I use the Internet too."

The author is a freelance contributor to CNET News and is not an employee of CBS Interactive. His Web site can be found at jonathanstray.com.

(Credit: AOTA)

Extended certificate validation for Web sites has boosted online confidence in 2008, according to a statement released Thursday by the Authentication and Online Trust Alliance (AOTA).

This could help online consumers looking for sites to trust on Cyber Monday, the first shopping Monday after Thanksgiving when online purchases are at their peak.

Sites with Extended Validation Certificates (EV) added to Secure Socket Layers (SSL) encryption display their URLs in a green bar in the address field of compatible browsers. This signals to the user that there is increased scrutiny of the Web site. In Firefox 3, a user clicks the green bar to see additional certificate information. Same with Internet Explorer.

The idea here is that a trusted third-party certificate authority will vouch for the Web site beyond the minimal "domain validation only" in place today with traditional SSL certificates. EV SSL sites must establish a legal identity and a physical presence for the site owner, establish that the owner has exclusive control of the site, and confirm the identity of the owner.

A study last year by Tech Ed Research found that participants were more likely to click on a link with a green EV SSL link than sites with the paddle lock icon traditionally associated with SSL.

The AOTA also announced that starting in January 2009, the US Internal Revenue Service will require all authorized IRS e-file providers participating in online filing of individual income tax returns to have a valid and current EV SSL certificate. The IRS is also requiring e-file sites to publish privacy information and safeguard policies, to obtain a privacy seal signifying an IRS-approved service, and to report all security and privacy breaches directly to the IRS.

PayPal and eBay have both been early supporters of EV SSL. In April, PayPal announced it would block users who did not use an EV SSL-compatible browser on its site. In May, a researcher found a vulnerability with EV SSL that affected PayPal and other sites, a flaw that was quickly remedied.

Browsers supporting EV SSL include Microsoft's Internet Explorer 7, Internet Explorer 8, Safari 3.2, Firefox 3, Opera 9.5, and Google Chrome.

A security researcher has been in discussions with Google on an exploit he plans to release that would allow a hacker to easily intercept someone's communications with supposedly secure Web sites over an unsecured Wi-Fi network, but other sites, like Facebook, Yahoo Mail, and Hotmail, remain vulnerable.

Mike Perry, a reverse engineer and developer at Riverbed Technology, says he announced on the BugTraq e-mail list a year ago a common flaw with the way Web sites implement the SSL (Secure Sockets Layer) protocol that is designed to protect people's data when they surf the Web. Typically, they only use SSL for encrypting communications during the log-in stage, he says.

There are actually two problems with SSL implementations. The first issue is that many sites do not use SSL past the log-in page, and thus expose their users' cookies to theft via sniffing by someone else on the network. A tool exploiting this flaw was released last year by Robert Graham of Errata Security, at the same time Perry announced his flaw.

Session cookies--which identify the machine as having used the correct username and password--have two modes: "secure" or "insecure." The vulnerability disclosed by Perry targets sites that attempt to use SSL, but do not flag their cookies as "secure." This flaw allows the cookies to be obtained by an attacker with access to the local network, and use them to pose as the Web surfer and access that person's e-mail accounts, bank accounts and other services, even if those users try to use https, Perry says.

Nothing was done to fix the SSL problems until a month ago when Google announced that people can set Gmail to automatically encrypt communications between a browser and Gmail servers by default, instead of having to type in https://mail.google.com, Perry says.

However, accessing the site via https://mail.google.com does not automatically preserve the "secure" session and the cookies can still be stolen, Perry says.

He says he has contacted security representatives at Hotmail, Yahoo Mail, and Facebook about the fact that their sites remain vulnerable to a so-called "man-in-the-middle attack" in which someone on the same Wi-Fi network hijacks the session cookies that are transmitted between a user's browser and a Web site. As of Friday afternoon, he hadn't heard back from them, he said.

Representatives at Microsoft and Yahoo said they were working on getting comment, while representatives at Facebook did not respond to e-mails or a phone message from CNET News seeking comment.

Amazon encrypts communications related to payment but not purchase history and recommendations, according to Perry. An Amazon spokeswoman said the company does not comment on security measures.

Perry had planned to release his exploit tool, which automates the hijacking of the cookies, on Sunday--which will be two weeks after he gave a talk about the vulnerabilities at the Defcon hacker conference in Las Vegas. There is already another exploit out there that targets the same problem, he says.

"The motivation is to raise awareness and try and encourage these sites to adopt SSL and do it properly," he said in an interview on Friday.

Delaying release of the tool
But, Perry said he has decided to delay releasing the tool for an undetermined time after talking to Google.

Google is the only one of the major Web sites to offer users the option of setting auto-encryption for all the communications with the site and not just the log-in page, as well as to properly set the "secure" property of its cookies, Perry says.

Google says it is rolling out the option not just for consumer Gmail users, but also for Google Apps enterprise users and has launched it for the premier edition of Google Apps so that communications with Google Docs, Calendar, and other included Google sites are encrypted.

It is also very possible that Google will make it so that the "always encrypt" mode is automatically enabled when people first log in via "https://gmail.google.com" instead of having to go into settings and enable it manually, Perry says.

"Just about everyone but Google simply does not want to spend the money to invest in the security of their users, and will continue to ignore this issue, just as they have for the past year," Perry wrote in an e-mail.

The vulnerability affects people using unsecured wireless networks and would require the attacker to be using the same network at the same time. However, it could affect people on other types of networks if it were to be combined with other attacks, such as ones taking advantage of a recently discovered domain name system hijacking exploit that any Web surfer could be exposed to, or more elaborate attacks involving modified DSL or cable modems, which were also discussed at Defcon, Perry says.

Perry goes into more details about the problems and his plans on his blog.

Google on Tuesday announced Keyczar, an open-source project to help developers select and use safe cryptography in their applications.

Built on OpenSSL, PyCrypto, and the Java JCE libraries, Keyczar supports authentication and encryption with both symmetric and asymmetric keys. It simplifies some of the details by choosing safe defaults and automatically tagging outputs with key version information. Keyczar also provides a simple interface.

The project provides developers with a simple API, key rotation and versioning, and safe default algorithms, modes, and key lengths.

A "nongoals" page proclaims what Keyczar is not. For example, Keyczar is not designed to work with legacy crypto output formats.

The project was developed as part of the Google Security Team by Steve Weis of Google and Arkajit Dey of MIT, with help from others.