July 2018 - cypherpunks-legacy

Novell-SUSE Sponsors Openswan
by brian-slashdotnews＠hyperreal.org 06 Jul '18

06 Jul '18

Link: http://slashdot.org/article.pl?sid=04/06/20/0124214 Posted by: timothy, on 2004-06-20 03:03:00 Topic: security, 37 comments from the they're-building-a-behemoth dept. [1]hsjones writes "Concerned about the demise of FreeS/WAN? Well, looks like Openswan is going to be a good, strong open source IPsec project going forward. Novell and SUSE have jumped in with Astaro to back the project and move it along. [2]See the press release. The Openswan project is at [3]http://www.openswan.org. SUSE Linux and Astaro Security Linux both use FreeS/WAN in their current releases. It will be very interesting to watch what they do now with Openswan!" IFRAME: [4]pos6 References 1. mailto:hsjones@sisna.com 2. http://www.novell.com/news/press/archive/2004/06/pr04040.html 3. http://www.openswan.org/ 4. http://ads.osdn.com/?ad_id=2936&alloc_id=8587&site_id=1&request_id=584565 ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> ______________________________________________________________ ICBM: 48.07078, 11.61144 http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE http://moleculardevices.org http://nanomachines.net [demime 1.01d removed an attachment of type application/pgp-signature]

1 0

Novell-SUSE Sponsors Openswan
by brian-slashdotnews＠hyperreal.org 06 Jul '18

06 Jul '18

Link: http://slashdot.org/article.pl?sid=04/06/20/0124214 Posted by: timothy, on 2004-06-20 03:03:00 Topic: security, 37 comments from the they're-building-a-behemoth dept. [1]hsjones writes "Concerned about the demise of FreeS/WAN? Well, looks like Openswan is going to be a good, strong open source IPsec project going forward. Novell and SUSE have jumped in with Astaro to back the project and move it along. [2]See the press release. The Openswan project is at [3]http://www.openswan.org. SUSE Linux and Astaro Security Linux both use FreeS/WAN in their current releases. It will be very interesting to watch what they do now with Openswan!" IFRAME: [4]pos6 References 1. mailto:hsjones@sisna.com 2. http://www.novell.com/news/press/archive/2004/06/pr04040.html 3. http://www.openswan.org/ 4. http://ads.osdn.com/?ad_id=2936&alloc_id=8587&site_id=1&request_id=584565 ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> ______________________________________________________________ ICBM: 48.07078, 11.61144 http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE http://moleculardevices.org http://nanomachines.net [demime 1.01d removed an attachment of type application/pgp-signature]

1 0

[tahoe-dev] LAFS Weekly Dev Chat notes, 2012-11-29
by Zooko Wilcox-O'Hearn 06 Jul '18

06 Jul '18

legend: "b" means Action Item! (If your name is mentioned after "b" and you aren't really going to do that thing, then please let us know!); "b" means Action Item that is already done. #include <std/caveat/lector> // I don't have time to write explanations of all this, and I may have forgotten parts. in attendance: Zooko (scribe), Marcus, Brian, Evgeny, David-Sarah, Kevan (briefly b technical difficulties), CiC (briefly) Marcus found the quickstart doc to be fine b it was easy to get Tahoe-LAFS set up. He had been using Linux for a while and so he was just looking for "What's my 'make'? What's my './configure' equivalent?". Marcus says there's a parallel set of getting-started docs maintained by the I2P people. Marcus wonders why the multi-introducer patch hasn't been merged into main Tahoe-LAFS yet, as it has been in use in I2P for a long time and is quite stable for them. The I2P setup include a cron job that downloads a new set of introducers and also downloads news. Answer: the multi-introducer patch may conflict with the accounting project. The accounting project is going to add the ability to control which servers your client will use or which clients your server will serve. In that case, access to the introducer will no longer be sufficient to allow you to use a set of servers. In that world, we might want to replace "introducers" with a "gossip" strategy. BUT We're reconsidering, because when/if we *do* replace the introduction process, we could change this behavior without a great deal of backward-compatibility problems. In fact, Brian thinks that even after it does the sort of gossip he wants, he might still want a distinguished set of introducers to serve as "seeds" for gossip, so we might want to *keep* multi-introducers as is. Things to do to about the multi-introduction patch: b" See if it merges with current trunk (which has the signed-announcements patch, which included significant refactoring of introduction). b [[Who?]] b" Let kytv know that we're interested. b [[Zooko]] b" Write tests that actually exercise the behavior of using multiple introducers. b [[kytv?]] b" Write up a plan for forward-compatibility with gossip. b [[Brian, because nobody else knows what sort of gossip Brian wants, precisely.]] Brian says there may be differences of opinion about design strategy here. He favors a "fully distributed" approach where no node is distinguished in terms of the introduction service that it provides to its peers. Zooko wonders if this relates to the "Are We Client-Server or Peer-To-Peer?" issue. David-Sarah says that this may not make any difference *in terms of security* for our current use cases: friendgrids, commercial services, volunteergrids, ... It isn't like we're currently trying to implement the One Grid To Rule Them All use case. [[Added by Zooko ex post facto: I long ago posted a design for "gossip/distributed-introduction" based on a Chord-like ring which is, IMHO, simple and scalable, and which is described in sufficient detail to be implemented. Here it is, it is ticket 68, comment 11: https://tahoe-lafs.org/trac/tahoe-lafs/ticket/68#comment:11 . I don't think it matters much whether the set of introducers that are participating in that Chord-like ring are a specially selected set a la the current I2P branch or whether "everyone is an introducer" a la gossip.]] Zooko says that the thing he is concerned about isn't the introduction part b how clients learn about servers b but instead the authorization part b how clients choose whether or not to use the servers that they know about. Current Tahoe-LAFS combines those two issues, which is a problem. Zooko says that Tahoe-LAFS has very weak security against rollback attack or DoS, but that if we had server selection (which is a part of the accounting project) then we would have very strong security against those. Zooko tells an illustration from Bruce Schneier: if you're at a coffeeshop and you need to go to the bathroom, you can ask a random stranger sitting nearby to watch your laptop. If you're paranoid, you can ask three different random strangers to watch your laptop and each other. But if three random strangers approach *you* and offer to watch your laptop, that's different! Zooko says server selection b where you choose the 1 or 3 servers that you're going to rely on instead of accepting the offer from 1 or 3 random servers b makes all the difference in the world in terms of security against DoS and rollback. Brian wonders what the user experience for that is going to be like. Zooko veers the discussion onto Raph Levien's Trust Metric, and thence onto Brian's cool "Not Tahoe" project. discussion of Brian's Cool "Not Tahoe" Project. Zooko urges Brian to make BCNTP be even more "Not-Tahoe-Like" by not having storage servers. Not having storage servers means you don't have to worry about how much different people's perspectives on the network overlap with one another. Brian might use an S3-style hosted approach. He might let a client publish which set of servers it uses, for the benefit of its file-sharers. Also, file references can be fat in Not-Tahoe, since they don't often get sent out of band, so they could include information about servers. back to docs: Evgeny's introductory doc is good! It is incomplete. It is aimed at less sophisticated users. Zooko is unsure if it would "fit" on the Download page of https://tahoe-lafs.org, or if it should go somewhere else. It might make a good magazine article. We might end up with too many started docs (that would be a good problem to have). There is audience segmentation, for example the I2P starter docs have been read by many I2P users but not by other users. Zooko wants better docs for less sophisticated new users, so Zooko is inclined to use Evgeny's doc. What's the next step? 1. LAFS developers answer some of Evgeny's questions. b [[Marcus and David-Sarah?]] 2. Test out the doc on some lab rats^W^Wnew users. b [[Evgeny?]] Evgeny has some users who want to use Tahoe-LAFS who might beta-test his doc. Tune in next time for: b" Proof-of-Retrievability; Zooko will post it to tahoe-dev in advance of the meeting so you can read it before the meeting! Warning: it is long. You might have to turn your phone off or something in order to get through it. (David-Sarah quips that it probably isn't as long as the Security Argument For Rainhill.) b" Report from Marlowe about translation efforts. _______________________________________________ tahoe-dev mailing list tahoe-dev(a)tahoe-lafs.org https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE

1 0

[i2p] weekly status notes [feb 8]
by jrandom 06 Jul '18

06 Jul '18

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi y'all, update time again * Index 1) 0.4.2.6-* 2) 0.5 3) i2p-bt 0.1.6 4) fortuna 5) ??? * 1) 0.4.2.6-* It doesn't seem like it, but its been over a month since the 0.4.2.6 release came out and things are still in pretty good shape. There have been a series of pretty useful updates [1] since then, but no real show stopper calling for a new release to get pushed. However, in the last day or two we've had some really good bugfixes sent in (thanks anon and Sugadude!), and if we weren't on the verge of the 0.5 release, I'd probably package 'er up and push 'er out. anon's update fixes a border condition in the streaming lib which has been causing many of the timeouts seen in BT and other large transfers, so if you're feeling adventurous, grab CVS HEAD and try 'er out. Or wait around for the next release, of course. [1] http://dev.i2p.net/cgi-bin/cvsweb.cgi/i2p/history.txt?rev=HEAD * 2) 0.5 Lots and lots of progress on the 0.5 front (as anyone on the i2p-cvs list [2] can attest to). All of the tunnel updates and various performance tweaks have been tested out, and while it doesn't include much in the way of the various [3] enforced ordering algorithms, it does get the basics covered. We've also integrated a set of (BSD licensed) Bloom filters [4] from XLattice [5], allowing us to detect replay attacks without requiring any per-message memory usage and nearly 0ms overhead. To accomodate our needs, the filters have been trivially extended to decay so that after a tunnel expires, the filter doesn't have the IVs we saw in that tunnel anymore. While I'm trying to slip in as much as I can into the 0.5 release, I also realize that we need to expect the unexpected - meaning the best way to improve it is to get it into your hands and learn from how it works (and doesn't work) for you. To help with this, as I've mentioned before, we're going to have a 0.5 release (hopefully out in the next week), breaking backwards compatability, then work on improving it from there, building a 0.5.1 release when its ready. Looking back at the roadmap [6], the only thing being deferred to 0.5.1 is the strict ordering. There'll also be improvements to the throttling and load balancing over time, I'm sure, but I expect we'll be tweaking that pretty much forever. There have been some other things discussed that I've hoped to include in 0.5 though, like the download tool and the one-click update code, but it looks like those will be deferred as well. [2] http://dev.i2p.net/pipermail/i2p-cvs/2005-February/thread.html [3] http://dev.i2p.net/cgi-bin/cvsweb.cgi/i2p/router/doc/ tunnel-alt.html?rev=HEAD#tunnel.selection.client [4] http://en.wikipedia.org/wiki/Bloom_filter [5] http://xlattice.sourceforge.net/index.html [6] http://www.i2p.net/roadmap * 3) i2p-bt 0.1.6 duck has patched up a new i2p-bt release (yay!), available at the usual locations, so get yours while its hot [7]. Between this update and anon's streaming lib patch, I pretty much saturated my uplink while seeding some files, so give it a shot. [7] http://forum.i2p.net/viewtopic.php?t=300 * 4) fortuna As mentioned in last week's meeting, smeghead has been churning away at a whole slew of different updates lately, and while battling to get I2P working with gcj, some really horrendous PRNG issues have cropped up in some JVMs, pretty much forcing the issue of having a PRNG we can count on. Having heard back from the GNU-Crypto folks, while their fortuna implementation hasn't really been deployed yet, it looks to be the best fit for our needs. We might be able to get it into the 0.5 release, but chances are it'll get deferred to 0.5.1 though, as we'll want to tweak it so that it can provide us with the necessary quantity of random data. * 5) ??? Lots of things going on, and there has been a burst of activity on the forum [8] lately as well, so I'm sure I've missed some things. In any case, swing on by the meeting in a few minutes and say whats on your mind (or just lurk and throw in the random snark) =jr [8] http://forum.i2p.net/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFCCSaRGnFL2th344YRApVpAKCEypMmgxmJu7ezMwKD5G3ROClh8ACfRqj6 +bDiCX8vfeua3lkyUfiF7ng= =+m56 -----END PGP SIGNATURE----- _______________________________________________ i2p mailing list i2p(a)i2p.net http://i2p.dnsalias.net/mailman/listinfo/i2p ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> ______________________________________________________________ ICBM: 48.07078, 11.61144 http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE http://moleculardevices.org http://nanomachines.net [demime 1.01d removed an attachment of type application/pgp-signature]

1 0

Re: thoughts on one time pads
by Peter Gutmann 06 Jul '18

06 Jul '18

Jonathan Thornburg <jthorn(a)aei.mpg.de> writes: >Melting the CD should work... but in practice that takes a specialized "oven" >(I seriously doubt my home oven gets hot enough), and is likely to produce >toxic fumes, and leave behind a sticky mess (stuck to the surface of the >specialized oven). For no adequately explored reason I've tried various ways of physically destroying CDs: - Hammer on hard surface: Leaves lots of little fragments, generally still stuck together by the protective coating. - Roasting over an open fire: Produces a Salvador Dali effect until they catch fire, then huge amounts of toxic smoke ("fulfilling our carbon tax quota" was one comment) and equally toxic-looking residue. - Propane torch: Melts them without producing combustion products. - Skilsaw: Melts them together at the cutting point, rest undamaged. - Axe: Like skilsaw but without the melting effect. - Using the propane torch and hammer to try and drop-forge a crude double- density CD: Messy. Peter. --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo(a)metzdowd.com ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE [demime 1.01d removed an attachment of type application/pgp-signature which had a name of signature.asc]

1 0

Re: Over a decade of DDOS--any progress yet?
by bmanning＠vacation.karoshi.com 06 Jul '18

06 Jul '18

actually, botnets are an artifact. claiming that the tool is the problem might be a bit short sighted. with the evolution of Internet technologies (IoT) i suspect botnet-like structures to become much more prevelent and useful for things other than coordinated attacks. just another PoV. --bill On Wed, Dec 08, 2010 at 04:46:13AM +0000, Dobbins, Roland wrote: > > On Dec 8, 2010, at 11:26 AM, Sean Donelan wrote: > > > Other than trying to hide your real address, what can be done to prevent DDOS in the first place. > > > DDoS is just a symptom. The problem is botnets. > > Preventing hosts from becoming bots in the first place and taking down existing botnets is the only way to actually *prevent* DDoS attacks. Note that prevention is distinct from *defending* oneself against DDoS attacks. > > ----------------------------------------------------------------------- > Roland Dobbins <rdobbins(a)arbor.net> // <http://www.arbornetworks.com> > > Sell your computer and buy a guitar. > > > > > ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE

1 0

Re: Over a decade of DDOS--any progress yet?
by bmanning＠vacation.karoshi.com 06 Jul '18

06 Jul '18

actually, botnets are an artifact. claiming that the tool is the problem might be a bit short sighted. with the evolution of Internet technologies (IoT) i suspect botnet-like structures to become much more prevelent and useful for things other than coordinated attacks. just another PoV. --bill On Wed, Dec 08, 2010 at 04:46:13AM +0000, Dobbins, Roland wrote: > > On Dec 8, 2010, at 11:26 AM, Sean Donelan wrote: > > > Other than trying to hide your real address, what can be done to prevent DDOS in the first place. > > > DDoS is just a symptom. The problem is botnets. > > Preventing hosts from becoming bots in the first place and taking down existing botnets is the only way to actually *prevent* DDoS attacks. Note that prevention is distinct from *defending* oneself against DDoS attacks. > > ----------------------------------------------------------------------- > Roland Dobbins <rdobbins(a)arbor.net> // <http://www.arbornetworks.com> > > Sell your computer and buy a guitar. > > > > > ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE

1 0

[cryptography] [OT] Reworked Version of Stuxnet Relative Duqu Found in Iran
by Jeffrey Walton 06 Jul '18

06 Jul '18

Hi Guys, >From "Reworked Version of Stuxnet Relative Duqu Found in Iran," http://www.securitynewsdaily.com/1642-stuxnet-duqu-iran.html: Duqu's builders also changed its encryption algorithm and rigged the malware loader to pose as a Microsoft driver. (The old driver was signed with a stolen Microsoft certificate.) Is the stolen certificate related to Diginotar or some other incident? Microsoft claims Diginotar issued certificates are inert (http://www.computerworld.com/s/article/9219729/Microsoft_Stolen_SSL_certs_c…) Perhaps "Stolen encryption key the source of compromised certificate problem, Symantec says," http://computerworld.co.nz/news.nsf/security/stolen-encryption-key-the-sour… Jeff _______________________________________________ cryptography mailing list cryptography(a)randombit.net http://lists.randombit.net/mailman/listinfo/cryptography ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE

1 0

[i2p] weekly status notes [feb 8]
by jrandom 06 Jul '18

06 Jul '18

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi y'all, update time again * Index 1) 0.4.2.6-* 2) 0.5 3) i2p-bt 0.1.6 4) fortuna 5) ??? * 1) 0.4.2.6-* It doesn't seem like it, but its been over a month since the 0.4.2.6 release came out and things are still in pretty good shape. There have been a series of pretty useful updates [1] since then, but no real show stopper calling for a new release to get pushed. However, in the last day or two we've had some really good bugfixes sent in (thanks anon and Sugadude!), and if we weren't on the verge of the 0.5 release, I'd probably package 'er up and push 'er out. anon's update fixes a border condition in the streaming lib which has been causing many of the timeouts seen in BT and other large transfers, so if you're feeling adventurous, grab CVS HEAD and try 'er out. Or wait around for the next release, of course. [1] http://dev.i2p.net/cgi-bin/cvsweb.cgi/i2p/history.txt?rev=HEAD * 2) 0.5 Lots and lots of progress on the 0.5 front (as anyone on the i2p-cvs list [2] can attest to). All of the tunnel updates and various performance tweaks have been tested out, and while it doesn't include much in the way of the various [3] enforced ordering algorithms, it does get the basics covered. We've also integrated a set of (BSD licensed) Bloom filters [4] from XLattice [5], allowing us to detect replay attacks without requiring any per-message memory usage and nearly 0ms overhead. To accomodate our needs, the filters have been trivially extended to decay so that after a tunnel expires, the filter doesn't have the IVs we saw in that tunnel anymore. While I'm trying to slip in as much as I can into the 0.5 release, I also realize that we need to expect the unexpected - meaning the best way to improve it is to get it into your hands and learn from how it works (and doesn't work) for you. To help with this, as I've mentioned before, we're going to have a 0.5 release (hopefully out in the next week), breaking backwards compatability, then work on improving it from there, building a 0.5.1 release when its ready. Looking back at the roadmap [6], the only thing being deferred to 0.5.1 is the strict ordering. There'll also be improvements to the throttling and load balancing over time, I'm sure, but I expect we'll be tweaking that pretty much forever. There have been some other things discussed that I've hoped to include in 0.5 though, like the download tool and the one-click update code, but it looks like those will be deferred as well. [2] http://dev.i2p.net/pipermail/i2p-cvs/2005-February/thread.html [3] http://dev.i2p.net/cgi-bin/cvsweb.cgi/i2p/router/doc/ tunnel-alt.html?rev=HEAD#tunnel.selection.client [4] http://en.wikipedia.org/wiki/Bloom_filter [5] http://xlattice.sourceforge.net/index.html [6] http://www.i2p.net/roadmap * 3) i2p-bt 0.1.6 duck has patched up a new i2p-bt release (yay!), available at the usual locations, so get yours while its hot [7]. Between this update and anon's streaming lib patch, I pretty much saturated my uplink while seeding some files, so give it a shot. [7] http://forum.i2p.net/viewtopic.php?t=300 * 4) fortuna As mentioned in last week's meeting, smeghead has been churning away at a whole slew of different updates lately, and while battling to get I2P working with gcj, some really horrendous PRNG issues have cropped up in some JVMs, pretty much forcing the issue of having a PRNG we can count on. Having heard back from the GNU-Crypto folks, while their fortuna implementation hasn't really been deployed yet, it looks to be the best fit for our needs. We might be able to get it into the 0.5 release, but chances are it'll get deferred to 0.5.1 though, as we'll want to tweak it so that it can provide us with the necessary quantity of random data. * 5) ??? Lots of things going on, and there has been a burst of activity on the forum [8] lately as well, so I'm sure I've missed some things. In any case, swing on by the meeting in a few minutes and say whats on your mind (or just lurk and throw in the random snark) =jr [8] http://forum.i2p.net/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFCCSaRGnFL2th344YRApVpAKCEypMmgxmJu7ezMwKD5G3ROClh8ACfRqj6 +bDiCX8vfeua3lkyUfiF7ng= =+m56 -----END PGP SIGNATURE----- _______________________________________________ i2p mailing list i2p(a)i2p.net http://i2p.dnsalias.net/mailman/listinfo/i2p ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> ______________________________________________________________ ICBM: 48.07078, 11.61144 http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE http://moleculardevices.org http://nanomachines.net [demime 1.01d removed an attachment of type application/pgp-signature]

1 0

Re: thoughts on one time pads
by Peter Gutmann 06 Jul '18

06 Jul '18

Jonathan Thornburg <jthorn(a)aei.mpg.de> writes: >Melting the CD should work... but in practice that takes a specialized "oven" >(I seriously doubt my home oven gets hot enough), and is likely to produce >toxic fumes, and leave behind a sticky mess (stuck to the surface of the >specialized oven). For no adequately explored reason I've tried various ways of physically destroying CDs: - Hammer on hard surface: Leaves lots of little fragments, generally still stuck together by the protective coating. - Roasting over an open fire: Produces a Salvador Dali effect until they catch fire, then huge amounts of toxic smoke ("fulfilling our carbon tax quota" was one comment) and equally toxic-looking residue. - Propane torch: Melts them without producing combustion products. - Skilsaw: Melts them together at the cutting point, rest undamaged. - Axe: Like skilsaw but without the melting effect. - Using the propane torch and hammer to try and drop-forge a crude double- density CD: Messy. Peter. --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo(a)metzdowd.com ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE [demime 1.01d removed an attachment of type application/pgp-signature which had a name of signature.asc]

1 0