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]
Re: Choosing an implementation language
- Original Message - From: "Tyler Close" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Saturday, October 04, 2003 4:31 AM Subject: Choosing an implementation language > On Thursday 02 October 2003 09:21, Jill Ramonsky wrote: > > I was thinking of doing a C++ implentation with classes and > > templates and stuff. (By contrast OpenSSL is a C > > implementation). Anyone got any thoughts on that? > > Given the nature of recent, and past, bugs discovered in the > OpenSSL implementation, it makes more sense to implement in a > memory-safe language, such as python, java or squeak. Using a VM > hosted language will limit the pool of possible users, but might > create a more loyal user base. I'd like to see an implementation written in a language that is memory-safe (I'm really sick of bugs related to buffer overflows) but easily embeddable in C applications, such as Ocaml or SmartEiffel. They seems to be also quite fast and memory-efficient, especially Ocaml (see e.g. http://www.bagley.org/~doug/shootout/ ). Enzo - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
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. 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: Are there...one-way encryption algorithms
Ah sure, that's why I said "irksome" and not "worrying" :-) It was more a curiosity of theoretical nature than a practical concern. Enzo - Original Message - From: "Sidney Markowitz" <[EMAIL PROTECTED]> To: "Enzo Michelangeli" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Tuesday, November 18, 2003 3:48 PM Subject: Re: Are there...one-way encryption algorithms > Enzo Michelangeli wrote: > > but the slight risk of collision, > > although practically negligible, is a bit irksome > > If you quantify the "practically negligible" risk, it might be less > irksome: SHA-1 is a 160 bit hash. The birthday paradox says that you > would need to hash 2^80 different credit card numbers before you had a > 50% probability of having even one collision in your database keys. Very > roughly that means you would need to have a trillion different credit > card numbers in your database in order to get as much as a one in a > trillion chance of a collision. You would probably find dealing with a > trillion different credit card numbers more irksome than the negligible > chance of a collision even that many would give you. > > -- sidney > - 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.de&oe=UTF-8&output=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: Can Skype be wiretapped by the authorities?
- Original Message - From: "Axel H Horns" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday, April 28, 2004 4:49 AM Subject: Can Skype be wiretapped by the authorities? > Is something known about the details of the crypto protocol within > Skype? How reliable is the encryption? > > See e.g. > > http://www.financialcryptography.com/mt/archives/76.html > > Can Skype be wiretapped by the authorities? With collaboration of the > Skype operator? Without? What do you mean with "operator"? AFAIK, the system is fully peer-to-peer (http://www.skype.com/skype_p2pexplained.html ). Regarding the crypto, at http://www.skype.com/help_faq.html#Technical they say: What type of encryption is used? Skype uses AES (Advanced Encryption Standard) - also known as Rijndel - which is also used by U.S. Government organizations to protect sensitive, information. Skype uses 256-bit encryption, which has a total of 1.1 x 1077 possible keys, in order to actively encrypt the data in each Skype call or instant message. Skype uses 1536 to 2048 bit RSA to negotiate symmetric AES keys. User public keys are certified by Skype server at login. OK, so "Rijndael" is misspelled and the RSA-based key exchange does not provide forward secrecy, but apart from that it doesn't smell like snake oil. Not too bad, at least. BUT, unfortunately, the implementation is closed source, so there are no guarantees that the software is not GAKked. And yes, definitely an opensource (and multiplatform) alternative would be a cool thing to have. A message I posted a while ago to the list p2p-hackers was reposted by Eugene Leitl to cypherpunks (http://www.mail-archive.com/[EMAIL PROTECTED]/msg81814.html ) but the couple of followups it elicited didn't seem to center the issues I raised. I didn't reply then because I'm not a subscriber of cypherpunks any longer, so I'd like to take this occasion for doing it here now: Major Variola (ret) commented (indented lines, followed by my comment): [...] >Skype claims to use RSA-based key exchange, which is good for >multi-party conferencing but does not preserve forward secrecy. >Maybe some variant of ephemeral D-H authenticated by RSA >signatures, with transparent renegotiation every time someone >joins the conference, could do the job better. RSA (ie persistant keys) may be an option but MUST NOT be required, for secrecy reasons as mentioned. (At worst RSA keys can be used once, then discarded. Lots of primes out there :-) Well, I don't see why RSA signatures (only for authentication of the key exchange) could endanger forward secrecy. Also, this is *voice*, ie biometric auth, so public-key-web-o-trust verislime scam is unnecessary at best. It's not only voice, it's also IM-style text chat. And even with voice, biometric authentication becomes awkward to use with conference calls. [...] >One could always implement a brand new >network, using Distributed Hash Table algorithms such as Chord or >Kademlia, We don't give a flying fuck as to which shiny new algorithm you use, although were we a graph theory wonk, we might care. The issue here is that DHT algorithms allow to implement a fully distributed directory, which means one much more resistant to attacks (especially from institutional attackers) than implementations based on centralized servers (see, in a related fild, the different destinies of Napster and its distributed successors such as Overnet or the less efficient Gnutella). Still, a full search takes O(log(n)) steps, making them practical for implementing directory/presence services. [...] >but it would be much easier to rely from the very beginning upon >a large number of nodes (at least for directory and presence >functionality, if not for the reflectors which require specific >UDP code). What the NAT world (yawn) needs is free registry services exploitable by any protocol. Those NAT-users with RSA-clue can sign their registry entry. Not only that: NATted agents cannot be "called" unless they first register with some reflector on the open Internet. And centralized reflectors are, again, easy to attack, and also expensive to operate, as the bandwidth requirements are substantial (all the traffic flows through them): see e.g. John Walker's analysis of the reasons that led him to abandon SpeakFreely at http://www.fourmilab.ch/speakfree/ . Thomas Shaddack suggested to leverage on Jabber, but: 1. Jabber uses TCP as transport, and therefore can't be efficiently used as transport for telephony, i.e. using encapsulation of the voice packets in the Jabber protocol in order to traverse NAT devices. 2. Jabber is based on a client-server paradigm similar to e-mail. Running a Jabber server requires an always-on machine with its own domain name; and, although dynamic DNS can help, the model again tend to be hierarchical, easy to attack etc. That pretty much rules it out also for session initiation, directory/presence etc. The beauty of Skype, encry
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: Using crypto against Phishing, Spoofing and Spamming...
Can someone explain me how the "phishermen" escape identification and prosecution? Gaining online access to someone's account allows, at most, to execute wire transfers to other bank accounts: but in these days anonymous accounts are not exactly easy to get in any country, and anyway any bank large enough to be part of the SWIFT network would cooperate in the resolution of obviously criminal cases. Enzo - Original Message - From: "Ian Grigg" <[EMAIL PROTECTED]> To: "Florian Weimer" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Sunday, July 18, 2004 1:51 AM Subject: Re: Using crypto against Phishing, Spoofing and Spamming... > > At 10:46 AM 7/10/2004, Florian Weimer wrote: > > > >> But is it so harmful? How much money is lost in a typical phishing > >> attack against a large US bank, or PayPal? (I mean direct losses due > >> to partially rolled back transactions, not indirect losses because of > >> bad press or customer feeling insecure.) > > I estimated phishing losses about a month ago at about > a GigaBuck. > > http://www.financialcryptography.com/mt/archives/000159.html > > You'll also see two other numbers in that blog entry, > being $5 billion and $400 million (the latter taken > from Lynn's posted articles). > > Of course these figures are very delicate, so we need > to wait a bit to get the real damage with any degree > of reliability. Scientific skepticism should abound. > > Notwithstanding that, I would suggest that the money > already lost is in excess of the amount paid out to > Certificate Authorities for secure ecommerce certificates > (somewhere around $100 million I guess) to date. As > predicted, the CA-signed certificate missed the mark, > secure browsing is not secure, and the continued > resistance against revision of the browser's useless > padlock display is the barrier to addressing phishing. > > iang > > - > 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: 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. / G&SR, 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: 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: SSL/TLS passive sniffing
- Original Message - From: "Andy Isaacson" <[EMAIL PROTECTED]> To: "Florian Weimer" <[EMAIL PROTECTED]> Cc: Sent: Saturday, December 25, 2004 4:56 AM Subject: Re: SSL/TLS passive sniffing > On Wed, Dec 22, 2004 at 07:43:13PM +0100, Florian Weimer wrote: [...] > > > Actually reasoning along these lines is why Lutz Jaenicke > > > implemented PRNGD, it is strongly recommended (at least by me) > > > that mail servers use PRNGD or similar. PRNGD delivers > > > psuedo-random numbers mixing in real entropy periodically. > > That's basically what /dev/urandom does, no? (Except that it has the > undesirable side-effect of depleting the entropy estimate maintained > inside the kernel.) 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. As entropy is a measure of the information we don't have about the internal state of a system, 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. 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 PRNG’s 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: entropy depletion (was: SSL/TLS passive sniffing)
- Original Message - From: <[EMAIL PROTECTED]> To: 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: Simson Garfinkel analyses Skype - Open Society Institute
- Original Message - From: "Adam Shostack" <[EMAIL PROTECTED]> To: "David Wagner" <[EMAIL PROTECTED]> Cc: Sent: Saturday, January 29, 2005 1:48 AM Subject: Re: Simson Garfinkel analyses Skype - Open Society Institute [...] > The 'vastly more secure' is not my claim. My claim is that it is > somewhat better. Even if it's using an RC4 key of all-zeros, it is > somewhat better than what I have today, because today, my voip calls > don't even have that, and as far as I can see, I can use asterisk's > codec translator API to turn tcpdump captured streams into mp3. > (http://www.asterisk.org/index.php?menu=architecture). The effort to > get skype data is slightly higher. Until shown otherwise, I expect a > grad student could do it in a weekend. However, that same grad > student could build me a wiretap for VOIP in an hour. (By which > metric, Skype is nearly 50x as secure :) [...] > I hate arguing by analogy, but: VOIP is a perfectly smooth system. > It's lack of security features mean there isn't even a ridge to trip > you up as you wiretap. Skype has some ridge. It may turn out that > it's very very low, but its there. Even if that's just the addition > of an openssl decrypt line to a reconstruct shell script. Actually it's not that bad: using SIP, the RTP packets can be protected by SRTP (RFC3711, with an opensource implementation from Cisco at http://srtp.sourceforge.net/ ) and the SIP signalling, as per RFC2246, can go over TLS. It's more an issue of deployment than standards, possibly due to CALEA-related pressures on service providers, but some manufacturers of hardware do support VoIP security: see e.g. what is claimed at http://www.snom.com/phones.html?&L=1 . Enzo - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: I'll show you mine if you show me, er, mine
- Original Message - From: "James A. Donald" <[EMAIL PROTECTED]> To: ; <[EMAIL PROTECTED]> Sent: Wednesday, March 09, 2005 4:25 AM [...] > > > However, techniques that establish that the parties share a > > > weak secret without leaking that secret have been around > > > for years -- Bellovin and Merritt's DH-EKE, David Jablon's > > > SPEKE. And they don't require either party to send the > > > password itself at the end. > > > They are heavily patent laden, although untested last time I > > looked. This has been discouraging to implementers. > > There seem to be a shitload of protocols, in addition to SPEKE > and DH-EKE > > A password protocol should have the following properties: > > 1. It should identify both parties to each other, that is to > say, be secure against replay and man in the middle attacks, in > particular, strong against phishing.. It should be secure > against replay and dictionary attacks by an evesdropper or > man-in-the-middle. Such an attacker should be able to no > better than someone who just tries repeatedly to log on to the > server with a guessed password > > 2. It should be as strong as practical against offline attacks > by the server itself. The server operators, or someone who has > stolen information from them, should not know the users > password, and dictionary attacks should be sufficiently > expensive that a strong password (not your ordinary password) > is secure. > > Can anyone suggest a well reviewed, unpatented, protocol that > has the desired properties? SRP ? It's patented, but available under a royalty-free BSD-style license: http://srp.stanford.edu/license.txt . 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]>; 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: 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]>; 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: Clearing sensitive in-memory data in perl
- Original Message - From: "Perry E. Metzger" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Cc: Sent: Tuesday, September 13, 2005 11:32 PM Subject: Re: Clearing sensitive in-memory data in perl [...] > What the world really needs is something between C++ and C -- a > language with very clean obvious semantics (like C) which does run > time bounds checking and strong typing, though it also needs explicit > escapes in the type system so you can write things like device drivers > in it. It probably also should not require run time garbage > collection, if only so kernel code can be written in it. D aims for that status: http://www.digitalmars.com/d/comparison.html http://www.digitalmars.com/d/sdwest/ On the paper, it looks excellent, and efficient too: http://shootout.alioth.debian.org/benchmark.php?test=all&lang=dlang&lang2=dlang&sort=fullcpu Garbage collection can be avoided, when desired: http://www.digitalmars.com/d/memory.html A frontend for gcc is available (even ported to Cygwin). Enzo - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
