Re: Another entry in the internet security hall of shame....
- Original Message - From: Perry E. Metzger [EMAIL PROTECTED] To: Adam Back [EMAIL PROTECTED] Cc: Peter Saint-Andre [EMAIL PROTECTED]; cryptography@metzdowd.com Sent: Friday, August 26, 2005 8:55 PM Subject: Re: Another entry in the internet security hall of shame [...] Remember that Jabber and similar protocols also trust servers to some extent. Servers store and distribute valuable information like presence data -- it is architecturally hard to do otherwise. Well, not really: the buddies on the list can be located through a Distributed Hash Table such as Kademlia, and, once their IP addresses are known, their presence can be checked by ping/pong exchange of UDP packets every few seconds. The biggest problem is represented by NATs, but there are techniques that can alleviate it (hole punching or, in stubborn cases, relaying through non-NATted nodes). I agree that you *also* want end to end, such as pgp over Jabber provides. I really wish Gaim supported the pgp over Jabber stuff the way PSI does... Why not get OTR then? http://www.cypherpunks.ca/otr/ Enzo - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: EMV
AFAIK, the cards are still the same (Sony FeliCa: http://www.sony.net/Products/felica/): I never changed mine since I got it several years ago. The same card was also adopted in 2002 by EZ-Link in Singapore (http://www.ezlink.com.sg ). Enzo - Original Message - From: Anne Lynn Wheeler [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: 'Ben Laurie' [EMAIL PROTECTED]; 'Peter Fairbrother' [EMAIL PROTECTED]; 'Florian Weimer' [EMAIL PROTECTED]; 'David Alexander Molnar' [EMAIL PROTECTED]; '? Schmidt' [EMAIL PROTECTED]; cryptography@metzdowd.com Sent: Wednesday, July 13, 2005 8:55 AM Subject: Re: EMV ... the original introduction of HK octopus transit card used the sony flavor of iso 14443 with 10cm and transit requirements of transaction in 100ms. having it in the bottom of a bag and bringing the bag within 10cm of the reader does the trick. there was a transit meeting where the mondex people attended ... they claimed that they could also be used for transit ... just get a wireless sleave for the mondex card ... and build 14' long tunnels leading up to the transit gates ... and have the people walk slowly thru the tunnels. Gabriel Haythornthwaite wrote: In Hong Kong a lot of people do little more than wave their bags at the turnstile. Removing the wallet and revealing its size is unnecessary. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: entropy depletion (was: SSL/TLS passive sniffing)
- Original Message - From: [EMAIL PROTECTED] To: cryptography@metzdowd.com Sent: Friday, January 07, 2005 9:30 AM Subject: Re: entropy depletion (was: SSL/TLS passive sniffing) From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Enzo Michelangeli Sent: Tuesday, January 04, 2005 7:50 PM This entropy depletion issue keeps coming up every now and then, but I still don't understand how it is supposed to happen. If the PRNG uses a really non-invertible algorithm (or one invertible only with intractable complexity), its output gives no insight whatsoever on its internal state. I see much misunderstanding of entropy depletion and many misstatements because of it. It is true you don't know what the internal state is but the number of possible internal states tends to reduce with every update of the internal state. See Random Mapping Statistics by Philippe Flajolet and Andrew M. Odlyzko (Proceedings of the workshop on the theory and application of cryptographic techniques on Advances in cryptology, Houthalen, Belgium, Pages: 329 - 354, year 1990) for a thorough discussion. [...] In the real world, our PRNG state update functions are complex enough that we don't know if they are well behaved. Nobody knows how many cycles exist in a PRNG state update function using, for example, SHA-1. You run your PRNG long enough and you may actually hit a state that, when updated, maps onto itself. When this occurs your PRNG will start producing the same bits over and over again. It would be worse if you hit a cycle of 10,000 or so because you may never realize it. I don't know of any work on how not-so well behaved PRNG state update function lose entropy. But that was precisely my initial position: that the insight on the internal state (which I saw, by definition, as the loss of entropy by the generator) that we gain from one bit of output is much smaller than one full bit. However, I've been convinced by the argument broght by John and others - thanks guys - that we should not mix the concept of entropy with issues of computational hardness. That said, however, I wonder if we shouldn't focus more, for practical purposes, on the replacement concept offered by John of usable randomness, with a formal definition allowing its calculation in concrete cases (so that we may assess the risk deriving from using a seeded PRNG rather than a pure RNG in a more quantitative way). The paper you mention appears to go in that direction. Enzo - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: entropy depletion (was: SSL/TLS passive sniffing)
- Original Message - From: John Denker [EMAIL PROTECTED] Sent: Thursday, January 06, 2005 3:06 AM Enzo Michelangeli wrote: [...] If the PRNG uses a really non-invertible algorithm (or one invertible only with intractable complexity), its output gives no insight whatsoever on its internal state. That is an invalid argument. The output is not the only source of insight as to the internal state. As discussed at http://www.av8n.com/turbid/paper/turbid.htm#sec-prng-attack attacks against PRNGs can be classified as follows: 1. Improper seeding, i.e. internal state never properly initialized. 2. Leakage of the internal state over time. This rarely involves direct cryptanalytic attack on the one-way function, leading to leakage through the PRNGs output channel. More commonly it involves side-channels. 3. Improper stretching of limited entropy supplies, i.e. improper reseeding of the PRNG, and other re-use of things that ought not be re-used. 4. Bad side effects. There is a long record of successful attacks against PRNGs (op cit.). Yes, but those are implementation flaws. Also a true RNG could present weaknesses and be attacked (e.g., with strong EM fields overcoming the noise of its sound card; not to mention vulnerabilities induced by the quirks you discuss at http://www.av8n.com/turbid/paper/turbid.htm#sec-quirks). Anyway, I was not saying RNG's are useless because PRNG's are more than enough: the scope of my question was much narrower, and concerned the concept of entropy depletion. I'm not saying that the problems cannot be overcome, but the cost and bother of overcoming them may be such that you decide it's easier (and better!) to implement an industrial-strength high-entropy symbol generator. Sure, I don't disagree with that. As entropy is a measure of the information we don't have about the internal state of a system, That is the correct definition of entropy ... but it must be correctly interpreted and correctly applied; see below. it seems to me that in a good PRNGD its value cannot be reduced just by extracting output bits. If there is an entropy estimator based on the number of bits extracted, that estimator must be flawed. You're letting your intuition about usable randomness run roughshod over the formal definition of entropy. Taking bits out of the PRNG *does* reduce its entropy. By how much exactly? I'd say, _under the hypothesis that the one-way function can't be broken and other attacks fail_, exactly zero; in the real world, maybe a little more. But in /usr/src/linux/drivers/char/random.c I see that the extract_entropy() function, directly called by the exported kernel interface get_random_bytes(), states: if (r-entropy_count / 8 = nbytes) r-entropy_count -= nbytes*8; else r-entropy_count = 0; ...which appears to assume that the pool's entropy (the upper bound of which is POOLBITS, defined equal to 4096) drops by a figure equal to the number of bits that are extracted (nbytes*8). This would only make sense if those bits weren't passed through one-way hashing. Perhaps, a great deal of blockage problems when using /dev/random would go away with a more realistic estimate. Enzo - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Your source code, for sale
- Original Message - From: Ian Grigg [EMAIL PROTECTED] To: Hal Finney [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Sunday, November 07, 2004 11:21 AM [Hal:] Interesting. In the e-gold case, both parties have the same bank, e-gold ltd. The corresponding protocol would be for the buyer to instruct e-gold to set aside some money which would go to the seller once the seller supplied a certain receipt. That receipt would be an email return receipt showing that the seller had sent the buyer the content with hash so-and-so, using a cryptographic email return-receipt protocol. This is to mix up banking and payment systems. Enzo's description shows banks doing banking - lending money on paper that eventually pays a rate of return. In contrast, in the DGC or digital gold currency world, the issuers of gold like e-gold are payment systems and not banks. The distinction is that a payment system does not issue credit. Actually, seeing issuance and acceptance of L/C's only as a money-lending activity is not 100% accurate. Letter of credit is a misnomer: an L/C _may_ be used by the seller to obtain credit, but if the documents are sent for collection rather than negotiated, the payment to the seller is delayed until the opening bank will have debited the buyer's account and remitted the due amount to the negotiating bank. To be precise: when the documents are submitted to the negotiating bank by the seller, the latter also draws under the terms of the L/C a bill of exchange to be accepted by the buyer; that instrument, just like any draft, may be either sent for collection or negotiated immediately, subject, of course, to final settlement. Also, depending on the agreements between the seller and his bank, the received L/C may be considered as collateral to get further allocation of credit, e.g. to open a back-to-back L/C to a seller of raw materials. However, if the documents and the draft are sent for collection, and no other extension of credit are obtained by the buyer, the only advantage of an L/C for the seller is the certainty of being paid by _his_ (negotiating) bank, which he trusts not to collude with the buyer to claim fictitious discrepancies between the actual documents submitted and what the L/C was requesting. (And even in case such discrepancies will turn out to be real, the opening bank will not surrender the Bill of Lading, and therefore the cargo, to the buyer until the latter will have accepted all the discrepancies: so in the worst case the cargo will remain under the seller's control, to be shipped back and/or sold to some other buyer. If it acted differently, the opening bank would go against the standard practice defined in the UCP ICC 500 (http://internet.ggu.edu/~emilian/PUBL500.htm) and its reputation would be badly damaged). So, the L/C mechanism, independently from allocation of credit, _does_ provide a way out of the dilemma which one should come first, payment or delivery?; and this is achieved by leveraging on the reputation of parties separately trusted by the endpoints of the transaction. Generally speaking, it is debatable whether doing banking only means accepting deposits and providing credit or also handling payments for a fee: surely banks routinely do both, although they do not usually enjoy a _regulatory franchise_ on payments because failures in that field are not usually argued to be capable of snowballing into systemic failures. (Austrian economists argue that that's also the case with provision of credit, but it's a much more controversial issue). In the US, as we know, Greenspan's FED decided several years ago against heavy regulation of the payments business, and most industrialized countries chose to follow suit. So, in the e-gold scenario, there would need to be similar third parties independent of the payment system to provide the credit moving in the reverse direction to the goods. In the end it would be much like Enzo's example, with a third party with the seller, a third party with the buyer, and one or two third parties who are dealing the physical goods. There have been some thoughts in the direction of credit creation in the gold community, but nothing of any sustainability has occurred as yet. That would probably end up attracting unwelcome attention by the regulators. Besides, wouldn't that require some sort of fractional banking, resulting in a money supply multiple of the monetary base by an unstable multiplier, and ultimately bringing back the disadvantages of fiat currencies? Enzo - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Your source code, for sale
- Original Message - From: Hal Finney [EMAIL PROTECTED] Sent: Friday, November 05, 2004 7:01 AM Tyler Durden writes: So my newbie-style question is, is there an eGold that can be verified, but not accessed, until a 'release' code is sent? In other words, say I'm buying some hacker-ed code and pay in egold. I don't want them to be able to 'cash' the gold until I have the code. Meanwhile, they will want to see that the gold is at least there, even if they can't cash it yet. Is there a way to send a 'release' to an eGold (or other) payment? Better yet, a double simultaneous release feature makes thing even more interesting. In the world of international trade, where mutual distrust between buyer and seller is often the rule and there is no central authority to enforce the law, this is traditionally achieved by interposing not less than three trusted third parties: the shipping line, the opening bank and the negotiating bank. First, the buyer asks his bank to open an irrevocable letter of credit (L/C), which is a letter sent to the seller's bank instructing it to pay the seller once the latter presents a given set of documents: these usually include the bill of lading (B/L), issued by the shipping line to declare that the desired cargo was indeed loaded on board. The seller gets the letter of gredit from his bank and is now sure that he will be paid by the latter (which he trusts); so he purchases or manufactures the goods, delivers them to the shipping line getting the B/L, passes it together with the other documents to his bank, and draws the payment. The seller's bank sends by mail the documents to the buyer's bank (which it trusts due to long-standing business relationships), knowing that it will eventually receive the settlement money. The buyer's bank receives the documents, debits the buyer's account, remits the monies to the seller's bank, and delivers the documents to the buyer. When the ship arrives to the buye's seaport, the buyer goes to the shipping line, presents to it the B/L and in exchange gets the cargo (in sea shipments, the B/L represents title to the goods). I've been thinking about how to do this kind of thing with ecash. That's way trickier because there are no trusted third parties, not even e-gold Ltd. / GSR, Inc. The trust chain with the L/C works well because delegation of trust is unnecessary: every link in the chain bears responsibility only to its adjacent links. [...] In the case of your problem there is the issue of whether the source code you are buying is legitimate. Only once you have inspected it and satisfied yourself that it will suit your needs would you be willing to pay. But attaining that assurance will require examing the code in such detail that maybe you will decide that you don't need to pay. Interestingly, with L/C's this problem is addressed by involving yet another third party: an internationally-recognized inspection company (e.g., the Swiss SGS) that issues a document certifying that the cargo is indeed what the buyer expects and not, i.e., bricks. Banks and shipping lines don't want to get involved in these issues; the seller's bank will only check all the documents requested by the L/C (possibly including the inspection certificate). You could imagine a trusted third party who would inspect the code and certify it, saying the source code with hash XXX appears to be legitimate Cisco source code. Then they could send you the code bit by bit and incrementally show that it matches the specified hash, using a crypto protocol for gradual release of secrets. You could simultaneously do a gradual release of some payment information in the other direction. But it's hard to assess the value of partially-released code. If the gradual transfer bits-against-cents is aborted, what is left to the buyer is likely to be unusable, whereas the partial payment still represents good value. A more general issue is that source code is not a commodity, and intellectual property is not real property: so the traditional cash on delivery paradigm just doesn't work, and looking for protocols implementing it kind of moot. If the code is treated as trade secret, rather than licensed, an anonymous buyer may make copies and resell them on the black market more than recovering his initial cost, at the same time undercutting your legitimate sales (see e.g. the cases of RC4 and RC2). This can cause losses order of magnitude larger than refusing to pay for his copy. Enzo - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Can Skype be wiretapped by the authorities?
- Original Message - From: Bill Stewart [EMAIL PROTECTED] Sent: Sunday, May 09, 2004 12:44 PM Subject: Re: Can Skype be wiretapped by the authorities? [...] BUT, unfortunately, the implementation is closed source, so there are no guarantees that the software is not GAKked. Also no guarantee that it's not implemented sufficiently incompetently that the Authorities can't crack it if they want. Somebody else's message confirmed that there's a competence problem, though there may not be exploits. Or, not exploits we're aware of... [...] Skype uses a supernode structure to implement reflector service, so it doesn't have the same centralization problems. Right, that's precisely my point. Skype is showing us the way to go, although the security of the product may not be good enough (and being closed source, it's automatically untrusted). They don't document it well enough to know if it's possible to wiretap a message by using a corrupt supernode as MITM, but perhaps. It's frustrating that they use proprietary protocols for everything. That's understandable considering their business model. But I see Skype as a proof of feasibility for the real thing: an opensource application built on sound bases. Their audio codec, however, is developed by a reputable company (brain spacing out on their name, but I'd seen them before.) I've read that Skype uses an iLBC codec implemented by Global IP Sound. There is also an opensource implementation of it (www.ilbcfreeware.org), although its license contains weaselspeak clauses that I don't like very much: http://www.globalipsound.com/legal/licenses.php . Most of that company's codec designs are intended for boring telephony-style 4khz mono audio, 64kbps uncompressed, something small compressed, with really good loss/noise resistence, rather than doing 7kHz or 11kHz audio or stereo sound, but I don't know which codecs they've chosen. From what I've seen, Speex (www.speex.org) would represent a better choice, and is totally unencumbered. I believe that we are finally close to the point where all the bits and pieces for a secure, multiplatform, decentralized, opensource Internet phone + text IM are available, and it would only take some coding effort to put them to work together: - Codec: Speex (www.speex.org) - Portable audio interface layer: Portaudio (www.portaudio.com) - Bulk encryption and authentication: SRTP, now a standard-track protocol (RFC3711) and with an opensource reference implementation available at srtp.sourceforge.net . - Key exchange: authenticated D-H (how to perform the authentication, as I said, should be discussed: biometric is not viable if only the text chat feature is used, and multy-party conferencing calls for suitable extensions to the basic D-H scheme) - Directory and presence: any good P2P content-addressable scheme. Preserving some sort of interoperability with file-sharing applications would solve the bootstrapping problem (hundreds of thousands of nodes are already up and running), but the most popular networks (eMule, Overnet and ReverseConnect) are based on Kademlia, which is a Distributed Hash Table algorithm and therefore doesn't allow sorted access (useful, e.g., to locate the reflector with the largest available bandwidth). I recently discovered a few tree-based distributed algorithms which would allow just that: P-trees: http://techreports.library.cornell.edu:8081/Dienst/UI/1.0/Display/cul.cis/TR2004-1926 SkipGraphs: http://www.cs.yale.edu/homes/shah/html/pubs/skip-graphs.html P-Grid: http://www.p-grid.org Enzo - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Problems with GPG El Gamal signing keys?
- Original Message - From: Perry E.Metzger [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, November 27, 2003 7:24 AM Subject: Problems with GPG El Gamal signing keys? Some notes have been floating around claiming that there are bugs in GPG's use of El Gamal keys. For example, see: http://groups.google.com/groups?selm=E1AOvTM-0001nY-00%40alberti.g10code.deoe=UTF-8output=gplain Can anyone confirm these reports? There is an official announcement: http://lists.gnupg.org/pipermail/gnupg-announce/2003q4/000276.html Enzo - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Are there...one-way encryption algorithms
Amir and others, First, I'd like to thank all who have taken time to reply, either on- or off-list. All suggestions so far are related to public-key algorithms; I had myself thought about simply raising a generator g to the plaintext, or to a suitable injective function of the plaintext, in a GF(p): that doesn't even require a key to throw away. One drawback is that, with the possible exception of ECC-based methods, the minimum size of the cryptotext becomes larger than I'd like. Anyway, the intended use is for primary keys in transaction databases, in replacement of the PAN (a.k.a. credit card number). Using secure hashes is the usual way of doing such things, but the slight risk of collision, although practically negligible, is a bit irksome (especially considering that the plaintext is of fixed size, and therefore injectivity is not a priori impossible), and I was wondering if something better can be done. Enzo - Original Message - From: Amir Herzberg [EMAIL PROTECTED] To: 'Enzo Michelangeli' [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Sunday, November 16, 2003 10:44 PM Subject: RE: Are there...one-way encryption algorithms Enzo asked, Are there one-way encryption algorithms guaranteed to be injective (i.e., deterministically collision-free)? Or are there theoretical reasons against their existence? I'm looking for algorithms where every piece of code and data is public, thus excluding conventional enciphering with a secret key. Sounds like you look for One Way Permutations... which of course exist (if one-way functions do). But before we get into details, it'll be useful if you specify your needs more precisely since imprecision is the mother of weaknesses and break-ins. BTW I've updated my foils on encryption and hashing which cover much of this topic (see in site if interested). Best, Amir Herzberg http://amir.herzberg.name - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: blackmail / real world stego use
- Original Message - From: bear [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Wednesday, August 27, 2003 5:49 AM Subject: Re: blackmail / real world stego use [...] That would imply packet recording and correlation on a level greater than we've ever considered to be in the arsenal of cryptographic threats, implying the emergence of forces (and inevitably of forces other than governments) that have eavesdropping capabilities that cannot be defeated except with time-delayed packet relay through many hosts and re-encryption/ redecryption at each step of the way. That is a model that does not permit realtime communication, meaning that monitoring may be impossible to escape for realtime activities such as web browsing. That appears to be the conclusion reached by the developers of GNUnet: http://www.ovmj.org/GNUnet/faq.php3?xlang=English#GNUweb --- Q. Is it possible to use GNUnet via a browser as an anonymous WWW? A. There is currently no proxy (like fproxy in Freenet) for GNUnet that would make it accessible with a browser. It is possible to build such a proxy and all one needs to know is the protocol used between browser and proxy and a swift look at the sources in src/applications/afs/tools/. The real question is, whether or not this is a good idea. In order to achieve anonymity, GNUnet has a much higher latency than the WWW. Thus, the experience of browsing the web will usually be hindered significantly by these delays (potentially several minutes per page!). If you still want to write a proxy, you are welcome to send us code and join the developer team. --- Enzo - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
