To be most helpful to us, and hence to do the most to improve Yenta's security, please read all of the topics below. They cover:

• How to comment on the code.
• What's in it for you.
• What counts as a flaw.

Since it is expected that most possible flaws will concern some well-defined area of the source code, you should remark on it at the appropriate point in the source tree that Yvette gives you. If you think you have found something particularly serious, you may want to send mail to bug-yenta@media.mit.edu telling us what you found. Please see also our description of what counts as a flaw.

What incentives we have for you

• Community good. This is worth doing for its own sake, because you are helping everyone who uses Yenta to be able to use a system that will not inadvertently expose personal information, will not crash, and will be useful to its users.
• Public recognition. All comments about Yenta that have been given to Yvette are available to everyone to read. Particularly insightful comments may also be mentioned in various acknowledgments when papers about Yenta are published.
• Goodies. If you are the first to report a particularly serious security problem in Yenta, we'll give you something. If you're local, this might be dinner. If you're not local, it might be something else appropriate. If you care strongly about getting something, then please comment in Yvette (if there is a particular area of the code that is affected), and remember to send us mail. Please note that our judgment of what counts as "serious" is absolutely at our discretion. But don't worry---we'll be fair. It is quite probable that there are things missing from the description below (perhaps we forgot one of the cases that don't count in the threat model description); this doesn't mean we owe you dinner if you find something we don't think it a major flaw, but which we didn't mention. On the other hand, we'd still like to hear about it---if nothing else, to correct our description.

What counts as a flaw?

Security bugs versus other bugs

• We're interested in all bugs... so please, if you spot something in the source which is a bug in functionality, even if it does not have security implications, please comment about it in the source and also send us mail at bug-yenta@media.mit.edu. If you trip over a bug while using Yenta, but don't know where it is in the source, send us mail and at least let us know.
• ...but we're most interested here in security bugs. Not only are undetected security bugs dangerous to users, but they are likely to go unreported unless someone actively looks for them. After all, a bug in functionality, such as Yenta crashing, or doing the wrong thing with a command, is likely to be noticed by the user who experiences it, but a security bug could be totally silent and yet deprive all users of their privacy.

What sort of attacks are we talking about?

• Things which don't count.
  • Denial of service doesn't count. In other words, if someone can arrange to make your Yenta do nothing, either by overloading it, running it out of resources, or attacking the connection of its machine to the net, that's outside of the scope of what Yenta is designed to survive. Of course, if you see a simple way to prevent a denial of service which is specific to Yenta, please let us know.
  • Careless users don't count. Users who deliberately choose poor passphrases will compromise their own security. Yenta can't stop them. Similarly, even though Yenta takes care to arrange a very strong SSL connection between the user's browser and Yenta itself, if the user is running their web browser with an insecure connection between their keyboard and their web browser, Yenta cannot possibly know this, and cannot prevent it from occurring. This can easily happen if the user is using X---with the keyboard and screen on one machine, and Yenta running another---and is not using SSH or some similar protocol between the two machines. Similarly, if the user is running a crippled browser that supports only 40-bit session keys, Yenta is willing to talk to the browser, but this connection is only secure against attackers without many resources.
  • Attacks by root on the same machine don't count. A superuser on someone's workstation can read any bit of memory, can substitute compromised versions of binaries for formerly good ones, can install trojan horses that capture every keystroke the user types before it gets to any application, and so forth. Yenta cannot hope to avoid such attacks. Note in particular that Yenta is more vulnerable to a memory-sniffing attack than programs like PGP, because Yenta must remember the user's private key at all times---PGP need only remember it for the instant that the session key is being encrypted. And any attack that compromises the binary---whether on the local workstation, or by altering NFS data if the binary is fetched over the network---also cannot be countered.
  • Byzantine failures don't count. In other words, if you surrounded some innocent victim's machines with only machines running bogus, compromised versions of Yenta that are all under your control, you could certainly figure out what the user is interested in, and probably do a lot worse damage as well. Yenta explicitly assumes that all the rest of the Yentas on the net are not evil. One or two is okay, but a vast majority is not.
  • Savant index files don't count. Yenta stores its crunched, vectorized information about your mail in a binary but unencrypted form on disk, in your ~/.Yenta directory. Although the directory is read-protected against all but its owner, this is not secure against an attacker who can read the filesystem. Since this information originally came from plaintext files which are also in the filesystem, it is assumed that this approach does not compromise the user's privacy any more than it already was. Note that Yenta's other saved state, such as the user's private key, his stored conversations, and so forth, are encrypted and never appear on disk in the clear, even for a moment.
  • Attacks on the maintainers' machines don't count. Even though the distributions are cryptographically signed, and even though the source code is available via Yvette, there is certainly the potential for corrupting the actual code being distributed, by attacking the machines upon which Yenta is developed. While it would be possible to secure these machines better, doing so gets in the way of getting work done, and Yenta is a research project. So you are not allowed to attack the actual source---or our machines!---and then claim a victory. Just don't.
  • Traffic analysis doesn't count---yet. The current version of Yenta uses point-to-point IP connections when passing a message from one Yenta to another. Later releases will employ a broadcast-flood algorithm, either by default or on request, to make it harder to tell where the real endpoints are of a communication. This makes it more difficult for an attacker who cannot monitor every link in real time to know which pairs of Yentas are exchanging a lot of traffic (and hence which may have users who are interested in the same things).
• Things which do count.
  • Problems in Yenta's cryptography. This could be insecure encryption modes, vulnerabilities in the protocols used between Yentas or in the way that permanent state is stored on disk, and so forth.
  • User confusion that leads to exposure. If Yenta does something that causes a user to be a confused and inadvertently reveal something that he did not wish to, that is a bug. But this must be Yenta's doing---not a con game perpetrated by another user, for example.
  • Failures of anonymity. Yenta tries to keep the connection between an individual user's true identity and his Yenta identity unknown, unless the user deliberately divulges that information. If there are easy ways to defeat this, we need to know. However, see the note about traffic analysis not counting, so far---a later release will fix this.
  • Spoofing. If one user can masquerade as another, complete with valid-looking attestations which are fraudulent, this is certainly a bug.
  • Missing items from the description on this page. We may be missing examples, either in the listing above of threats which Yenta is just not designed to handle, or in this listing of possible places to look for problems. If so, please let us know, so we can update the list. This helps two sets of people: Yenta's users, who get a more accurate picture of what Yenta can and cannot do, and Yenta's reviewers, who won't waste their time investigating a vulnerability which we consider to be outside of Yenta's scope.

Last modified: Wed Mar 24 21:42:09 EST 1999