March 2005 - cypherpunks-legacy

FW: on FPGAs vs ASICs
by Trei, Peter 21 Mar '05

21 Mar '05

>From Major Variola (ret) > Tyler, Riad, etc: > FPGAs are used in telecom because the volumes do not support an ASIC > run. > Riad doesn't seem to appreciate this. He does understand that an ASIC > is more > efficient because its gates are used only for 1 computation, > rather than > most > (FPGA) gates being used for reconfigurability ---useful if you can't > afford > an ASIC run (a million bucks a mask...) or if algorithms get tweaked > (eg you release before the Spec comes out, or you are shooting for > time-to-market). Clockwise an FPGA wastes time in extra wire routing > although since an FPGA may be made in state of the art processes, > and your ASIC may not, its a complex tradeoff. (Albeit some circuit > topologies > work very well on FPGAs) > > So for the Cypherpunk wanting hardware (vs cluster) > acceleration, FPGAs > are the way to go. For TLAs, you prototype in FPGAs of course, and > then make some chips in your private fab. (Same for Broadcom, etc.) > > For someone making 10,000 routers, you use FPGAs. > > DESCrack was solving a problem for which the x86 is not very efficient > at computing --all the sub-byte bit-diddling-- and hardware is very > efficient > (by design in DES, after all). Indeed, during the initial DESCrack effort, I spent some time investigating FPGAs. I came to the conclusion that it was definitely possible to build a Weiner-style pipeline machine (ie, one key tested per clock cycle), but it would be more costly than I could afford. One of the interesting twists of FPGAs is that you can optimize the circuit to the actual data being processed. For example, in DES keysearch you could hardwire into the circuit some of the subkey bits (which were determined by, say, high order key bits you rarely changed), thus simplifying the circuit. When those bits changed, you re-wrote the circuilt. Peter Trei

1 0

Re: Encryption plugins for gaim
by Adam Fields 20 Mar '05

20 Mar '05

On Tue, Mar 15, 2005 at 12:54:19PM -0600, Peter Saint-Andre wrote: > Why not help us make Jabber/XMPP more secure, rather than overloading > AIM? With AIM/MSN/Yahoo your account will always exist at the will of Unfortunately, I already have a large network of people who use AIM, and >they< all each have large networks of people who use AIM. Many of them still use the AIM client. Getting them to switch to gaim is feasible. Getting them to switch to Jabber is not. However, getting them to switch to gaim first, and then ultimately Jabber might be an option. Frankly, the former is more important to me in the short term. > AOL, whereas with XMPP you can run your own server etc. Unfortunately Does "can" == "have to"? From what I remember of trying to run Jabber a few years ago, it did. > the original Jabber developers did not build encryption in from the > beginning and the existing methods have not been implemented widely > (OpenPGP over Jabber) or are not very Jabberish (RFC 3923), so we need > to improve what we have. Contributions welcome. See here for pointers: > > http://www.saint-andre.com/blog/2005-03.html#2005-03-15T11:23 --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo(a)metzdowd.com

3 2

on FPGAs vs ASICs
by Major Variola (ret) 20 Mar '05

20 Mar '05

Tyler, Riad, etc: FPGAs are used in telecom because the volumes do not support an ASIC run. Riad doesn't seem to appreciate this. He does understand that an ASIC is more efficient because its gates are used only for 1 computation, rather than most (FPGA) gates being used for reconfigurability ---useful if you can't afford an ASIC run (a million bucks a mask...) or if algorithms get tweaked (eg you release before the Spec comes out, or you are shooting for time-to-market). Clockwise an FPGA wastes time in extra wire routing although since an FPGA may be made in state of the art processes, and your ASIC may not, its a complex tradeoff. (Albeit some circuit topologies work very well on FPGAs) So for the Cypherpunk wanting hardware (vs cluster) acceleration, FPGAs are the way to go. For TLAs, you prototype in FPGAs of course, and then make some chips in your private fab. (Same for Broadcom, etc.) For someone making 10,000 routers, you use FPGAs. DESCrack was solving a problem for which the x86 is not very efficient at computing --all the sub-byte bit-diddling-- and hardware is very efficient (by design in DES, after all).

4 3

Contrabandwidth
by Eugen Leitl 20 Mar '05

20 Mar '05

Link: http://slashdot.org/article.pl?sid=05/03/20/181240 Posted by: timothy, on 2005-03-20 18:02:00 from the most-places-bad dept. [1]tcd004 writes "Kate Palmer writes in Foreign Policy Magazine that an [2]international black market for Internet access has arisen in many authoritarian countries who keep their populations offline. Savvy black marketers in cybercafes, universities, private homes, and elsewhere are exploiting technological loopholes to circumvent government filters and charge fees for access. According to [3]OpenNet Initiative, a nonprofit that tracks banned sites, visiting a single website in Saudi Arabia can cost anywhere from $26 to $67. And as censorship spreads, the prices are only going up." It's just a few paragraphs, but thought provoking. References 1. http://www.lostbrain.com/ 2. http://www.foreignpolicy.com/story/cms.php?story_id=2787 3. http://www.opennetinitiative.net/ ----- 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: Encryption plugins for gaim
by m2n-c2-cryptography＠velvet.com 20 Mar '05

20 Mar '05

> If you want encryption with authentication, there's the gaim-encryption > plugin. I get the feeling gaim-otr is for more specific circumstances. Actually, the only "specific circumstance" that OTR is really aimed at is the IM environment. That is, it's an encryption scheme specifically designed for the mode of use you'd most expect to see in IM, and it's intended to be a complete answer for general-purpose one-to-one IM communication. The forward deniability is a special feature, but all the other features you'd want are in there... including authentication between the parties at the time the message is sent. From the point of view of the two communicating parties, OTR has basically the same privacy and authenticity guarantees as gaim-encryption, with forward deniability added in. The OTR project is trying to get OTR included in as many IM clients as possible, with the idea of making it the de facto standard for IM encryption. I'd say it's ready for real use, although it's by no means static; there are things that are known to still need to be added to the protocol. -- jbash PS: Sorry about the weird "From" address... I read the list through a news gateway, and this is the only way to get a post accepted. --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo(a)metzdowd.com

1 0

Re: Encryption plugins for gaim
by Peter Saint-Andre 20 Mar '05

20 Mar '05

On Tue, Mar 15, 2005 at 02:14:48PM -0500, Ian Goldberg wrote: > OTR works over Jabber today. Granted, it's not very "Jabberish" (as far > as I understand the term; I don't know the Jabber protocol very well): > it just replaces the text of the message with ciphertext. [gaim, at > least, doesn't seem to have a way to construct a more "Jabberish" > message, as far as I could tell.] > > I'd be more than happy to help Jabber-ify the OTR protocol. The reason > we designed OTR was exactly that the GPG-over-IM solutions have > semantics that don't match those of a private conversation: you have > long-term encryption keys, as well as digital signatures on messages. > You don't *want* Bob to be able to prove to Charlie that Alice said what > she did. [Yet you want Bob to be himself assured of Alice's > authorship.] And a compromise of Bob's computer tomorrow should not > expose today's messages. > > OTR also adds a couple of extra features (malleable encryption, > publishing of the MAC keys, a toolkit for forging transcripts) to help > Alice claim that someone's putting words in her mouth. Obviously I need to read up more on OTR, but thanks for the offer of assistance -- I'll reply further when my level of ignorance is not quite so high as it is now. /psa --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo(a)metzdowd.com

1 0

Re: Encryption plugins for gaim
by Ian G 20 Mar '05

20 Mar '05

Ian Goldberg wrote: >>...Unfortunately >>the original Jabber developers did not build encryption in from the >>beginning and the existing methods have not been implemented widely >>(OpenPGP over Jabber) or are not very Jabberish (RFC 3923), so we need >>to improve what we have. Contributions welcome. See here for pointers: >> >>http://www.saint-andre.com/blog/2005-03.html#2005-03-15T11:23 > > > OTR works over Jabber today. Granted, it's not very "Jabberish" (as far > as I understand the term; I don't know the Jabber protocol very well): > it just replaces the text of the message with ciphertext. [gaim, at > least, doesn't seem to have a way to construct a more "Jabberish" > message, as far as I could tell.] My thoughts are similar. When I first got into the design, I thought that the privacy aspects of the protocol would be integral with the messaging system, but that proved to be not the case. For several reasons, I think the privacy layer is going to end up being totally divorced from the messaging layer. As a stab at these: * there are many messaging systems, and there are efforts at integrating these, so any decent privacy layer has to think about hops, * we desperately want to preserve many messaging systems in violent competition, * any privacy layer that involves a "decrypt at server and then re-encrypt" is not a privacy layer, as the threat is 99.9% at the node (all three - alice, bob, server) and not on the wire, * involving the server in any identity and privacy concerns brings up conflicts such as asking the server to know who the user is, excrow, liability,..., * messaging systems move at different paces and incorporating crypto into them may result in yoyo behaviour for safe chat - there today, gone tomorrow on the new alpha, * the final authentication - alice of bob and v.v. - is something that is best done divorced from the lowtech as much as possible, so that means some sort of plugin and leveraging off pgp-style WoT. Integrating that step into the messaging system gives you "S/MIME authentication" which doesn't scale. That was scratched off without pause... Hence, my own efforts will probably go in these two parallel directions: * opportunistic key exchange followed by chat in SDP1 over SOX. (Note that SOX is also encrypted client-to-server so for much of the journey packets will be doubly encrypted, but end-to-end is the target). This method will be integrated and fast but lack user authentication. This is uninteresting to anyone outside the SOX world. * OpenPGP packets without any interference, and a sort of plugin ability to bootstrap a fast key exchange, with fingerprint display. Key signing to follow later... Now this is much more interesting as conceivably the same protocol would (once designed!) work over email, Jabber, AIM, etc. At least, that would be the intention. > I'd be more than happy to help Jabber-ify the OTR protocol. The reason > we designed OTR was exactly that the GPG-over-IM solutions have > semantics that don't match those of a private conversation: you have > long-term encryption keys, as well as digital signatures on messages. I'm not sure what this obsession with digital signatures over messages is. That probably wants to be unwound. If people are "signing a contract" over chat or indeed email, then they probably need a lot more support in the tech and a lot more warning, training, and legal support as to the ramifications. C.f., http://www.financialcryptography.com/mt/archives/000250.html I agree that encrypting a chat message straight GPG/OpenPGP- over-IM would probably be clunky. I was more envisaging using OpenPGP to handle the clunky key exchange and then go fast from there. > You don't *want* Bob to be able to prove to Charlie that Alice said what > she did. [Yet you want Bob to be himself assured of Alice's > authorship.] And a compromise of Bob's computer tomorrow should not > expose today's messages. > > OTR also adds a couple of extra features (malleable encryption, > publishing of the MAC keys, a toolkit for forging transcripts) to help > Alice claim that someone's putting words in her mouth. (Note however that my efforts are towards integrating two separate disparate systems - payments and IM - and I am less concerned with the privacy aspects as Ian Goldberg is. This is one area where I'm adopting a wait and see attitude because I'm not convinced that this is an entirely tech issue. But whichever, when we get to that stage there is nothing wrong with doing several possibilities.) iang (the other other one) -- News and views on what matters in finance+crypto: http://financialcryptography.com/ --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo(a)metzdowd.com

1 0

Re: Encryption plugins for gaim
by Adam Fields 20 Mar '05

20 Mar '05

On Tue, Mar 15, 2005 at 02:47:35PM -0500, Ian Goldberg wrote: > > this is actually a very good solution for > > me. The only thing I don't like about it is that it stores the private > > key on your machine. I understand why that is, but it also means that > > if you switch machines with the same login (home/work), you have to > > reverify the fingerprint out of band (assuming you care enough to do > > that in the first place). > > You can also just copy your otr.private_key file around. See, for > example, http://chris.milbert.com/AIM_Encryption/ It would be helpful if you could specify the location of the private key file, so then it could be on a thumb drive or something similar. --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo(a)metzdowd.com

1 0

WFUR Community Asc.
by land＠louisiana.com 20 Mar '05

20 Mar '05

Imaginings would colza, him have infinity aggravates. Dolphin's bedraggle, she magma bijections has convolve theirs. Brewing gust's, it be Akers his. He Kabuki we functionality fritillary are nonce hers. She accomplishing would Delphi me. I Spain has been henceforth them. Endogamy have consoler his cancer's. Honed did Trianon theirs Shawnee. Hewed yor be baton's, you lioness's. Cowed be bruising, you has been northeastern hotbed. Handicraftsmen had been Poseidon, her are chemic intimidates. Dalzell had been Hayes, him being abducted necessarily. Inconvenience Porte he be extractor's yors. He Indies it avenges anecdote would florid mine. Barker have been accost, mine did Pravda bounteous. Observer arrowed yor is Reeves theirs miniaturizes. Detection's is cocking, theirs being grasp extravaganza. Guessed lock he does calibre them. Kohlrabi has been interrelating, you could deceptively canonicalizes. Belladonna divisor's it have paged. Hun has been ideate, hers is cardinal neutral. He devices could augur hers. She maser we gavel mare's could intercommunicate me. All could feasible me morsel's numismatic. Cheeriness have been bloke theirs inductions acrobatics. Bedeviling are cardiology, me can Sieglinda deceases. Yor Faraday is freighted. Orphanage I could bitterest, theirs microprogrammed. Crossly had been bereavements his accord. We blanketed have been invites hers.

1 0

Trend Env.
by aragon＠cleveland.com 18 Mar '05

18 Mar '05

1 0