- tor-dev - lists.torproject.org

Should Whonix recommend against using multiple workstations behind the same Tor-Gateway in all situations?
by Patrick Schleizer 03 Dec '16

03 Dec '16

TLDR: Should Whonix recommend against using multiple workstations behind the same Tor-Gateway in all situations? Long: We at Whonix are currently wondering if we should recommend against using multiple workstations behind the same Tor-Gateway. It's not something we are looking forward to do since it severely decrease usability and may not actually increase anonymity. That's why we're asking. (Usability would decrease because: multiple-gw multiple-ws mapped 1:1 is more difficult to explain and set up than single-gw multiple-ws; more VMs to [maybe configure for bridges multiple and] upgrade multiple times; more RAM usage; taking more disk space; setup taking more time; and perhaps more.) Whonix does use a control port filter. By default, only the most essential Tor control commands are whitelisted such as authenticate, quit, signal newnym, getinfo net/listeners/socks, getinfo status/circuit-established and protocolinfo to make Tor Brower work without any errors. teor recently wrote: > We don't even recommend running a SOCKS client and a hidden service on the same instance. Okay, makes sense. We'll update our documentation to reflect that advice. Not too long ago Tor got some improvements: * The number of Tor entry guards was reduced from 3 to 1. * And guards are kept for longer. (Longer guard cycling period.) If we encourage multiple Tor-Gateways, we subvert these improvements. * a) I think guard related attacks are much more serious since they lead to deanonymization, which speaks for single-gw multiple-ws setups. * b) Drawback is that caching issues in single-gw multiple-ws setups can lead to linking multiple workstations together. I think a) is more serious than b). So for now I guess single-gw multiple-ws is still better than multiple-gw multiple-ws mapped 1:1. Perhaps we could equate the following two? single-gw multiple-ws * perhaps some discovery attacks even with a filter multiple-gw multiple-ws mapped 1:1 * Even VM-level isolation is not proof against some attacks What is worse...? * a) single gateway sharing vs * b) using multiple-gw multiple-ws mapped 1:1 and thereby subverting number and duration of entry guards Even in a multiple-gw multiple-ws mapped 1:1 setup, would these multiple instances of Tor be really isolated from each other? Doesn't this presuppose a perfectly contained VM? By perfect I mean to limit the system resources any workstation / gateway can take. We are not there yet to limit CPU load / network load / I/O (hdd) load / graphic calculation load (/ RAM load?). (Because [not all] virtualizers support that [easily]. [...]) (And one compromised workstation then could stress system resources which would then make the anonymity of another gateway suffer.) So far we can see four options for implementation / user recommendation: * single-gw multiple-ws * multiple-gw multiple-ws mapped 1:1 ** For multiple-gw multiple-ws mapped 1:1 setups it might be theoretically an option to have them manually use the same Tor entry guard? That also does not seem too great, since Tor guard selection then would be manual? (Cloning a gateway not a reliable solution to keep entry guards, since Tor will change them after some time and then they will differ.) * single-gw with multiple-ws while recommending against running multiple workstations for activities of different trust levels / pseudonyms at the same time * Yet another option might be to run multiple Tor instances on the same gateway. Tor's systemd service supports that. (Would use separate Tor data dirs, thereby different Tor entry guards.) ** If you recommend we should use multiple Tor instances, should we try to configure them to use the same Tor entry guard or bridge? A list with all pros and cons for either option based on what we learned recently on this list has been created: https://www.whonix.org/wiki/Dev/Multiple_Whonix-Workstations

1 0

Re: [tor-dev] protecting users from known relay groups with end-to-end correlation capabilities
by teor 03 Dec '16

03 Dec '16

> On 3 Dec. 2016, at 11:48, Bungeetaco <bungeetaco(a)protonmail.com> wrote: > > Hi there, I have added the following line to the torrc of all my tor nodes and reloaded the daemons: > > MyFamily 629FE436746E0AACDFC93D2DA70B5E269F7ADC79,DA5B2F8C1C7E901374C8A200277A3C927176BF0F,A894ABB7B1A990B5F10BA9CBE668E27BE6C7FEDF > > Been running my two exit nodes for a year now with good management, and I haven't got raided so far so I guess I'm doing this the right way. Glad you guys are reaching out about issues that are easily fixable by operators instead of just blacklisting nodes at random. > If something else needs my attention, feel free to let me know. I love this project ^w^/. Thanks for fixing this so quickly. It should be distributed to all clients within the next few hours. You can check it worked using the "Family Members" on: https://atlas.torproject.org/#details/629FE436746E0AACDFC93D2DA70B5E269F7AD… It will take at least 15 minutes to appear on atlas, and maybe even 75 minutes, if your relays sent updated descriptors after 50 minutes past the hour. Tim > >> -------- Original Message -------- >> Subject: Re: [tor-dev] protecting users from known relay groups with end-to-end correlation capabilities >> Local Time: December 2, 2016 7:15 PM >> UTC Time: December 3, 2016 12:15 AM >> From: teor2345(a)gmail.com >> To: Bungeetaco <bungeetaco(a)protonmail.com> >> tor-dev(a)lists.torproject.org <tor-dev(a)lists.torproject.org> >> >> >> > On 3 Dec. 2016, at 11:11, Bungeetaco <bungeetaco(a)protonmail.com> wrote: >> > >> > >> > >> > >> > >> > >> > Hi there! I would be more than glad to apply the appropriate modifications to my relay if it means increased security for the users ;D. I care about the security and privacy of the people who pass through my relays, and I take pride in supporting a project which empowers people so much. I decided to run a Middle and 2 exit nodes because I wanted to provide diversified support to the Tor network, I did not intend to jeopardize anyone's privacy or security. >> > >> > Would I need to add the fingerprints of my others nodes in my torrc configuration files? If so, please let me know how to accomplish this and I'll push an update on all my servers ASAP. The last thing I want is create a security risk for the users and/or distrust. >> > >> > Thanks for letting me know about this btw! >> >> Hi Bungeetaco, >> >> On each relay, add a line to the torrc that says: >> >> MyFamily fingerprint,fingerprint,fingerprint,... >> >> Where the fingerprints are the fingerprints of each of your relays. >> >> Tim >> >> > - Bungeetaco >> > https://bungeetaco.com/ >> > >> >> -------- Original Message -------- >> >> Subject: Re: [tor-dev] protecting users from known relay groups with end-to-end correlation capabilities >> >> Local Time: December 2, 2016 5:39 PM >> >> UTC Time: December 2, 2016 10:39 PM >> >> From: teor2345(a)gmail.com >> >> To: tor-dev(a)lists.torproject.org >> >> abuse(a)torworld.org, tor(a)digineo.de, Viktor Nikolov <vnikolov(a)vnikolov.cz>, Nicholas Merrill <nick(a)calyx.com>, bungeetaco(a)protonmail.com, Dmitrii Tcvetkov <demfloro(a)demfloro.ru>, abuse(a)to-surf-and-protect.net, bad-relays(a)lists.torproject.org >> >> >> >> Dear relay operators who are CC'd, >> >> >> >> TL;DR: we're talking about blacklisting your non-exit relays, >> >> because they don't have MyFamily set correctly. >> >> >> >> If you'd like help configuring MyFamily correctly, please let us know. >> >> >> >> > On 3 Dec. 2016, at 08:50, nusenu <nusenu(a)openmailbox.org> wrote: >> >> > >> >> > Hi, >> >> > >> >> > it is a well known fact that MyFamily is a largely ignored setting, >> >> > luckily this is not a problem in most cases because >> >> > >> >> > - all relevant relays are run in a single /16 >> >> > or >> >> > - are only guard relays (exit probability = 0*) >> >> > or >> >> > - are only exit relays (guard probability = 0*) >> >> > >> >> > but there is a limited number of relay groups** that have actual >> >> > end-to-end correlation capabilities, meaning they are potentially chosen >> >> > by tor clients for the guard _and_ exit position, even if the odds are >> >> > (hopefully) not very high. >> >> > >> >> > These potentially dangerous relay groups >> >> > - are run in multiple /16 netblocks >> >> > - have an exit _and_ guard probability of > 0 (because they run exits >> >> > and guards) >> >> > >> >> > Examples (generated daily): >> >> > https://raw.githubusercontent.com/ornetstats/stats/master/o/potentially_dan… >> >> > (see CC) >> >> >> >> This is a useful check, but it is insufficient. >> >> Can you please produce a similar list for middles and exits by the same >> >> operator? >> >> >> >> (Controlling the middle and exit leads to a guard identification >> >> attack.) >> >> >> >> There's also an attack when an operator controls a guard and a middle. >> >> But that's harder to resolve, albeit much more common. >> >> >> >> > How could the risk for tor clients be reduced? >> >> > (options after enough dir auths came to the conclusion that these relays >> >> > are in fact operated by a single entity) >> >> > >> >> > 1) try to contact the operators and give them time to fix it >> >> > I've done that multiple times but haven't been successful [1] >> >> >> >> Have you tried emailing them individually? >> >> I've typically got better results that way. >> >> >> >> > 2) build tools to easily/automatically manage MyFamily >> >> > done[2], but it is unlikely to be used >> >> >> >> Maybe one solution is to build a generic tool that works with more than >> >> just ansible? >> >> >> >> > 3) assign them the badexit flag >> >> > since exits are a scarce resource, not very wise >> >> >> >> +1 >> >> >> >> > 4) assign them the badguard flag >> >> > there is no such thing ;) >> >> >> >> We have written patches that take away the guard flag. >> >> This would be possible, but it doesn't resolve the issue, because they >> >> will still be used as middle relays. >> >> >> >> However, taking away the guard flag would fix the guard/middle case, >> >> because then all the relays would only be used as middle relays. >> >> >> >> > 5) blacklist the entry guards (that are outside the configured family) >> >> >> >> Yes, this is the best option, because it protects clients from >> >> selecting relays from that operator as either guard or middle. >> >> >> >> (However, operating a bridge and an exit still has the same issue, and >> >> there is no MyFamily for bridges, because that de-anonymises them. As >> >> do the bridge/middle and guard/middle cases. So maybe we should >> >> consider the risks of each case, and whether we want to educate or ban.) >> >> >> >> And, of course, it's worth noting that the ContactInfo might be >> >> incorrect, so we would have to do this on a case-by-case basis, and >> >> convince the directory authority operators it's a sensible thing to do. >> >> >> >> (If someone is using others' ContactInfo, those relays should be >> >> banned.) >> >> >> >> > 6) change tor's path selection algorithm to never choose more than one >> >> > relay with a given non-empty non-default contact string? >> >> > This would basically turn the ContactInfo field into the PoS token >> >> > mentioned by Mike in [3]. Since there are a few common contactInfo >> >> > strings this is probably not the best option without excluding them. >> >> >> >> No, this field is not mutually authenticated, unlike MyFamily. >> >> This leads to an attack where bad relays bias client path selection >> >> using ContactInfo. >> >> >> >> > [1] >> >> > https://lists.torproject.org/pipermail/tor-relays/2016-November/010965.html >> >> > [2] https://github.com/nusenu/ansible-relayor >> >> > [3] https://trac.torproject.org/projects/tor/ticket/5565 >> >> > * if we can assume onionoo's values to be accurate and realistic >> >> > ** they are considered to be operated by a single group due to their >> >> > contactInfo descriptor field. This string is not verified in any way and >> >> > can therefore result in false-positives. T -- Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n xmpp: teor at torproject dot org ------------------------------------------------------------------------

1 0

Re: [tor-dev] protecting users from known relay groups with end-to-end correlation capabilities
by teor 03 Dec '16

03 Dec '16

> On 3 Dec. 2016, at 11:11, Bungeetaco <bungeetaco(a)protonmail.com> wrote: > > > > > > > Hi there! I would be more than glad to apply the appropriate modifications to my relay if it means increased security for the users ;D. I care about the security and privacy of the people who pass through my relays, and I take pride in supporting a project which empowers people so much. I decided to run a Middle and 2 exit nodes because I wanted to provide diversified support to the Tor network, I did not intend to jeopardize anyone's privacy or security. > > Would I need to add the fingerprints of my others nodes in my torrc configuration files? If so, please let me know how to accomplish this and I'll push an update on all my servers ASAP. The last thing I want is create a security risk for the users and/or distrust. > > Thanks for letting me know about this btw! Hi Bungeetaco, On each relay, add a line to the torrc that says: MyFamily fingerprint,fingerprint,fingerprint,... Where the fingerprints are the fingerprints of each of your relays. Tim > - Bungeetaco > https://bungeetaco.com/ > >> -------- Original Message -------- >> Subject: Re: [tor-dev] protecting users from known relay groups with end-to-end correlation capabilities >> Local Time: December 2, 2016 5:39 PM >> UTC Time: December 2, 2016 10:39 PM >> From: teor2345(a)gmail.com >> To: tor-dev(a)lists.torproject.org >> abuse(a)torworld.org, tor(a)digineo.de, Viktor Nikolov <vnikolov(a)vnikolov.cz>, Nicholas Merrill <nick(a)calyx.com>, bungeetaco(a)protonmail.com, Dmitrii Tcvetkov <demfloro(a)demfloro.ru>, abuse(a)to-surf-and-protect.net, bad-relays(a)lists.torproject.org >> >> Dear relay operators who are CC'd, >> >> TL;DR: we're talking about blacklisting your non-exit relays, >> because they don't have MyFamily set correctly. >> >> If you'd like help configuring MyFamily correctly, please let us know. >> >> > On 3 Dec. 2016, at 08:50, nusenu <nusenu(a)openmailbox.org> wrote: >> > >> > Hi, >> > >> > it is a well known fact that MyFamily is a largely ignored setting, >> > luckily this is not a problem in most cases because >> > >> > - all relevant relays are run in a single /16 >> > or >> > - are only guard relays (exit probability = 0*) >> > or >> > - are only exit relays (guard probability = 0*) >> > >> > but there is a limited number of relay groups** that have actual >> > end-to-end correlation capabilities, meaning they are potentially chosen >> > by tor clients for the guard _and_ exit position, even if the odds are >> > (hopefully) not very high. >> > >> > These potentially dangerous relay groups >> > - are run in multiple /16 netblocks >> > - have an exit _and_ guard probability of > 0 (because they run exits >> > and guards) >> > >> > Examples (generated daily): >> > https://raw.githubusercontent.com/ornetstats/stats/master/o/potentially_dan… >> > (see CC) >> >> This is a useful check, but it is insufficient. >> Can you please produce a similar list for middles and exits by the same >> operator? >> >> (Controlling the middle and exit leads to a guard identification >> attack.) >> >> There's also an attack when an operator controls a guard and a middle. >> But that's harder to resolve, albeit much more common. >> >> > How could the risk for tor clients be reduced? >> > (options after enough dir auths came to the conclusion that these relays >> > are in fact operated by a single entity) >> > >> > 1) try to contact the operators and give them time to fix it >> > I've done that multiple times but haven't been successful [1] >> >> Have you tried emailing them individually? >> I've typically got better results that way. >> >> > 2) build tools to easily/automatically manage MyFamily >> > done[2], but it is unlikely to be used >> >> Maybe one solution is to build a generic tool that works with more than >> just ansible? >> >> > 3) assign them the badexit flag >> > since exits are a scarce resource, not very wise >> >> +1 >> >> > 4) assign them the badguard flag >> > there is no such thing ;) >> >> We have written patches that take away the guard flag. >> This would be possible, but it doesn't resolve the issue, because they >> will still be used as middle relays. >> >> However, taking away the guard flag would fix the guard/middle case, >> because then all the relays would only be used as middle relays. >> >> > 5) blacklist the entry guards (that are outside the configured family) >> >> Yes, this is the best option, because it protects clients from >> selecting relays from that operator as either guard or middle. >> >> (However, operating a bridge and an exit still has the same issue, and >> there is no MyFamily for bridges, because that de-anonymises them. As >> do the bridge/middle and guard/middle cases. So maybe we should >> consider the risks of each case, and whether we want to educate or ban.) >> >> And, of course, it's worth noting that the ContactInfo might be >> incorrect, so we would have to do this on a case-by-case basis, and >> convince the directory authority operators it's a sensible thing to do. >> >> (If someone is using others' ContactInfo, those relays should be >> banned.) >> >> > 6) change tor's path selection algorithm to never choose more than one >> > relay with a given non-empty non-default contact string? >> > This would basically turn the ContactInfo field into the PoS token >> > mentioned by Mike in [3]. Since there are a few common contactInfo >> > strings this is probably not the best option without excluding them. >> >> No, this field is not mutually authenticated, unlike MyFamily. >> This leads to an attack where bad relays bias client path selection >> using ContactInfo. >> >> > [1] >> > https://lists.torproject.org/pipermail/tor-relays/2016-November/010965.html >> > [2] https://github.com/nusenu/ansible-relayor >> > [3] https://trac.torproject.org/projects/tor/ticket/5565 >> > * if we can assume onionoo's values to be accurate and realistic >> > ** they are considered to be operated by a single group due to their >> > contactInfo descriptor field. This string is not verified in any way and >> > can therefore result in false-positives. >> >> T >> >> -- >> Tim Wilson-Brown (teor) >> >> teor2345 at gmail dot com >> PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B >> ricochet:ekmygaiu4rzgsk6n >> xmpp: teor at torproject dot org >> ------------------------------------------------------------------------ >> >> >> > T -- Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n xmpp: teor at torproject dot org ------------------------------------------------------------------------

1 0

[PATCH] torspec: Keep proposal-status.txt up to date
by George Kadianakis 01 Dec '16

01 Dec '16

Hello, I was in a train yesterday and decided to do some torspec housekeeping. So I updated the proposals/proposal-status.txt file which includes a summary of every proposal. You can find my changes here: https://gitweb.torproject.org/user/asn/torspec.git/commit/?h=proposal-statu… Please let me know if you see anything wrong with it. Otherwise, I will merge this to torspec soon since it's probably better than the status quo. Of course, there are still things we can do to make proposal-status.txt better, and also I bet some of the old proposals have changed status since they were written. I updated a few of them, but I didn't do all of them. Cheers!

2 2

Stem Release 1.5
by Damian Johnson 30 Nov '16

30 Nov '16

Damn this was long overdue. I'm delighted to announce Stem 1.5.2, the accumulation of seventeen months of improvements. What is *Stem <https://stem.torproject.org/>*, you ask? For those who aren't familiar with it Stem is a Python library for interacting with Tor. With it you can script against your relay, descriptor data, or even write applications similar to Nyx and Vidalia. So what's new in this release? Short answer: a lot. For full details *see our release announcement* <http://blog.atagar.com/stem-release-1-5/>!

2 1

Shor's Algorithm meets Lattices
by bancfc＠openmailbox.org 26 Nov '16

26 Nov '16

In a new paper Peter Shor extends his quantum algorithm to solving a variant of the Closest Lattice-Vector Problem in polynomial time. With some future tweaking it can be used against the entire family of Lattice based crypto. While an error in the calculations has been pointed out and the paper will be withdrawn, this isn't reassuring since a revised version where this still holds is probable. Its available on arxiv until Monday so grab a copy before then: https://arxiv.org/pdf/1611.06999.pdf Without Lattice crypto we're stuck with some very ugly choices as Isis pointed out. McEliece is huge. SIDH is slow and brittle. The PQ future looks grim fam :(

3 3

CollecTor Release 1.1.1
by iwakeh 24 Nov '16

24 Nov '16

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi there! another small CollecTor version is available: https://dist.torproject.org/collector/1.1.1/ The release provides two changes * CollecTor now handles a rare internal error gracefully instead of escalating the problem [0], and * hidserv-* lines are now kept in sanitized extra-info descriptors [1]. In addition, the released .jar files are signed again, and a simple test during the release process ensures they'll get signed in future releases. Please direct comments and questions to the metrics-team mailing list [2]. And, of course, bug reports [3] or feature requests [4] can be filed in trac. Cheers, iwakeh [0] https://trac.torproject.org/projects/tor/ticket/20695 [1] https://trac.torproject.org/projects/tor/ticket/20714 [2] https://lists.torproject.org/cgi-bin/mailman/listinfo/metrics-team [3] https://trac.torproject.org/projects/tor/newticket?component=Metrics/Collec… [4] https://trac.torproject.org/projects/tor/newticket?component=Metrics/Collec… -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iF4EAREIAAYFAlg3Yc4ACgkQsANAxTOj/abH6wD/bi7z7uysfbc4TIBG8poXD5yk GrSWrgfTAwhk0YHyfEIA/09jUs/JSGeTFJ8Y08QYV5ursBrYs/2rKVDL33A+1mwL =iAUd -----END PGP SIGNATURE-----

1 0

Distributed RNG Research
by bancfc＠openmailbox.org 23 Nov '16

23 Nov '16

New research on Distributed RNGs is published: "Scalable Bias-Resistant Distributed Randomness" eprint.iacr.org/2016/1067

2 1

Onionoo 3.1-1.0.0
by iwakeh 23 Nov '16

23 Nov '16

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi there! More than five years of development [0] led to the very first release of Onionoo, which is now available here: https://dist.torproject.org/onionoo/3.1-1.0.0/ For those who haven't heard of Onionoo: Onionoo [0] is a web-based protocol to learn about currently running Tor relays and bridges. Onionoo responds to HTTP GET requests with JSON-formatted replies. As reading JSON-files is not everyones favorite, there are quite a few client applications building on Onionoo's data and providing human-readable information [0]. In case you're wondering about the version number: The version of Onionoo consists of the current protocol version [2], which is 3.1 and the software's version 1.0.0. The first Onionoo protocol was already released two years ago. With the first Onionoo release and the accompanying operating guide [3] you're just one download away from running your own Onionoo mirror. Please direct comments and questions to the metrics-team mailing list [4]. Cheers, iwakeh [0] https://gitweb.torproject.org/onionoo.git/log/?ofs=500 [1] https://onionoo.torproject.org/ [2] https://onionoo.torproject.org/protocol.html [3] see release tar-ball: INSTALL.md [4] https://lists.torproject.org/cgi-bin/mailman/listinfo/metrics-team -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iF4EAREIAAYFAlg12wIACgkQsANAxTOj/aaXjwEAj9NWFefHYPlY9UmIR7oflh/y U/DfO0kVf/aAigyI4u0A+QF6atK+Yqw1B+E7jjOL8wMhA4sDsnsRr7KxBA7QqwVG =NQpw -----END PGP SIGNATURE-----

1 0

Browsers, VMs and Targeted Hardware Bit-Flips
by teor 18 Nov '16

18 Nov '16

Hi all, There have been a series of recent attacks that take advantage of "rowhammer" (a RAM hardware bit-flipping vulnerability) to flip bits in security-critical data structures. VMs sharing the same physical RAM are vulnerable, and browsers and mobile apps are remote vectors with proof-of-concept implementations. Rowhammer summary: https://en.wikipedia.org/wiki/Row_hammer An attack that flips targeted bits in another virtual machine on the same physical RAM, targeting OpenSSH public keys, GPG public keys, and Debian package sources: https://www.vusec.net/projects/flip-feng-shui/ A similar proof-of-concept Android app: https://www.vusec.net/projects/drammer/ A JavaScript-based in-browser remote proof-of-concept: https://arxiv.org/pdf/1507.06955v1.pdf It seems like a short step from these existing attacks to targeting Tor Browser users remotely. I wonder whether it might be possible to target relays (or clients) using OR cells or directory documents with specific content, but this seems much less likely. I have been thinking about how we could make Tor (and browsers, and other processes, and OSs) less vulnerable to these kinds of attacks. In general, some of the process-level defences against one or more of the above attacks are: * sign or checksum all security-critical data structures, * implement and check cross-certification, * don't rely on cached checks (or checks performed at load time) continuing to be accurate, * minimise time between checking validity and using the data, (this includes signatures, checksums, data structure consistency) * make the content of memory pages (including loaded files) less predictable, * make sure the hamming distance between trusted, valid inputs and untrusted, valid inputs is large, in particular: * register domains that are one bit-flip away from trusted domains, (or, alternately, mandate SSL, and pin certificates, and fix broken CA roots) Some of the OS-level defences are: * turn off memory deduplication, * write and verify checksums on each page, Some of the firmware/hardware defences are: * increase the RAM refresh rate, * improve RAM design, * use ECC RAM. T -- Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n xmpp: teor at torproject dot org ------------------------------------------------------------------------

2 1