Re: [Cryptography] AES-256- More NIST-y? paranoia
On Oct 4, 2013, at 12:20 PM, Ray Dillinger wrote: So, it seems that instead of AES256(key) the cipher in practice should be AES256(SHA256(key)). Is it not the case that (assuming SHA256 is not broken) this defines a cipher effectively immune to the related-key attack? So you're essentially saying that AES would be stronger if it had a different key schedule? At 08:59 AM 10/5/2013, Jerry Leichter wrote: - If this is the primitive black box that does a single block encryption, you've about doubled the cost and you've got this messy combined thing you probably won't want to call a primitive. You've doubled the cost of key scheduling, but usually that's more like one-time than per-packet. If the hash is complex, you might have also doubled the cost of silicon for embedded apps, which is more of a problem. - If you say well, I'll take the overall key and replace it by its hash, you're defining a (probably good) protocol. But once you're defining a protocol, you might as well just specify random keys and forget about the hash. I'd expect that the point of related-key attacks is to find weaknesses in key scheduling that are exposed by deliberately NOT using random keys when the protocol's authors wanted you to use them. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] TLS2
At 02:27 PM 9/30/2013, James A. Donald wrote: On 2013-09-30 18:02, Adam Back wrote: If we're going to do that I vote no ASN.1, and no X.509. Just BNF format like the base SSL protocol; Granted that ASN.1 is incomprehensible and horrid, but, since there is an ASN.1 compiler that generates C code we should not need to comprehend it. Unfortunately, you have to be able to comprehend all of the failure modes and attacks on ASN.1. The object descriptions themselves are a bit bloaty, with their main weakness being that either you have to get permission to attach your data into the official tree, or else do a vendor-specific branch, but they're not all that broken. It's the data representations that map them into binary strings that are a wretched hive of scum and villainy, particularly because you can't depend on a bit string being able to map back into any well-defined ASN.1 object or even any limited size of ASN.1 object that won't smash your stack or heap. The industry's been bitten before by a widely available open source library that turned out to be vulnerable to maliciously crafted binary strings that could be passed around as SNMP traps or other ASN.1-using messages. Similarly, PGP's most serious security bugs were related to variable-length binary representations that were trying to steal bits to maximize data compression at the risk of ambiguity. Scrounging a few bits here and there just isn't worth it. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Thoughts on hardware randomness sources
At 08:32 PM 9/13/2013, Jerry Leichter wrote: If by server you mean one of those things in a rack at Amazon or Google or Rackspace - power consumption, and its consequence, cooling - is *the* major issue these days. Also, the servers used in such data centers don't have multiple free USB inputs - they may not have any. More to the point, the servers in the data centers aren't going to let you plug things in to them, especially if you're just renting a virtual machine or cloud minutes and don't get to connect to the real hardware at all (which also means you're not going to be able to use disk drive timing.) A tablet computer has lots of sensors in it; even turning the cameras on at boot time and hashing the raw pixels should give you a reasonable chunk of entropy; you're not going to turn your virtual machine upside down and shake it like an Etch-A-Sketch. I realize it's possible for somebody to try to manipulate this, but I've always assumed that ethernet packet timing ought to give you some entropy even so, and even though with virtual machines you may only get quantized versions of interrupt times. Startup processes are probably going to include pinging a router and a name server, or at least they could if you wanted. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] People should turn on PFS in TLS (was Re: Fwd: NYTimes.com: N.S.A. Foils Much Internet Encryption)
At 10:39 AM 9/11/2013, Phillip Hallam-Baker wrote: Perfect Forward Secrecy is not perfect. In fact it is no better than regular public key. The only difference is that if the public key system is cracked then with PFS the attacker has to break every single key exchange and not just the keys in the certificates and if you use an RSA outer with an ECC inner then you double the cryptanalytic cost of the attack (theory as well as computation). I wouldn't mind if it had been called Pretty Good Forward Secrecy instead, but it really is a lot better than regular public key. The main difference is that cracking PFS requires breaking every single key exchange before the attack using cryptanalysis, while cracking the RSA or ECC outer layer can be done by compromising the stored private key, which is far easier to do using subpoenas or malware or rubber hoses than cryptanalysis. (Of course, any messages that were saved by the sender or recipient can still be cracked by non-cryptanalytic techniques as well, but that's a separate problem.) ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Bruce Schneier has gotten seriously spooked
At 12:09 PM 9/7/2013, Chris Palmer wrote: On Sat, Sep 7, 2013 at 1:33 AM, Brian Gladman b...@gladman.plus.com wrote: Why would they perform the attack only for encryption software? They could compromise people's laptops by spiking any popular app. Because NSA and GCHQ are much more interested in attacking communictions in transit rather than attacking endpoints. So they spike a popular download (security-related apps are less likely to be popular) with a tiny malware add-on that scans every file that it can read to see if it's an encryption key, cookie, password More to the point, spike a popular download with remote-execution malware, and download spiked patches for important binaries, so the not-a-collection-target's browser uses known keys (the opposite of the fortify patch that made 40-bit Mozilla do 128-bit), and the disk encryption software broadcasts its keys or stashes them in plaintext ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] In the face of cooperative end-points, PFS doesn't help
At 06:49 PM 9/6/2013, Marcus D. Leech wrote: It seems to me that while PFS is an excellent back-stop against NSA having/deriving a website RSA key, it does *nothing* to prevent the kind of cooperative endpoint scenario that I've seen discussed in other forums, prompted by the latest revelations about what NSA has been up to. But if your fave website (gmail, your bank, etc) is disclosing the session-key(s) to the NSA, Depends a lot on how cooperative they are. It's much easier to get a subpoena/secret-order/etc. for business records that a company keeps, which may include the long-term key, than to get one for transient session keys that their software doesn't keep. Doesn't mean they can't do it, but it's probably much easier to get an order to produce plaintext, especially for a company like a bank or email service where the plaintext is something they would be keeping, at least briefly, as a business record anyway. Do we now strongly suspect that NSA have a flotilla of TWIRL (or similar) machines, so that active cooperation of websites isn't strictly necessary to derive their (weaker) RSA secret keys? Unlikely - the economics are still strongly against that. Keeping a fleet of key cracking machines to grab long-term private keys from high-value targets might make sense, but each long-term key gets used to protect thousands or millions of transient session keys. If they have 1024-bit RSA crackers at all, unless there's been a radical breakthrough in factoring, they're still not fast. I've always preferred RSA-signed Diffie-Hellmann to encrypted session-key transfer when it's practical. The long-term keys only get used for signatures, so if they're compromised they can only be used to impersonate the endpoints, not to read previous sessions, and under less-than-NSA versions of due process, it's a lot easier to argue in court against a police agency that wants to impersonate you than one that wants a copy of a transaction. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Why prefer symmetric crypto over public key crypto?
On 7/09/13 09:05 AM, Jaap-Henk Hoepman wrote: Public-key cryptography is less well-understood than symmetric-key cryptography. It is also tetchier than symmetric-key crypto, and if you pay attention to us talking about issues with nonces, counters, IVs, chaining modes, and all that, you see that saying that it's tetchier than that is a warning indeed. You have the same issues with nonces, counters, etc. with symmetric crypto so I don't see how that makes it preferable over public key crypto. At 12:57 AM 9/7/2013, ianG wrote: It's a big picture thing. At the end of the day, symmetric crypto is something that good software engineers can master, and relatively well, in a black box sense. Public key crypto not so easily, that requires real learning. I for one am terrified of it. Public-key crypto requires learning math, and math is hard (or at least ECC math is hard, and even prime-number-group math has some interesting tricks in it.) Symmetric-key crypto is easy in a black-box sense, because most algorithms come with rules that say You need to do this and not do that, yet the original PPTP did half a dozen things wrong with RC4 even though the only rule is never use the same state twice. But if you want to look inside the black box, most of what's there is a lot of bit-twiddling, maybe in a Feistel network, and while you can follow the bits around and see what changes, there can still be surprises like the discovery of differential cryptanalysis. Public-key crypto lets you use math to do the analysis, but [vast over-simplification] symmetric-key mostly lets you play around and decide if it's messy enough that you can't follow the bits. But there are other traps that affect people with either kind of system. Once PGP got past the Bass-o-matic stage, the biggest security problems were mostly things like variable-precision numbers that were trying so hard to save bits that you could trick the program into interpreting them differently and accepting bogus information. Fortunately we'd never have problems like that today (yes, ASN.1 BER/DER, I'm looking at you), and nobody ever forgets to check array bounds (harder in modern languages than in C or Fortran, but still quite possible), or fails to validate input before using it (SQL injections), etc. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] FIPS, NIST and ITAR questions
At 03:06 PM 9/3/2013, Jerry Leichter wrote: On Sep 3, 2013, at 3:16 PM, Faré fah...@gmail.com wrote: Can't you trivially transform a hash into a PRNG, a PRNG into a cypher, and vice versa? No. [...] I don't actually know if there exists a construction of a PRNG from a cryptographically secure hash function. (You can build a MAC, but even that's not trivial; people tried all kinds of things that failed until the HMAC construction was proven correct.) PRNG is not necessarily a cryptographically strong term. But isn't counter-mode hash likely to be ok? Counter = seed; while (counter++) Output(Hash(counter)); // or as somebody said Output(Hash(seed||counter||seed)); // and you probably need to pad it to be long enough for the hash to be happy. Obviously if somebody discovers the seed the whole thing is toast. And you can turn the PRNG into a stream cypher by doing plaintext[x] xor PRNG[x], with the usual limitations. None of that has any bearing on ITAR, of course. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] IPv6 and IPSEC
At 01:53 PM 8/29/2013, Taral wrote: Oh, wait. I misread the requirement. This is a pretty normal requirement -- your reverse DNS has to be valid. So if you are 3ffe::2, and that reverses to abc.example.com, then abc.example.com better resolve to 3ffe::2. For IPv4, that's a relatively normal way to do things, though if example.com is commercial, smtp.example.com might actually be a load-balanced bunch of servers in xx.yy.zz.0/24 instead of just one machine, or they might be hidden behind NAT. But with IPv6 privacy extensions, a single machine might be using pseudorandomly-generated addresses in a /64 subnet, so you'd have to do some kind of wildcarding to represent it as a single name. Also, residential vs. commercial is a much fuzzier boundary for IPv6; an IPv6 machine might be a VM tunnelling to Hurricane Electric over IPv4, or tunnelled from a residence to a DSL ISP that can only do telco DSL at IPv4. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Using Raspberry Pis
Custom built hardware will probably be the smartest way to go for an entrepreneur trying to sell these in bulk to people as home gateways anyway Meanwhile, while Phill may have spent $25 for a USB Ethernet, I frequently see them on sale for $10 and sometimes $5. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: Haystack (helping dissidents?)
cryptography@metzdowd.com On Thu, Sep 16, 2010 at 04:49:19PM +, M.R. wrote: | I said (something like) this when Haystack first appeared on this | list... | | Words dissidents and oppressive regimes have no place in | serious discussions among cryptographers. Once we start assigning | ethical categorizations to those that protect and those that attack | (data files, communications channels, etc.) we are watering the | garden in which the weeds like Haystack flourish. They do tell you what level of attack you're trying to block. There's spammers trying to crack your system for money, but then there's a national government that doesn't like you, though I suppose it's possible that if you're not annoying one of the top ten governments, you might get a larger attack by annoying 4chan. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Stanford 10/7/2010 -- Lessons from the Haystack Affair
Potentially interesting lecture if you're in the Bay Area From: alli...@stanford.edu Reply-To: alli...@stanford.edu Subject: Liberation Technology 10/7/2010 -- Lessons from the Haystack Affair Date: Mon, 27 Sep 2010 13:40:55 -0700 (PDT) STANFORD FREEMAN SPOGLI INSTITUTE FOR INTERNATIONAL STUDIES The Stanford Program on Liberation Technology Seminar Series is starting up again. The first of the series will be held on Sept 23, 4:30pm at Wallenberg Hall. As an EE380 attendee you may find this series of lectures at the cust of Computer Science, Electrical Engineering, and Social Science his stimulating and informative series. Lessons from the Haystack Affair October 7, 2010 4:30 PM - 6:00 PM Wallenberg Theater Wallenberg Hall 450 Serra Mall, Building 160 Abstract Haystack, a circumvention tool, emerged in the wake of the repression after the Iranian election of June 2009. After achieving considerable public prominence, its use and distribution was recently halted. Important questions have been raised about Haystack's effectiveness and security, as well as the roots of its reputation. Evgeny Morozov, who emerged as a leading critic of Haystack, and Daniel Colascione, who wrote the Haystack code, will discuss the Haystack experience and the lessons it carries for circumvention technologies and, more broadly, for the evaluation and political deployment of new information technologies. Daniel Colascione co-founded the Censorship Research Center in June 2009 in the aftermath of the Iranian election and has had a lifelong interest in internet freedom and technological measures to mitigate censorship. He created the Haystack anti-censorship system and holds a BSc in Computer Science from the SUNY University at Buffalo. Speaker Evgeny Morozov is a leading thinker and commentator on the political impact of the Internet and a well known opponent of internet utopianism. He is a contributing editor to Foreign Policy and runs the magazine's Net Effect blog about the Internet's impact on global politics. Evgeny is currently a Yahoo! fellow at the Institute for the Study of Diplomacy at Georgetown University. Prior to his appointment to Georgetown, he was a fellow at the Open Society Institute, where he remains on the board of the Information Program. Before moving to the US, Evgeny was based in Berlin and Prague, where he was Director of New Media at Transitions Online, a media development NGO active in 29 countries of the former Soviet bloc. He is writing a book about the Internet and democracy, to be published this fall by Public Affairs. Open to the public No RSVP required For more information on the Program on Liberation Technology go to- http://liberationtechnology.stanford.edu/ - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: 2048-bit RSA keys
At 01:54 PM 8/16/2010, Perry E. Metzger wrote: On Mon, 16 Aug 2010 12:42:41 -0700 Paul Hoffman paul.hoff...@vpnc.org wrote: At 11:35 AM +1000 8/16/10, Arash Partow wrote: Just out of curiosity, assuming the optimal use of today's best of breed factoring algorithms - will there be enough energy in our solar system to factorize a 2048-bit RSA integer? We have no idea. The methods used to factor number continue to slowly get better,[...] He asked about today's best of breed algorithms, not future ones. In that context, and assuming today's most energy efficient processors rather than theoretical future processors, the question has a concrete answer. With today's best-of-breed algorithms and hardware designs, there isn't enough money in the economy to build a machine that comes close to making a scratch in the surface of that kind of energy consumption, whether for factoring or for simple destruction. Basically, 2048's safe with current hardware until we get some radical breakthrough like P==NP or useful quantum computers, and if we develop hardware radical enough to use a significant fraction of the solar output, we'll probably find it much easier to eavesdrop on the computers we're trying to attack than to crack the crypto. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: A mighty fortress is our PKI, Part II
At 07:16 AM 7/28/2010, Ben Laurie wrote: SSH does appear to have got away without revocation, though the nature of the system is s.t. if I really wanted to revoke I could almost always contact the users and tell them in person. This doesn't scale very well to SSL-style systems. Unfortunately, there _are_ ways that it can scale adequately. Bank of America has ~50 million customers, so J. Random Spammer sends out 500 million emails saying Bank of America is updating our security procedures, please click on the following link to update your browser. It's more efficient for BofA to send out the message themselves, only to actual subscribers, with the actual keys, helping to train them to accept phishing mail in the process, but apparently even doing it the hard way scales well enough for some people to make money. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Possibly questionable security decisions in DNS root management
At 12:14 PM 10/22/2009, David Wagner wrote: Back to DNSSEC: The original criticism was that DNSSEC has covert channels. So what? If you're connected to the Internet, covert channels are a fact of life, DNSSEC or no. The added risk due to any covert channels that DNSSEC may enable is somewhere between negligible and none, as far as I can tell. So I don't understand that criticism. I thought it was also that DSA had covert channels, but I also don't see why that's as relevant here, and I share Dave's skepticism about threat models. It's unlikely that DNSSEC will let you do anything any more heinous than Dan Kaminsky's streaming-video-over-DNS hacks have already done. There are two obvious places that data can be leaked - the initial key signature process, and the DNS client/server process. If the people who certify the root or TLDs can't be trusted, the number of those people is small enough that they can simply send the secret data to their unindicted co-conspirators without all the trouble of hiding it in a covert channel on a very public DNS server. And if Bad Guys have compromised the software used in a DNS server, while they could be subtle and hide data in DSA signatures of DNS records, it would be much easier to just send it as data if the query has the evil bit set or asks for covertchannel1.com or whatever. There's plenty of room in the formats even without DSA. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: XML signature HMAC truncation authentication bypass
At 05:11 PM 7/27/2009, Jon Callas wrote: By the way, do you think it's safe to phase out MD5? That will break all the PGP 2 users. Depends - if you're only replacing it with SHA-1, it's probably not worthwhile.. And if you're breaking things anyway, might as well replace most of the bit-twiddling variable-length number field types with 32-bit-word-aligned types, but nobody listened to me rant about that a decade ago :-) - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Proof of Work - atmospheric carbon
At 10:40 AM 1/30/2009, Thomas Coppi wrote: Just out of curiosity, does anyone happen to know of any documented examples of a botnet being used for something more interesting than just sending spam or DDoS? There are good botnets and bad botnets. Good ones ask you if you want to join, bad ones don't. Good ones are typically things like s...@home, fold...@home, Great Internet Mersenne Prime Search, DES crackers, etc., and if you've got something good to do, people will help. People usually only set up the bad ones if they want to do something bad - it may be interesting the first time they do it, like a new flavor of DDOS, but it's not usually doing the world any favors. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: the skein hash function
Eugen Leitl and Stephan Somogyi [EMAIL PROTECTED] wrote about the Skein hash function announcement. http://www.schneier.com/blog/archives/2008/10/the_skein_hash.html?1 http://www.schneier.com/skein.html One thing I noticed on a first read-through was a discussion of speed for ASICs vs. general CPUs. Their implementation on CPUs was about 4 Gbps/core, and their estimate of ASIC speed was about 5 Gbps using about 80K gates worth of ASIC, and their hash-tree mode makes parallelization efficient. Their conclusion was that ASICs don't give you much of a speedup, but may save power or cost. A quick google-look at ASICs showed a number in the range of 300K-20M gates, so hash-trees could probably get speedups of up to 20-100x if you can keep from becoming input-speed-bound. The 300K chips were about $6, 5M at $50 and 350MHz, which is somewhat faster than the Skein team estimate, and some of the denser chips didn't mention price but were starting to use 45nm technology. So if Skein becomes popular, ASIC accelerator hardware may be practical for higher-speed applications. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: combining entropy
This isn't enough. Somehow, you have to state that the values emitted on demand in any given round i (where a round consists of exactly one demand on all N member and produces a single output result) cannot receive any input from any other members. Otherwise, if N=2 and member 0 produces true random values that member 1 can see before it responds to the demand it received, then member 1 can cause the final result to be anything it likes. In the case of malicious members who can snoop the inputs, Mal can get any result he wants if the combining function is XOR (or, with slightly more work, if it's a non-cryptographic checksum.) But if your combining function is a cryptographic hash, it's computationally difficult to do. However, even a hash isn't always enough - consider the case where the application of the random numbers only uses k of the N bits, and the attacker has enough time to try out 2**k (waving hands roughly here) different cases. So you may still need to design your protocols carefully. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: On the randomness of DNS
Ben wrote: But just how GREAT is that, really? Well, we don' t know. Why? Because there isn't actually a way test for randomness. Your DNS resolver could be using some easily predicted random number generator like, say, a linear congruential one, as is common in the rand() library function, but DNS-OARC would still say it was GREAT. At 11:57 AM 7/30/2008, Pierre-Evariste Dagand wrote: Well, they are some tests to judge the quality of a random number generator. The best known being the Diehard tests: Random number quality is contextual. In this case, for 95-99% of the market, the real test is between Patched Badly Broken Not patched yet Didn't need patching, and if you'd prefer the term Best we can do until DNSSEC instead of GREAT I won't be the one to argue with you. There are some other possible conditions, like Rolled their own with open source, badly or Maliciously subtle malware DNS resolver. The latter is way too much work compared to cruder approaches (like targeting queries directly to your evil DNS server). The former is not too common, though it probably exists, but once most systems get patched, it may not be a big enough target to interest crackers. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Toshiba shows 2Mbps hardware RNG
At 07:02 PM 2/9/2008, Peter Gutmann wrote: I've always wondered why RNG speed is such a big deal for anything but a few highly specialised applications. For security use you've got two options: 1. Use it with standard security protocols, in which case you need all of 128 or so bits every now and then (and very rarely a few thousand bits for asymmetric keygen). One obvious application I can think of is Diffie-Hellman session key generation for web or email servers that handle lots of sessions. Sure, you _could_ use PRNGs to generate the keys, with real RNG now and then, but a fast RNG can help protect you against one popular threat model, which is auditors. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Changes in Russian licensing of cryptraghical tools
At 12:23 AM 1/20/2008, Alexander Klimov wrote: Given what is required to get a license (for example, 4.b in the first document, says that one must have people trained in information security), I guess the new law is not supposed to limit use of cryptography by ordinary people, but to limit distribution of snake-oil by self-proclaimed professionals. I would have guessed the opposite - it's designed to prevent customized encryption solutions that actually work, but not to prevent mass-market products. Since you don't need a license for totally inadequate crypto, you can still sell snake-oil customized for your users. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Botnets on Unix
At 11:04 AM 1/18/2008, Ray Dillinger wrote: More than half the servers on the Internet - the very most desirable machines for botnet operators, because they have huge storage and huge bandwidth - run some form of Unix, and yet, since 1981 and the Morris Worm, you've never heard of a botnet composed of Unix machines! Of course there've been Unix botnets, though most of them were a few years ago and not as tightly integrated as the current ones (or as the Morris worm, which was in 1988.) Stacheldraht was a DDOS tool from ~1999 running in Linux and Solaris; it was related to Trinoo and Tribe Flood Network which had similar features, but I'm not sure what OS those ran on. http://staff.washington.edu/dittrich/misc/stacheldraht.analysis says there were several thousand machines running it. I found it running on a RedHat 6 machine in my lab a few years back, chatting away with a university machine in Sweden. It had broken in through a wu-ftpd hole, so it was appropriate that the next time somebody broke into that machine the botnet controller was from Washington University. Another attack looked like it was from MIT, but Jeff Schiller said it was actually from somebody in Japan that had byte order problems in the target IP address, so it was probably a Sparc machine. In contrast, nobody ever bothered the Win95 machine on the same DSL circuit, but it wasn't running any servers. Both of them were running on 60-75 MHz Pentium hardware. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: 2008: The year of hack the vote?
Dan wrote: Let's not do this or we'll have to talk about JF Kennedy who, at least, bought his votes with real money. That's because Democrats had become more professional, and the tradition of buying votes with whiskey only works for the retail level, not wholesale. Dan also wrote: May I point out that if voting systems have a level of flaw that says only an idiot would use them, then how can you explain electronic commerce, FaceBook, or gambling sites? More people use just those three than will *ever* vote. The primary threats of electronic voting machines aren't to the individual voter, who can slightly increase the chances of getting his/her vote counted accurately by insisting on paper ballots, but to the aggregate vote count, which can be hacked if the precinct has _any_ electronic machines. The big problem in Ohio appears to have been Denial of Service - not that there weren't lots of other problems, but electronic voting systems have sufficient complexity that an elections department can arrange to have enough missing parts or supplies or passwords or powercords or whatever in demographically appropriate precincts so that the results get skewed even without Other Technical Means. Some of the black inner-city precincts had two-hour lines (on a rainy day), while white Republican-leaning precincts had all the equipment they needed. (Also, if you're saying only an idiot would use it and ask how gambling sites exist, the answer is that only idiots gamble... As Ed Gerck pointed out, risk in e-commerce can be managed and amortized into the price, but that doesn't work for voting.) - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: Trillian Secure IM
| Which is by the way exactly the case with SecureIM. How | hard is it to brute-force 128-bit DH ? My guesstimate | is it's an order of minutes or even seconds, depending | on CPU resources. Sun's Secure NFS product from the 1980s had 192-bit Diffie-Hellman, and a comment in one of the O'Reilly NFS books says that However, by 1990, advances in RISC processors produced workstation machines that could, by brute force, derive the private key from any public key in under a day. but that in 1987 there were still a lot of Motorola 68010 machines that took several minutes to generate keys so they didn't want it longer. I'm guessing that a 1990 RISC machine was around 50 MIPS, so it's maybe 1/100 the speed of a modern single-core CPU. 128-bit DH sounds like as good a decision as using 40-bit RC4 keys would be today. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: How the Greek cellphone network was tapped.
At 07:37 AM 7/12/2007, Eric Cronin wrote: With current CPUs and audio codecs you can get decent voice quality over 9600bps. Yes and no. There are lots of 8kbps codecs, and some 6.5 and 5.3kbps codecs, all off which give acceptable voice quality if transmission's ok. (And you can reduce average transmission rates by 40-50% with silence suppression.) However, that's the raw codec rate - if you're taking the VOIP packets, wrapping them in RTP, UDP, and IP headers, and then transmitting them on a layer 2 protocol with as little overhead as PPP or Frame, the 8kbps becomes more like 26 kbps (Ethernet and ATM are worse, and DSL is ATM underneath - I'm not sure what the cellular carriers do for framing.) The problem is that the Voice-stream data packets are extremely small - the same headers don't add much overhead percentage when you're using 1500-byte data packets. In some environments you can do header compression to save about half the bandwidth, but in general you can't. The Asterisk IP PBX has a trunking protocol that lets you use one set of RTP/UDP/IP headers to carry multiple streams of voice packets, so you can connect two locations together for close to the raw protocol speeds, but that's not likely to apply to a mobile phone situation. The other way to avoid the VOIP overhead is to use one of the old voice-over-data designs that uses point-to-point async or sync connections without an IP layer (e.g. raw modems.) That lets you send voice for much closer to the 9600 bps (depending on sync protocol, async stop-bits, etc.) - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: How the Greek cellphone network was tapped.
At 10:59 PM 7/9/2007, Florian Weimer wrote: Uh-oh, no. The protocol characteristics don't change depending on who is selling you the device. Of course they do, at least in the US, where the mobile phones are generally carrier-specific, often locked, and generally don't have open designs. In particular, they're not usually designed to let the data applications get at the voice compression ASICs, but they usually don't have enough CPU to compress voice in Java if they can get at the voice stream at all. Some of the PDA phones are more flexible, and I'd expect OpenMoko to be much more flexible. Many telcos have an aversion to end-to-end protocols. They're getting better about it, but the transmission characteristics from most of the data protocols aren't designed for voice, unless you're willing to do push-to-talk or equivalent. So ironically, if you want to get good latency for 5.3kbps voice, you'll want the fastest data protocols. HSDPA's latency is 100-200ms, and upstream is 100+ kbps - you could probably run uncompressed voice which is about 80kbps, since latency's less of a problem. (EDGE has upstream of 40-60kbps, but latency is 350+ so the more compressed protocols aren't going to behave. I don't have the 1xRTT numbers handy, but I think they're similar.) - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Quantum Cryptography
At 08:51 AM 6/28/2007, Alexander Klimov wrote: I suspect there are two reasons for QKD to be still alive. First of all, the cost difference between quantum and normal approaches is so enormous that a lot of ignorant decision makers actually believe that they get something extra for this money. If you tell a lie big enough and keep repeating it, people will eventually come to believe it. The second reason is ``rollback'' (is it right term?): you pay Kickbacks would be the usual American term. $10 from your company funds to a QKD vendor, and they covertly give $5 back to you. Never attribute to malice what can be adequately explained by incompetence. Quantum Crypto is shiny new technology, complete with dancing pigs. And once you've invested the research and development costs into building it, of course you want to sell it to anybody who could use it. So what kind of threat models does it address, and what does that say about the kinds of customers who'd want it? - It doesn't protect against traffic analysis, because the eavesdropper can follow the fiber routes and see who you're connected to. - It potentially provides perfect forward secrecy a long time into the future against attackers who can eavesdrop on you now and save all the bits they want. That's mainly useful for military applications - most commercial applications don't require secrecy for more than a few years, and most criminal activities can't use it because of the traffic analysis threat. Maybe banks? - It doesn't protect against Auditors getting your data. So maybe it's not useful for banks. That's really too bad, because except for the military, the main kinds of customers that need to spend lots of money on extra-shiny security equipment are doing so to distract Auditors, but it does let you tell the auditors you'd done everything you could. - The Quantum Key Distribution versions only protect keys, not data, so it doesn't protect you against cracking symmetric-key algorithms. It does provide some protection against Zero-Day attacks on public-key crypto-systems, but wrapping your key exchange in a layer of symmetric-key crypto can do that also. And if you're the military, you can revert to the traditional armed couriers with briefcases handcuffed to their arms method. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: Russian cyberwar against Estonia?
At 01:04 PM 5/18/2007, Trei, Peter wrote: If the Russians aren't behind this, who else should be suspected? It isn't like Estonia has a wide selection of enemies. :-) There are three likely suspects - the actual Russian government (or some faction thereof) - Russian Mafia for whatever reasons (might not be distinct from a faction of the government, and usually if the Mafia's involved they're polite enough to send a note demanding money or something.) - Some teenage hacker who got annoyed at some other teenage hacker because they got into an argument on WoW or Myspace and decided to DDOS him (usually attacks like that don't take down much more than a small ISP or a university, but like D00d, you're so 0wn3d, I can take down ur whole *country* :-) The latter isn't as far-fetched as it sounds (well, ok a bit...) - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: 128 bit number T-shirt?
I'd like one with Wearing an integer is not circumvention. on the back or some such. :) Large Integers are Not A Crime :-) On the other hand, isn't the key really an MD5 hash of some haiku about OK, so we know that DVD-CSS was Just Not Good Enough ? - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Private Key Generation from Passwords/phrases
With 4K possible salts, you'd need a very large password file to have more than a very few collisions, Definition of very large can vary. (alliteration intended).[...] UCSD has maybe 60,000 active users. I think very large is very common in the University environment. Different decade, different threat models, different scales. It was probably pretty rare to have more than a couple of hundred users on a PDP-11, but even at 60-70 you're in birthday-collision range with a 12-bit salt. But a website could easily have a million users in its password files, and some systems like Yahoo and Hotmail have hundreds of millions, though obviously they're not all separate Unix userids. Sometimes it matters if they get stolen, sometimes not - I don't care if someone discovers that my New York Times web password is password, but I'd be really annoyed if my online banking password got cracked. Salt is designed to address a couple of threats - Pre-computing password dictionaries for attacking wimpy passwords These become harder to do online, pushing a dictionary of e.g. a million words to 4 billion, or ~32GB, an unreasonably large database for ~1975 crackers, though obviously you could use a manageable stack of tapes. Today that fits in my iPod, though it's still impractical to store an unsalted full-56-bit DES password dictionary. - Detecting password collisions within systems, and between systems Testing a known password against 4096 salts took a long time at 0.5 MIPS, but it's faster at 4000 MHz. Large systems will have internal collisions, and the web makes it even more likely that somebody will have logins on insecure systems that might have the same password as their secure logins. - Annoying then-hypothetical hardware DES crackers That's still useful against some designs today, though many designs, especially software, are table-driven in ways that aren't annoyed much. There are probably times that salt is useful, and that password files using hashes are useful, but I'd think that if you're going to do that today you might as well use 64 or preferably 128 bits of salt, and of course you might want a hash other than MD5 or SHA-1. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Private Key Generation from Passwords/phrases
At 01:55 PM 1/18/2007, John Denker wrote: We would be better off maintaining just the one technical definition of entropy, namely S = sum_i P_i log(1/P_i). If you want to talk about something else, call it something else ... or at least make it clear that you are using the term in a nontechnical or metaphorical sense. ... If you want to talk about work factor, call it work factor. If you want to talk about entropy, call it entropy. One of the roots of the problem is that for many applications, i is a well-defined event and P(i) is a fixed value (for i) , but for many other applications, i might not be a well-defined event, and/or P(i) is really a conditional probability, P(i|other-stuff-you-know), and it's hard to tell whether that's usefully different from the non-conditional P(i). One case where this comes up is key generation with entropy pools - you take a bunch of hopefully-kinda-independent, hopefully-identically-distributed variables generated by processes that are complicated enough to look random, make some estimates of their probability distributions and hence of their entropy, and add the estimates together, after prewhitening the samples to make any correlation harder to exploit. This gives you N bits of entropy, and you take M bits of it to use as a key, again possibly with some hash functions to make calculations more difficult. So how many bits of entropy are left? You can be conservative and call it N-M, assuming that if somebody were clever enough to take the M bits key sample they could validate the rest with only N-M calls to an oracle, or you could be wildly optimistic and call it N, assuming that the conditional probabilities of the remaining pool are still the same given that you know the M bits, because there's no way to use them to validate anything, and if you've done a good enough job of designing your pool management functions the reality is probably closer to the wildly optimistic case, unless somebody finds an efficient way to invert your hash functions, at which point the conditional probabilities are actually different if you know the M key bits than if you don't. Another entropy example was the Venona decryptions - people banging randomly on typewriters didn't actually produce independent or identically distributed letters, so the conditional probabilities didn't actually match the assumed ones, so the entropy estimates were wrong, and human language plaintext being what it is, they really needed the 1-bit-per-bit of key entropy. It's much tougher to exploit than OTPs used more than once, but it's a start. But hey, nobody's going to guess that your password is your dog's name spelled backwards, or think of using a list of a few million obvious passwords as input to the key-generation function. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: It's a Presidential Mandate, Feds use it. How come you are not using FDE?
As far as Full Disk Encryption's usefulness as a term goes, I'd distinguish between several different kinds of applications for encrypting the contents of a disk 1 - The disk drive or maybe disk controller card (RAID, SCSI, etc.) encrypts all the bits written to the drive and decrypts all the bits read from the drive, usually with some keying input from the OS. 2 - The operating system's driver software encrypts/decrypts all bits written to/from the drive 3 - The operating system's file system driver software encrypts/decrypts all bits written to/from a file system (which might or might not occupy a drive partition.) 4 - Utility software encrypts/decrypts bits written to/from directories. 5 - Application software encrypts/decrypts contents of files. Obviously if you're trying to protect against KGB-skilled attacks on stolen/confiscated hardware, you'd like to have the swap partition encrypted as well as any user data partitions, though you may not care whether your read-only utility software was protected (e.g. your Knoppix disk or vanilla shared /usr/ or whatever.) Whether you implement that in the disk controller or OS is really a matter of convenience and user support economics - if you're a small conspiracy you may want to roll your own, but if you're a corporate IT shop, you've probably got economic issues that affect whether you customize the OS (more) or the disks or both and it's the operational processes that will trip you up. On the other hand, if you're trying to protect against lower-skilled attackers, e.g. laptop thieves who are reselling disks to the Nigerians and other hardware on eBay, you want to protect your file systems, but probably don't need to protect your swap. It's certainly nice to do that, of course, and might be a Good Thing for Linux and ***BSD to include in their standard swap drivers, but hopefully your file system drivers would keep their keys in non-swappable memory, and most other things get overwritten often enough that attackers not using electron microscopes probably won't bother with them much. In most OS's, swap isn't persistent across system reboots, so you can actually generate a new key on the fly every time and not bother the user about entering it, unlike regular filesystems or full-disk-encryption systems. Of course, if the KGB *is* after you, they may black-bag your PC before they confiscate it - if there's a key-logger chip added to your keyboard or a camera mounted in your ceiling light, it may not matter how cool your FDE is. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: cellphones as room bugs
At 11:26 AM 12/9/2006, Daniel F. Fisher wrote: Ian Farquhar (ifarquha) wrote The other problem for this technique is battery life. Suppose this worked by recording from mic to memory and then transmitting later. This leads to a bunch of questions: By what factor could transmission time/power be reduced sending such a recording later? How many minutes could a typical phone buffer? How much does a typical conversation compress? Are such algorithms within the power of a typical phone's processor? How much power is used in recording to memory and compressing? Cell phones already compress voice, to reduce spectrum needs, and that's done in hardware rather than wasting CPU. If the phone's design is sufficiently general, it can easily grab the compressed voice bits and store them in memory instead of transmitting (assuming there's enough memory, which isn't necessarily the case.) Voice compression rates are typically 5.6 - 6.5kbps, or 13 on some GSM flavors, and you may gain a bit from silence suppression depending on whether the microphone can adequately hear the other speaker. If the phone doesn't have data networking features, or only has the slow types (CDPD, etc.) used to handle text messages, there's probably no big advantage to doing this. But if you've got faster data service, say 50-60kbps or the newer ~~200-300kbps stuff, then you can transmit faster than real-time speech, and if you can buffer enough data, say 1 MB for 20 minutes of talk time, you might save some battery. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Cypherpunks make the OED :-)
James Gleick's NYT article on the OED mentions cypherpunk among the words recently added to the dictionary. http://www.nytimes.com/2006/11/05/magazine/05cyber.html?pagewanted=all The page requires registration to access, though there are enough popular pseudonyms that have done so; I don't know if any of the cypherpunks/somepassword combinations still work; I've been using one of the no-response email systems for my login. http://www.oed.com/help/updates/latest-additions.html I don't have a subscription to the online dictionary to see what they said about it. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Public Key Cryptography 30th Anniversary Event - 10/26, Mountain View CA
From: Computer History Museum [EMAIL PROTECTED] Subject: Public Key Cryptography 30th Anniversary Event - October 26 Celebrating 30 years of Public Key Cryptography (PKC) Join the Computer History Museum for a special public event celebrating 30 years of public key cryptography. This memorable evening celebration will honor the inventors, the inventions, the milestones, and the future of PKC. The program is moderated by Steven Levy, author of Crypto and senior editor Newsweek, and includes Ray Ozzie, Whitfield Diffie, Martin Hellman, Jim Bidzos, Dan Boneh, Brian Snow, and John Markoff. All will share their opinions on the state of the industry today and an audience question and answer session will complete the evening. Go to www.computerhistory.org/events/PKC/ to register for this exclusive celebration. Space is limited, so register today. WHERE ~ Computer History Museum 1401 N. Shoreline Blvd. Mountain View CA 94043 (Highway 101 at Shoreline) www.computerhistory.org/about/directions/ WHEN ~ OCTOBER 26, 2006 6 to 9 pm AGENDA ~ 6:00 to 7:00 PM Networking reception 7:00 to 7:30 PM Welcome and PKC Overview 7:30 to 8:30 PM Panel presentation 8:30 to 9:00 PM Audience question and answer session Please join us on October 26th for this networking reception and panel presentation. Mark your calendar now, and visit www.computerhistory.org/events/PKC/ to register for this celebration. Space is limited, so register today. s p o n s o r e d b y Voltage Security and RSA: www.voltagesecurity.com www.rsasecurity.com You are currently part of the Lecture announcement list of the Computer History Museum. To unsubscribe, please reply to this message with the word remove in the subject line. -- - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Hamiltonian path as protection against DOS.
Crypto is usually about economics and scalability. If you're doing this for DOS/DDOS prevention, you don't need the NP-completeness perfection you get from Hamiltonian paths or similar problems - SHA is fine, or any other hash that's quick to verify and hard to reverse. Even MD5 is probably still ok... Calculating any of the hashes probably takes less time than handling the packets does. It's almost certainly better for you if they harass you by sending you bogus SHA pieces that you can process quickly than bogus DH pieces that take you a while, and if it's not too distributed an attack, you can also blacklist senders IP addresses. At present I'm skeptical about the need for that kind of protection - a simple UDP or TCP handshake and maybe a Photuris cookie are enough to take care of most forgery attacks and let you blacklist hostile senders. But malware writers are tenacious bastards, and perhaps there are or will be applications where this sort of protection could be useful - merely insisting that attackers use _your_ protocol is probably enough to cut down on 99.99% of attacks unless you get the protocol widely adopted. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: VoIP and phishing
There are two sides to the voice phishing here - - getting the target to call a phone number you've emailed him - using cheap voice calls to call the target with your offer. VOIP doesn't affect the former case much, since the target is paying for the call, but it does separate callee geography from phone numbers, so you can use a plausible phone number (e.g. New York) that's directed to a location with cheap criminal labor, without the effort that used to be required to set up FX numbers or expensive international private lines or locate your call center in the target's country or state. I've received one Nigerian 419 phone call, a few years back, which used a Deaf Relay Operator to relay the call from the scammer, and apparently they used to be heavy abusers of that service. VOIP also makes that more practical, and somebody's coined the term spit to refer to Spam over IP Telephony. But phone calls are cheap enough that labor is the dominant cost of the calls. I receive frequent offers to refinance my mortgage or get credit cards that use presumably-standard phone banks, usually calling from India and claiming to be US banks. For all I know, they really are legitimate rude bankers instead of scammers, but I don't care either way. VOIP may have replaced voice over frame as the transmission medium, but it's often an enabling technology for the telco rather than voice over internet to the end user. I've been at a lot of telecom trade shows recently, and vendors have been showing off session border controllers and various security devices and presence servers, and while there are lots of tools to let the recipient indicate whether he's accepting calls or not, there doesn't seem to be much out there to detect and reject unwanted calls wholesale. Most of what I've seen that's somewhat in that direction are buddy-list tools that let your spouse/boss/etc. reach you directly and divert other callers to voice mail or whatever, but within a year or two we'll start needing to get more sophisticated filters the way we do with email. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: bounded storage model - why is R organized as 2-d array?
At 10:37 AM 3/9/2006, Chris Palmer wrote: Right, but even though a 1.5GHz machine is a bit old (heh...) for a workstation, my dinky little Linksys WRT54GC wireless AP still needs to AES-encrypt a theoretical maximum of 54Mbps when I turn on WPA. Unless you're using your Linksys for file-sharing between machines at home, you're not likely to be encrypting more than about 6 Mbps (or whatever DSL and Cable Modem do these days in better cities.) Thus, something faster than AES, but still strong, would be nice. Your point about CPU cache size vs. pad size is well-taken, though. I'd trust RC4-used-correctly before trusting Tri-Strata, if there weren't so much bad history of people misusing RC4... - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: NPR : E-Mail Encryption Rare in Everyday Use
Somebody, probably Florian, wrote: I couldn't find a PGP key server operator that committed itself to keeping logs confidential and deleting them in a timely manner (but I didn't look very hard, either). Keyservers are a peripheral issue in PGP - important for convenience and for quick distribution of revocation lists, but they're very strongly just a tool for convenience. Security through Inconvenience is one flipside of Security through Obscurity, I suppose... If you've got a threat model that includes traffic analysis, then either you and your unindicted co-conspirators need to find other ways to exchange keys, like printing them on business cards, or find a keyserver that lets you suck down all the keys so it's not obvious which key you're looking for, or start using Tor to access the keyservers. Or you could try using the Google Keyserver - just because there isn't one doesn't mean you can't type in 9E94 4513 3983 5F70 or 9383DE06 or [EMAIL PROTECTED] PGP Key and see what's in Google's cache. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: EDP (entropy distribution protocol), userland PRNG design
At 01:01 AM 2/4/2006, Travis H. wrote: Assume further that it is not cost-effective to furnish each with a HWRNG, even one as inexpensive as a sound card (for example, they may not have a spare slot on the motherboard nor built-in sound). ... Suppose that /dev/random is too slow (SHA-1 was never meant to generate a lot of output) because one of these machines wishes to generate a large file for use as a one-time pad*. One-time pads are expensive protocols to use properly - the operational costs of generating easily-disposable media, putting couriers with briefcases handcuffed to their arms onto airplanes, shredder costs when trashing the CD/DVD/etc., /dev/thermite for the PCs, and all the other things that you need to do for a real OTP threat model add up to real money after a while. If you can afford that, you can afford to spend $100 for an external sound card or USB hardware random generator dongle or whatever or a PC case with more slots in it. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: another feature RNGs could provide
Good ciphers aren't permutations, though, are they? Because if they were, they'd be groups, and that would be bad. Actually, by definition, a cipher should be a permutation from the set of plaintexts to the set of ciphertexts. It has to be 1 to 1 bijective or it isn't an encryption algorithm. The groups-are-bad problem applies to the mapping between keys and plaintext-cyphertext bijections, not the mapping between plaintext and cyphertext. You're trying to avoid the situation where E(x,key1) == E( E(x,key2), key3) for all x The mapping between plaintext and cyphertext doesn't need to be 1-1 bijective. 1-n mappings from 1 plaintext to multiple cyphertexts can work fine for many applications, but have the practicality problem that the cyphertext is longer than the plaintext, and there aren't many applications where you really want the expansion. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: crypto for the average programmer
At 03:34 PM 12/14/2005, [EMAIL PROTECTED] wrote: An application programmer who is using PKCS1 doesn't even need to know the small amount of ASN.1 in the spec... libraries that implement RSA PKCS1 take care of the ASN.1 for the programmer. This is in fact one reason that ASN.1 exploits have been so wide-ranging when they've happened. ASN.1 is a horrendously ugly mess, even uglier than PGP, so almost everybody uses an existing library instead of rolling their own or writing a new library for other users. Major bugs aren't discovered often, but everybody's pretty much using the same C code, whether for SNMP or X.509 or whatever. I don't know how many of the Java et al. versions have rewritten it natively as opposed to importing C libraries, which is probably more convenient. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: A small editorial about recent events.
At 10:58 AM 12/18/2005, Perry E. Metzger wrote: The President claims he has the prerogative to order such surveillance. The law unambiguously disagrees with him. There are minor exceptions in the law, but they clearly do not apply in this case. They cover only the 15 days after a declaration of war by congress, a period of 72 hours prior to seeking court authorization (which was never sought), and similar exceptions that clearly are not germane. One of the NYT articles also said that the President's lawyers gave him an opinion saying that the post-9/11 resolutions gave him the authority to do this. If the resolutions actually did that, then that could supersede the previous laws that made it criminal. But this wasn't the only domestic spying story in the news this week. http://www.msnbc.msn.com/id/10454316/ NBC reports that the Defense Department is back to CONINTELPRO-style spying on Americans, specifically anti-war groups and campaigns against military recruiting, especially suspicious groups associating with Quakers. And the EU parliament just voted on massive data collection laws, requiring ISPs, telcos, and mobile phone companies to collect and retain information in ways that would have previously violated EU privacy laws. That's one of the big problems with protections based on laws - they're only good until the politicians change the laws. Constitutional protections are somewhat more durable, but can still be changed either by Amendments or by significant changes in court interpretations, such as the Drugs and Terrorism Exceptions to the Bill of Rights and the expansion of the Commerce Clause to cover almost everything. One of the Bush Administration's innovations has been White House legal opinions telling the President that the courts ought to approve various powers or practices, so there's therefore no need to actually take them to court, whether it's wiretapping or extraordinary rendition or defining torture to exclude anything done by US forces. We'll see if he gets away with it this time - he needs to be stopped. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: X.509 / PKI, PGP, and IBE Secure Email Technologies
At 09:40 AM 12/8/2005, Aram Perez wrote: On Dec 7, 2005, at 10:24 PM, James A. Donald wrote: Software is cheaper than boats - the poorest man can afford the strongest encryption, but he cannot afford the strongest boat. If it is that cheap, then why are we having this discussion? Why isn't there a cheap security solution that even my mother can use? Usability is a hard problem, and security is a really broad field. PGP, for instance, did a pretty good job of security a decade ago, given Phil's threat models, (ignoring a few algorithm problems that were mostly related to trying to skimp on bits and the subsequent weaknesses in MD5), but the usability was pretty rough back then, and version compatibility has gotten enough worse that Hugh Daniel and I can no longer reliably communicate with PGP. But even if we both drop back to GPG on text files, and use remailers run by friends on Tor nodes run by random strangers, KGB-proof security would require protection against black-bag jobs on Hugh's keyboards and duping employees at my company's IT department into weakening my Windows XP configuration. (For cost-effectiveness and avoidance of detection, I'd recommend the latter strategy, probably by selling them some new nifty administration tool or Instant Messaging client :-) The real security issue for your mother is threat models. If your mom isn't using a Mac or administering her own Linux box, then her biggest security threat is that she's computing on a box made of Swiss cheese (though XP does seem to be noticeably better than Win95/98/ME) and probably using a browser that's happy to accept random software installed by spammers and phishers, and if she's not using webmail, she's probably running a mail client that happily displays clickable links to phishing sites purporting to be eBay or her bank. And that's mostly independent of whether she can trustably send email to other members of the Ladies' Sewing Circle and Terrorist Society without the Feds reading it, which is the kind of problem PGP was trying to solve, because her bank and eBay don't cryptographically sign their mail. Popularity of a product is critical to its security; you don't gain anonymity if the Feds can recognize that you're one of the dozen users of a given application. Your mom can use Skype, but nobody she knows uses Crypto Kong, and I only know a few people who use PGP to email their mom. But some of the Instant Messaging systems use crypto; too bad that they're continually trying to be incompatible with each other to gain market share. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: [Clips] Banks Seek Better Online-Security Tools
At 08:05 PM 12/2/2005, [EMAIL PROTECTED] wrote: You know, I'd wonder how many people on this list use or have used online banking. I've used it for about a decade at my credit union, and I've had my paychecks deposited directly for decades. There are things I absolutely won't do, like have a debit card attached to the account, or have companies authorized to take money out directly, or have electronic checks of various sorts taken out of the account. Normally I don't do email with them (though nobody appears to have noticed them as a phishing target), but I did have one time I had to ask about a transaction, and they do that by email, so I was able to trust the responses. But for basic services where I tell them what to send to whom, it's reliable, appears to be at least as secure as the other risks to the account, and it means that the basic payments I need to make every month happen automatically, so I only have to pay attention to the occasional variable transaction. I've also used account-based electronic gold services, but only transactionally, so at most they end up with a couple dollars worth of exchange-rate breakage in them, and there are some non-account-based services that I've also used. I won't use e-gold - not that their website is obviously insecure, but for a while there was so much e-gold phishing that I set my filters to automatically discard anything purporting to be from them, which might interfere with doing real business. On the other hand, they don't appear to state a policy of always digitally signing all transactions, so I'm a bit concerned beyond the more blatant phishing risks. Thanks; Bill Stewart - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: ISAKMP flaws?
At 06:56 PM 11/18/2005, William Allen Simpson wrote: | tromped around the office singing, Every bit is sacred / Every bit | is great / When a bit is wasted / Phil gets quite irate. | Consider this to be one of the prime things to correct. Personally, | I think that numbers should never (well, hardly ever) be smaller | than 32 bits. (Jon Callas, 1997-08-08) Ah yes, a couple of years after Photuris. And wasn't Jon the _author_ of the PGP variable length integer specification? Hoisted on his petard? No, it was still Phil's old heavily-used petard, worked over by various other people from PGP 3.0 and PGP Inc. Jon was going for backwards compatibility in the OpenPGP specs. He may have cleaned up the specs a bit, and fixed some of the security holes from VL-integer exploits, but unfortunately OpenPGP retained almost all the old ugliness. I was always grumpy about the impossibility of doing stealth easily in the native PGP formats and the fact that the OpenPGP code fossilized it. For political reasons I'd have also liked PGP to have had an optional very simple format so you could fit it into one page of Perl or equivalent to go with the RSA in 4 lines of Perl or lisp. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: the limits of crypto and authentication
At 09:29 PM 7/9/2005, Perry E. Metzger wrote: The Blue Card, so far as I can tell, was poorly thought out beyond its marketing potential. I knew some folks at Amex involved in the development of the system, and I did not get the impression they had much of a coherent idea of what the technologies would be used for other than creating marketing buzz. On the other hand, only a short time before that, Apple's iMac created a whole marketing revolution and set of spinoff products and revitalized the company by coming out with a semi-transparent blue-green case that effectively packaged the Reality Distortion Field, and they were able to maintain the effect over several years by the radical introduction of several other semi-transparent colors. It'd be nice if good crypto and authentication methods could create a market for improved products, but hey, if blue-green translucent dancing pigs gets customers, the marketing people have done _their_ job. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: AES cache timing attack
At 02:44 AM 6/20/2005, Peter Gutmann wrote: Stephan Neuhaus [EMAIL PROTECTED] writes: Concerning the practical use of AES, you may be right (even though it would be nice to have some advice on what one *should* do instead). Would switching to triple-AES (or double-AES) or something help? Yeah, it's ugly, and AES was supposed to let us get away from triple-DES, but maybe running one AES with the original key and the other session with the inverse of the key would interfere with timing attacks? - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Papers about Algorithm hiding ?
At 01:14 PM 6/3/2005, [EMAIL PROTECTED] wrote: I think we are already in a state where practically everybody that has a computer has crypto available, and it's not difficult to use it! Of course they have it - the problem is having crypto in a way that's not suspicious, and suspicious is highly dependent on your threat model. For instance, Microsoft Word has crypto - it's lousy crypto, which isn't directly relevant here, but it's a utility that people view as normal, while PGP is inherently suspicious-looking. No reason that OpenOffice couldn't have crypto that's actually reasonable quality. The rename the binaries strategy is probably more reliable than cyphersaber etc. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: how email encryption should work
At 07:00 PM 3/28/2005, James A. Donald wrote: In my blog http://blog.jim.com/ I post how email encryption should work I see a couple of problems with your proposal. I'm not sure I like your external trusted mail-server assumptions, but they're probably good enough for many people, and other people will have better comments about them. Your plan is really designed for a small number of addresses per sender, as opposed to a quasi-infinite set of tagged addresses. It's becoming pretty common for anti-spam reasons to give different recipients different mail addresses like [EMAIL PROTECTED] (or [EMAIL PROTECTED]) or [EMAIL PROTECTED] so you can track and whitelist/blacklist people you communicate with, and some ISPs automagically translate between the two formats. Building a user interface that does that unobtrusively is probably a hard problem, or at least not a well-solved one, and building a cryptosystem that assumes a small number of addresses per user could make that style of mailer harder. A good user interface probably has some version of petname support, though, so there's some commonality with key handling. On the other hand, if you assume that most people will get domains, whether 2LD or 3LD or other subdomain, you could do a model that says that a user gets one key per domain, so you could think about hanging the keys off DNS. That may not be the right choice (do you want your email addresses to be easily correlated, and cracking/stealing one address's key to reveal the keys you use for everybody else? Or does the domain pretty much imply that to the skilled recipient anyway so who cares?) And of course it gets into the whole squabble about DNSSEC, and why its deployment failed, and whether it was trying to do a perfect job and therefore less scalable than a mostly-good-enough job, or at least into the politics of those questions if not the technology. The related problem is what to do if you *do* want different keys for different recipients; you could do that with different subdomains, or you could do a non-DNS approach. - Is (sender+recipient+timestamp+message) the right thing to sign? The Subject: line is in the mail headers, but it's probably something that should be part of the message. I'm not sure about some various X-headers. And of course the From: line includes both the email address and the sender's name, and the sender's name may be different for different recipients (in some sense, it may be the recipient's petname for the sender.) - Also, if you're attaching a key strictly to the email address, what happens to old signatures if you move email addresses? I suppose that's part of the point of getting your own domain name, so you can avoid having to change contact addresses when you change ISPs, but if you're using a new email address, how do you forward the signature? One option is to do what you can do in Crypto Kong, where you send a message from old-address signed by old-address, saying that you'll be using new address and new key, but that seems a bit awkward, since you need a convenient way to include the new keys for people who whitelist you or who you only want to send encrypted mail to. Thanks; Bill Stewart - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Encryption plugins for gaim
At 10:19 PM 3/13/2005, Adam Fields wrote: Given what may or may not be recent ToS changes to the AIM service, I've recently been looking into encryption plugins for gaim. AOL says that the ToS bits are only for things like chatrooms; user-to-user AIM traffic doesn't even go through their servers. That doesn't mean they can't eavesdrop on it if they want to, or that they don't have mechanisms for automating MITM, so you may very well want to use encryption, but at least in the normal case your traffic is relatively private. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: Banks Test ID Device for Online Security
R.A. Hettinga wrote: Okay. So AOL and Banks are *selling* RSA keys??? Could someone explain this to me? At 12:24 PM 1/4/2005, Trei, Peter wrote: The slashdot article title is really, really misleading. In both cases, this is SecurID. Yup. It's the little keychain frob that gives you a string of numbers, updated every 30 seconds or so, which stays roughly in sync with a server, so you can use them as one-time passwords instead of storing a password that's good for a long term. So if the phisher cons you into handing over your information, they've got to rip you off in nearly-real-time with a MITM game instead of getting a password they can reuse, sell, etc. That's still a serious risk for a bank, since the scammer can use it to log in to the web site and then do a bunch of transactions quickly; it's less vulnerable if the bank insists on a new SecurID hit for every dangerous transaction, but that's too annoying for most customers. Bill Stewart [EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Are new passports [an] identity-theft risk?
At 06:11 AM 10/24/2004, Ian Grigg wrote: The questions would then be, what frequency do these things operate on, what power is required to power them up, and what power is required to ... power them down. Any radio guys around? There's an excellent RFID reference article at http://www.acmqueue.com/modules.php?name=Contentpa=showpagepid=216 RFIDs run at a variety of frequencies, including 128 kHz, 13.56MHz, 915 MHz, 2.45GHz, which are the common ISM bands that lots of other things run in, such as cordless phones, WiFi, Microwave ovens, etc., which means that detecting readers may be tough. It doesn't take a lot of power to power them; not sure what it takes to fry them. Bill Stewart [EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Printers betray document secrets
At 05:23 PM 10/18/2004, R.A. Hettinga wrote: http://news.bbc.co.uk/2/low/technology/3753886.stm It turns out that their techniques aren't all that useful. Changing laser printer cartridges changes the results. You might find that two documents were printed by the same printer, but it doesn't give you the options for tracking it down that manual typewriters did. And the differences don't identify a specific printer in a way that can be tracked, e.g. identifying a serial number that could be looked up from warranty records. It's not clear that they work at all with inkjet printers, and changing ink cartridges is even more common than changing laser printer cartridges. If you're sloppy, you've probably got a bunch of partly-used cartridges around, so even if you want to print out a bunch of ransom notes or whatever, you don't even have to go to Kinko's to get them to be different. If printer makers want to build in watermarking to make everything they print traceable, the way many of them check for documents that look like money and don't print them, they could hide patterns that survive cartridge changes (would you notice a few inverted pixels on a 600x600dpi printout?) But even then, inkjet printers are dirt cheap; when they're on sale, they're essentially a free enclosure in a box of overpriced printer cartridges, so even of the printer wants to rat out the user and it's not easy to change the serial number PROM, you can just replace the printer. Bill Stewart [EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Linux-based wireless mesh suite adds crypto engine support
Peter Gutmann wrote: Tinfoil-hat mode. Agreed, but some people want to be thorough, or pedantic, or paranoid. At 04:20 AM 9/30/2004, Jonathan Thornburg wrote: UNDOCUMENTED_EVIL_WIRETAP_MODE can be just about impossible to spot without full design oversight. Even for a 3DES chip, where supposedly you can use deterministic test vectors to verify things, the following scheme due to Henry Spencer embeds an almost-impossible-to-spot-in-practice backdoor: A somewhat simpler backdoor could be used in block chaining modes. Occasionally output the data you're leaking instead of one or a few blocks of cyphertext, and the CBC will glitch on it and then resync a few blocks later; in many environments the application layer will correct for it, e.g. IPSEC will lose a few packets, TCP will timeout and retransmit, and 3 seconds later it's as if nothing happened except that the private keypart has been leaked for the passive eavesdropper. Bill Stewart [EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Linux-based wireless mesh suite adds crypto engine support
In the past, there have been two main problems with the Via crypto sets - availability of convenient software - sufficient documentation and really transparent provable details so that users could trust and verify that the hardware and software were doing what they claimed to be doing and weren't doing anything evil that they didn't admit to, such as including backdoors or bad random number generators. For typical applications, this is probably fine, though I haven't looked at Via's licenses to see if they can easily be used with a GPL license or if they need LGPL+Weaselwords or worse. The hard part is trust - Cryptography Research did a study last year about the quality of the random number generator, and found that you get about 0.75 bits of entropy per output bit, or 0.99 if you do Von Neumann whitening, so it's fine for feeding your crypto-based whitener. But their report indicates that they were mainly working from design documentation and testing actual equipment, so their tests doesn't show what the RNG does if you execute SET MSR UNDOCUMENTED_EVIL_WIRETAP_MODE first, much less what happens to the AES keying info or IVs. Disclaimer: I'd be really surprised if UNDOCUMENTED_EVIL_WIRETAP_MODE exists - the folks who built the crypto features in say good pro-privacy things, and I'm inclined to trust them. I'm much less sure about the nonexistence of OBSCURE_BUGGY_RNG_CONDITION_MODE. It's very hard to test for these things when you've got complete documentation, even if Ken Thompson wasn't helping write your compilers. Bill Stewart At 05:21 AM 9/25/2004, R. A. Hettinga wrote: http://www.linuxdevices.com/news/NS1975038466.html ... Sep. 24, 2004 The first commercial software product to exploit the cryptographic acceleration engine in newer Via processors has hit the market, according to Via. LocustWorld's MeshAP-Pro is a commercial version of MeshAP, Linux software for self-organizing networks of wireless access points. MeshAP-Pro targets larger mesh network operators such as urban service providers. In addition to selling and supporting MeshAP-Pro software, LocustWorld also offers blackbox hardware platforms for wireless routers, such as the MeshBox, a Linux-based mini-ITX system based on Via mini-ITX boards. LocustWorld sells Linux-based blackboxes for wireless routers based on Via mini-ITX boards The processors in newer Via mini-ITX boards based on C5P Nehemiah cores include the PadLock Hardware Security Suite, which includes the PadLock RNG (random number generator) and the PadLock ACE (advanced cryptography engine). PadLock ACE performs low-level processing of the algorithms used in AES (advanced encryption standard), a kind of cryptography defined by US government standards. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: public-key: the wrong model for email?
At 10:19 PM 9/15/2004, Ed Gerck wrote: Yes, PKC provides a workable solution for key distribution... when you look at servers. For email, the PKC solution is not workable (hasn't been) and gives a false impression of security. For example, the sender has no way of knowing if the recipient's key is weak (in spite of its length) or has some key-access feature. Nonetheless, the sender has to use that key. I don't understand the threat model here. The usual models are - Key too short - Obvious to the sender - Recipient's machine is compromised - Not obvious to sender, but not fixable by email program - Recipient is stupid and careless - Often obvious to sender, but not fixable by email program - Recipient's Public Key generator system generates weak keys - Hard for sender to detect and work around - Usually requires extra work by recipient to obtain compromised software, unless mandated by Corporate IT Droids - Recipient can reduce risk by using open source software - Recipient's Public Key generator mails copy of private key to keyserver.kgbvax.gov - Indistinguishable from previous case - Recipient's Client Software mails copy of session key to ashcroft.kgbvax.gop - Indistinguishable from previous case - Recipient's Email Client forwards incoming mail message plaintext disguised as bouncegrams or viruses. - Indistinguishable from previous case. - Recipient's Secret Key is recipient's dog's name spelled backwards, written on yellow sticky note pasted next to open window, under the big mirror with a good view of recipient's keyboard and screen. - Not a software problem - Recipient's Computer Disk automatically backed up to optical storage at night - No sense subpoenaing cyphertext when you can subpoena plaintext. You're focusing on a relatively niche threat model, unless there's some operational aspect here I'm missing. If you wanted to do something fancy, you could insist that the recipient send the sender a Diffie-Hellmann Half-Key, which you use to generate a session key that you use for message encryption, and transmit your DH half-key along with the encrypted message for the sender to decrypt. It's still subject to most of the same threats as the RSA-like public-key model, though maybe it's a bit easier to detect weak Diffie-Hellmann keys. However, unless you want to force the recipient to change their client interface, the easier place to implement something is in their SMTP client, and the obvious way to do that is some variant on SSL-SMTP. If you _still_ want more control, set up a web server, and instead of sending your actual secret message, send Encrypt ( Key=Alice, Message= - BEGIN PGP SIGNED MESSAGE Alice - I've sent you an encrypted message at https://bob.example.net/cookie123456.PGP This URL will self-destruct in 5 business days. - Bob - END PGP SIGNED MESSAGE ) However, if Alice was using a compromised email client, she could just as easily be using a compromised browser. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: potential new IETF WG on anonymous IPSec
At 11:45 AM 9/12/2004, Sam Hartman wrote: No. opportunistic encryption means I have retrieved a key or cert for the other party, but do not know whether it is actually the right cert. This is slightly different although at the level of current discussion it has the same security properties. Actually, FreeSWAN's Opportunistic Encryption meant if you've got IP traffic for somebody, see if they can do encryption with you and use it if you can. Because Gilmore wanted to make sure encryption was always done securely, their implementation used a common PKI - DNSSEC and inverse DNS - which has the advantage that a security gateway can use it when all it knows is the IP address of the destination (which is typically the case), but the severe disadvantage that very few people have control over that DNS space and also that an IP address may belong to more than one domain. There's a significant policy question there - if you don't have a common PKI of some sort, is it worthwhile encrypting anyway, protecting against passive eavesdroppers but not MITM, or is that a false sense of security because the people who most need security are the people most likely to have a government annoyed enough at them to do the work of running a MITM attack? Encryption against passive eavesdroppers makes password-stealing and traffic analysis harder, so it's probably worth the risk, but that wasn't the choice that FreeSWAM made. Bill Stewart [EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: potential new IETF WG on anonymous IPSec
At 12:57 PM 9/9/2004, Hal Finney wrote: http://www.postel.org/anonsec To clarify, this is not really anonymous in the usual sense. Rather it is a proposal to an extension to IPsec to allow for unauthenticated connections. Presently IPsec relies on either pre-shared secrets or a trusted third party CA to authenticate the connection. The new proposal would let connections go forward using a straight Diffie-Hellman type exchange without authentication. It also proposes less authentication of IP message packets, covering smaller subsets, as an option. I read the draft, and I don't see how it offers any improvement over draft-ietf-ipsec-internet-key-00.txt or Gilmore's proposal touse open secret as a not-very-secret pre-shared secret that anybody who wants to can accept. It does introduce some lower-horsepower alternatives for authenticating less than the entire packet, and suggests using AH which I thought was getting rather deprecated these days, but another way to reduce horsepower needs is to use AES instead of 3DES. Also, the author's document discusses protecting BGP to prevent some of the recent denial-of-service attacks, and asks for confirmation about the assertion in a message on the IPSEC mailing list suggesting E.g., it is not feasible for BGP routers to be configured with the appropriate certificate authorities of hundreds of thousands of peers. Routers typically use BGP to peer with a small number of partners, though some big ISP gateway routers might peer with a few hundred. (A typical enterprise router would have 2-3 peers if it does BGP.) If a router wants to learn full internet routes from its peers, it might learn 1-200,000, but that's not the number of direct connections that it has - it's information it learns using those connections. And the peers don't have to be configured rapidly without external assistance - you typically set up the peering link when you're setting up the connection between an ISP and a customer or a pair of ISPs, and if you want to use a CA mechanism to certify X.509 certs, you can set up that information at the same time. Bill Stewart [EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: ?splints for broken hash functions
how about this simpler construction? (IV1) - B1 - B2 - B3 - ... Bk - H1 (IV2) - B1 - B2 - B3 - ... Bk - H2 This approach and the cache Block 1 until the end approach are both special-case versions of maintain more state attacks. This special case maintains 2*(size of hash output) bits of state. The cache block 1 case maintains (size of hash output) + (size of block 1) bits of state, but doesn't change the (size of block 1) bits between cycles. (Also, if you're going to do that, could you maintain (hash(Block1)) bits between cycles instead of the raw bits?) They both have some obvious simplicity to them, but I'm not convinced that simplicity actually helps, compared to other ways of getting more state. Perhaps the effective state of the 2-IV version is twice the size of the basic hash, perhaps it's less. My intuition is that more mixing might be better, and probably isn't worse, but I could easily be wrong. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Compression theory reference?
It's a sad situation when you have to get a non-technical judge to resolve academic conflicts like this, but it's your head that you're banging against the wall, not mine. If you want to appeal to authority, there's the FAQ, which of course requires explaining the Usenet FAQ traditions; perhaps you can find Lempel, Ziv, or Welch? In reality, you could show an algorithm for which any input gets at most _one_ bit longer, rather than arbitrarily longer. And of course most of the compression algorithms work because real data almost always has structure which reduces the entropy. My information theory books from grad school have long vanished into some closet, and were written just about the time LZ came out so they mainly discuss Huffman coding in the discrete-message sections, but you should be able to find a modern book on the topic. Matt Crawford's inductive argument is very strong - it gives you a constructive way to say that for any integer N, I can give a proof for that N, starting at 1 and working your way up, showing that if there's a lossless coding that doesn't make any messages of length N any longer, then it doesn't make any any shorter, so it's not a compression method, just a permutation. The You could compress any message down to 1 bit argument is a great throwaway line, but it isn't rigorously valid. (And if it were, you might as well compress down to zero bits while you're at it.) The problem is that for most lossless compression algorithms, some strings will get shorter (maybe even much shorter), but some will stay the same length, so even if you had a hypothetical never gets longer compression algorithm, you can't guarantee that your starting message would be one that got shorter as opposed to staying the same, so you can't say that all messages would compress to zero. If your judge doesn't like inductions that count up, or your academic opponents insist on examining methods that count down, Bear's argument gets you most of the way there, by emphasizing the 1-1 mapping aspect, but you could easily get tangled. (To do this properly, you need to do n and 2**n, but I'll use 10 for concreteness.) There are 1024 10-bit messages, and only 512 9-bit messages, so something obviously happened to the =512 that didn't compress to 9 bits. Maybe 512 of them didn't compress further and stayed as 10-bit; almost certainly some of them became 8 bits or shorter. At least one message didn't get shorter, because (2**10 - 1) = 2**9 + 2**8 + 2**7 ... + 2**1 So if you want to recurse downwards through repeated compression, you need to be sure your mapping keeps track of the ones that didn't compress the first time (maybe they'll compress the second time?), the ones that compressed by one bit, and the ones that compressed by more than one bit, and avoid wandering around in a maze of twisty little passages. So working your way up is probably cleaner. At 11:30 AM 9/1/2004, bear wrote: Actually you don't need to take it all the way to the reductio ad absurdum here. There are 1024 10-bit messages. There are 512 9-bit messages. You need to point out that since a one-to-one mapping between sets of different ordinality cannot exist, it is not possible to create something that will compress every ten-bit message by one bit. Or, slightly more formally, assume that a function C can reversibly compress any ten-bit message by one bit. Since there are 1024 distinct ten-bit messages, there must be at least 1024 distinct nine-bit messages which, when the reversal is applied, result in these 1024 messages. There are exactly 512 distinct nine-bit messages. Therefore 512 = 1024. Bear - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED] Bill Stewart [EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: First quantum crypto bank transfer
At 02:02 AM 8/23/2004, Florian Weimer wrote: * Bill Stewart: I agree that it doesn't look useful, but lawful intercept is harder, if you're defining that as undetected eavesdropping with possible cooperation of the telco in the middle, because quantum crypto needs end-to-end fiber so there's nothing the telco can help with except installing dark fiber, and the quantum crypto lets you detect eavesdroppers. But this doesn't scale. You'd need dark fiber to all communication partners. Yes. That's part of one definition of doesn't look useful. So if quantum key distribution was mandated for applications involving more than just a handful communication partners, you'd need relays (or rather unlikely advances in optical circuit switching). It would be possible to use it as link encryption, giving up the benefits of end-to-end in return for better scaling, but you could still make all the relaying happen in the user organization's facilities, rather than in a telco building that's outside the user organization's control. (Just because something isn't very useful doesn't mean you can't at least try to do the job semi-correctly...) By the way, the complete bashing of the recent QKD experiment is probably not totally deserved. Apparently, the experimenters used a QKD variant that relies on quantum teleportation of photons. This QKD variant is currently *not* available commercially, and the experiment itself could well be an important refinement of Zeilinger's earlier work in this area. That's at least interesting, though I don't see why you'd take the experiment out of the lab without a really well-defined benefit to the end user (unless you've got a research grant.) I'm surprised to hear that _any_ quantum key distribution variant is available commercially, given the costs of dedicating fiber and the effectiveness of current mathematical crypto or the alternative approach of couriers with briefcases and handcuffs. Bill Stewart [EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: First quantum crypto bank transfer
At 01:00 PM 8/21/2004, Florian Weimer wrote: However, I still don't believe that quantum cryptography can buy you anything but research funding (and probably easier lawful intercept because end-to-end encryption is so much harder). I agree that it doesn't look useful, but lawful intercept is harder, if you're defining that as undetected eavesdropping with possible cooperation of the telco in the middle, because quantum crypto needs end-to-end fiber so there's nothing the telco can help with except installing dark fiber, and the quantum crypto lets you detect eavesdroppers. On the other hand, at least in the US and probably in Germany, if the government wants the records of a bank's transactions, all they need is the locally-proper paperwork demanding the data, which is a threat model that quantum crypto doesn't help with, especially since the costs of that attack are much lower than tapping quantum fiber transactions. An intermediate level of weakness is detection of who the bank is communicating with. In the case of quantum crypto, it's simple - just follow the fiber to the other end. But banks are a semi-special case for this threat also, because you know that a bank's headquarters will talk to other buildings belonging to that bank, so it's no information leak... - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Cryptome on ABC Evening News?
At 03:32 PM 8/12/2004, R. A. Hettinga wrote: There's a teaser for tonight's 6:30 news about a website that publishes pipeline maps and the names and addresses of government employees. The horror. Speaking unofficially for the telecom industry, we're really happy to have the site there showing pictures of cable landings, antennas, etc. I've seen them used in internal training about submarine cables and I think we've probably used them in talks to customers as well. Separately, of course, we have bureaucrats who don't want to publish the addresses of telecom POPs, ignoring the fact that you can't buy physically diverse access to a location if you don't know where it is, and also ignoring the fact that 90% of a certain large 3-1/2-letter-acronym long distance carrier's POPs are in the same buildings as the local telcos so everybody knows where they are anyway, even though everybody's forgotten the derivation of VH coordinates... Bill Stewart [EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Using crypto against Phishing, Spoofing and Spamming...
At 03:20 AM 7/18/2004, Enzo Michelangeli wrote: 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. At least until a few years ago, and probably still today, it was easy to get a non-anonymous account in the US using fake ID. The Know Your Customer laws and other anti-terrorism fallout may have encouraged banks to check SSNs a bit more carefully, but as long as the person whose identity you're stealing doesn't have horrendously bad or good credit, it's probably still not hard. If it costs you $100 in fake ID to get the account set up, and you can burn the phish for $1000, then you win. But credit cards are probably more common and certainly easier to use. Buy laptops or other fungible goods, and sell them on eBay. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: The future of security
At 05:15 AM 6/2/2004, Ben Laurie wrote: SPF will buy me one thing forever: I won't get email telling me I sent people spam and viruses. Unfortunately, that won't work for me. My email address is at pobox.com, the mail forwarding service where the main proponent of SPF works, but my SMTP service is whichever ISP I'm currently connected through (DSL, dial, work, whatever) - which isn't under pobox's control. So my incoming mail can recognize SPFs and block forgeries, but my outgoing mail can't use them, unless pobox changes their business model to provide outgoing SMTP relay for their customers, doubling their bandwidth needs. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: [camram-spam] Re: Microsoft publicly announces Penny Black PoW postage project
At 07:46 PM 12/30/2003 +, Richard Clayton [EMAIL PROTECTED] wrote: [what about mailing lists] Obviously you'd have to whitelist anybody's list you're joining if you don't want your spam filters to robo-discard it. moan I never understand why people think spam is a technical problem :( let alone a cryptographic one :-( /moan The reason it's partly a cryptographic problem is forgeries. Once everybody starts whitelisting, spammers are going to start forging headers to pretend to come from big mailing lists and popular machines and authors, so now you'll not only need to whitelist Dave Farber or Declan McCullough if you read their lists, or Bob Hettinga if you're Tim (:-), you'll need to verify the signature so that you can discard the forgeries that pretend to be from them. You'll also see spammers increasingly _joining_ large mailing lists, so that they can get around members-only features. At least one large mailing list farm on which I've joined a list used a Turing-test GIF to make automated list joining difficult, and Yahoo limits the number of Yahoogroups you can join in a day, but that's the kind of job which you hire groups of Indians or other English-speaking third-world-wagers to do for you. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Microsoft publicly announces Penny Black PoW postage project
At 09:37 PM 12/26/2003 -0500, Adam Back wrote: The 2nd memory [3] bound paper (by Dwork, Goldber and Naor) finds a flaw in in the first memory-bound function paper (by Adabi, Burrows, Manasse, and Wobber) which admits a time-space trade-off, proposes an improved memory-bound function and also in the conclusion suggests that memory bound functions may be more vulnerable to hardware attack than computationally bound functions. Their argument on that latter point is that the hardware attack is an economic attack and it may be that memory-bound functions are more vulnerable to hardware attack because you could in their view build cheaper hardware more [] Once nice thing about memory-bound functions is that, while spammers could build custom hardware farms in Florida or China, a large amount of spam is delivered by hijacked PCs or abused relays/proxies, which run on standard PC hardware, not custom, so it'll still be slow. Penny Black or any other system that involves tweaking the email protocols gets a one-time win in blocking spam, because older badly-administered mail relays won't be running the new system - if their administrators upgrade them to support the new features, hopefully that will turn off any relay capabilities. That doesn't apply to cracked zombie machines, since the crackers can install whatever features they need, but at least all of those Korean cable-modem boxes won't run it. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Difference between TCPA-Hardware and a smart card (was: example:secure computing kernel needed)
At 09:38 AM 12/16/2003 -0500, Ian Grigg wrote: In the late nineties, the smart card world worked out that each smart card was so expensive, it would only work if the issuer could do multiple apps on each card. That is, if they could share the cost with different uses (or users). Of course, at this point the assertion that a smart card (that doesn't also have independent user I/O) costs enough to care about is pretty bogus. Dumb smartcards are cost-effective enough to use them to carry $5 in telephone minutes. The real constraint is that you're unlikely to have more than one card reader in a machine, so multifunction cards provide the opportunity to run multiple applications without switching cards in and out, but that only works if the application vendors cooperate. For instance, you may have some encrypted session application that needs to have your card stay in the machine during the session (e.g. VOIP, or secure login, SSH-like things, remote file system access), and you may want to pay for something using your bank smartcard during the session. That's not likely to work out, because the secure session software vendors are unlikely to have a relationship with your bank that lets both of them trust each other with their information, compared to the simpliciy of having multiple cards. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: example: secure computing kernel needed
At 02:41 PM 12/14/2003 +, Dave Howe wrote: Paul A.S. Ward wrote: I'm not sure why no one has considered the PC banking problem to be a justification for secure computing. Specifically, how does a user know their computer has not been tampered with when they wish to use it for banking access. I think PC banking is an argument *against* Secure Computing as currently proposed - there is no way to discover if there is a nasty running in protected memory or removing it if there is. Agreed. It's a better argument for booting from a known CDROM distribution. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: Open Source Embedded SSL - (License and Memory)
[Moderator's note: I'd really like to shut down the What license? debate --Perry] At 12:52 AM 11/27/2003 -0800, J Harper wrote: 1) Not GPL or LPGL, please. I'm a fan of the GPL for most things, but for embedded software, especially in the security domain, it's a killer. I'm supposed to allow users to modify the software that runs on their secure token? And on a small platform where there won't be such things as loadable modules, or even process separation, the (L)GPL really does become viral. This is, I think, why Red Hat releases eCos under a non-GPL (but still open source) license. We're aware of these issues. How do other people on the group feel? That's an obvious call for a BSD / C-News style license - You're free to copy it but leave our copyright notice in. - You acknowledge that you got it for free and that any consequences, no matter how horrible, of what you do with it are not our responsibility. - You're free to change it, but only if you include a notice that you changed it. - Maybe something about you must either distribute the licensed source code for no more than a copying/handling charge or else a pointer to the original. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Open Source Embedded SSL - Export Questions
At 02:45 PM 11/27/2003 +1100, Greg Rose wrote: At 12:27 PM 11/27/2003, Thor Lancelot Simon wrote: RC4 is extremely weak for some applications. A block cipher is greatly preferable. I'm afraid that I can't agree with this howling logical error. RC4 is showing its age, but there are other stream ciphers that are acceptable, and there are block ciphers (such as FEAL, same vintage as RC4) that aren't even vaguely secure. Well, to be more precise, RC4 has restrictions on the ways you can use it that make its crypto strength fail very badly if you violate them, and because it's an XOR stream cypher there are sometimes things you can't do with it that you could do with a block cypher. RC4 does also have the historical problem that people sometimes decide to use it with 40-bit keys because they can... OTOH, of course being a block cypher isn't enough to guarantee either strength or usefulness, e.g. bass-o-matic. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: New authentication protocol, was Re: Tinc's response to 'Linux's answer to MS-PPTP'
=Step 1: Exchange ID messages. An ID message contains the name of the tinc daemon which sends it, the protocol version it uses, and various options (like which cipher and digest algorithm it wants to use). By name of the tinc daemon, do you mean identification information? That data should be encrypted, and therefore in step 2. (Alternatively, if you just mean tincd version 1.2.3.4, that's fine. Step 2: Exchange METAKEY messages. The METAKEY message contains the public part of a key used in a Diffie-Hellman key exchange. This message is encrypted using RSA with OAEP padding, using the public key of the intended recipient. You can't encrypt the DH keyparts using RSA unless you first exchange RSA public key information, which the server can't do without knowing who the client is (the client presumably knows who the server is, so you _could_ have the client send the key encrypted to annoy MITMs.) To make the protocol generally useful for privacy protection, you shouldn't exchange this information unencrypted. So do a Diffie-Hellman exchange first, then exchange any other information, including RSA signatures on the DH keyparts. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: New authentication protocol, was Re: Tinc's response to 'Linux's answer to MS-PPTP'
If we use RSA encryption, then both sides know their message can only be received by the intended recipient. If we use RSA signing, then we both sides know the message they receive can only come from the assumed sender. For the purpose of tinc's authentication protocol, I don't see the difference, but... Now, the attacker chooses 0 as his DH public. This makes ZZ always equal to zero, no matter what the peer's DH key is. You need to validate the DH keyparts even if you're corresponding with the person you thought you were. This is true whether you're using signatures, encryption, or neither. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Code breakers crack GSM cellphone encryption
Trei, Peter wrote: Why the heck would a government agency have to break the GSM encryption at all? The encryption is only on the airlink, and all GSM calls travel through the POTS land line system in the clear, where they are subject to warranted wiretaps. Breaking GSM is only of useful if you have no access to the landline portion of the system. Some governments are more concerned about using warrants than others are. Sometimes the ones that are concerned about them also have police agencies that like to avoid using them. Some phone companies are pickier about paperwork than others. Some phone companies are faster about responding than others. Having governments that are officially less concerned about warrants is often correlated with having monopoly phone companies, which is often correlated with slow bureaucratic response - they may be extremely happy to help out the police, but that doesn't mean it doesn't take 18 steps to accomplish it. Landline-based wiretaps work best if you know the phone number; over-the-air systems can be more flexible about picking up any phone nearby, so if you see your target pick up a phone, but don't know its phone number, they're more convenient. And in landline-tapping environments, clever law-evaders can usually acquire the equipment to keep switching phones. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Attacking networks using DHCP, DNS - probably kills DNSSEC
At 11:49 PM 06/29/2003 +0200, Simon Josefsson wrote: No, I believe only one of the following situations can occur: * Your laptop see and uses the name yahoo.com, and the DNS server translate them into yahoo.com.attackersdomain.com. If your laptop knows the DNSSEC root key, the attacker cannot spoof yahoo.com since it doesn't know the yahoo.com key. This attack is essentially a man-in-the-middle attack between you and your recursive DNS server. That doesn't happen. (Well, it could, but as you point out, it's not a successful attack methodology, because DNSSEC was designed to correctly take care of this.) * Your laptop see and uses the name yahoo.com.attackersdomain.com. You may be able to verify this using your DNSSEC root key, if the attackersdomain.com people have set up DNSSEC for their spoofed entries, but unless you are using bad software or judgment, you will not confuse this for the real yahoo.com. The DNS suffix business is designed so that your laptop tries to use yahoo.com.attackersdomain.com, either before yahoo.com or after unsuccessfully trying yahoo.com, depending on implementation. It may be bad judgement, but it's designed to support intranet sites for domains that want their web browsers and email to let you refer to marketing as opposed to marketing.webservers.example.com, and Netscape-derived browsers support it as well as IE. Of course, everything fails if you ALSO get your DNSSEC root key from the DHCP server, but in this case you shouldn't expect to be secure. I wouldn't be surprised if some people suggest pushing the DNSSEC root key via DHCP though, because alas, getting the right key into the laptop in the first place is a difficult problem. I agree with you and Steve that this would be a Really Bad Idea. The only way to make it secure is to use an authenticated DHCP, which means you have to put authentication keys in somehow, plus you need a reasonable response for handling authentication failures, which means you need a user interface as well. It's also the wrong scope, since the DNSSEC is global information, not connection-oriented information, so it's not really DHCP's job. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Attacking networks using DHCP, DNS - probably kills DNSSEC
At 11:15 PM 06/28/2003 -0400, Steven M. Bellovin wrote: In message [EMAIL PROTECTED], Bill Stewart writes: This looks like it has the ability to work around DNSSEC. Somebody trying to verify that they'd correctly reached yahoo.com would instead verify that they'd correctly reached yahoo.com.attackersdomain.com, which can provide all the signatures it needs to make this convincing. So if you're depending on DNSSEC to secure your IPSEC connection, do make sure your DNS server doesn't have a suffix of echelon.nsa.gov... No, that's just not true of DNSsec. DNSsec doesn't depend on the integrity of the connection to your DNS server; rather, the RRsets are digitally signed. In other words, it works a lot like certificates, with a trust chain going back to a magic root key. I thought about that, and I think this is an exception, because this attack tricks your machine into using the trust chain yahoo.com.attackersdomain.com., which it controls, instead of the trust chain yahoo.com., which DNSSEC protects adequately. So you're getting a trustable answer to the wrong query. I'm less sure of the implementation issues of the Connection-specific DNS suffix, and I've seen conflicting documentation. If the resolver looks up domain.suffix before domain, then the attacker's DNS doesn't need to control the DNS access, and only needs to provide the attacker's certificates, but if the resolver looks up domain before domain.suffix, then the attacker also needs to make sure that the lookup of domain fails, which is most easily done by telling the DHCP client to use the attacker's DNS server along with telling it the suffix. (That doesn't add any extra work to the attack, but does make it a bit easier to trace the attacker after the fact; if you're not replacing the attacker's DNS server entry, then all you need is a legitimate-looking server for *.attackersdomain.com. In either case, somebody who can pull off this kind of an attack probably uses a compromised machine to run the DNS server on anyway.) I'm not saying that there can't be problems with that model, but compromised DNS servers (and poisoned DNS caches) are among the major threat models it was designed to deal with. If nothing else, the existence of caching DNS servers, which are not authoritative for the information they hand out, makes a transmission-based solution pretty useless. DNSSEC seems to do a pretty thorough job of making sure that if you look up the correct domain name, you'll get the correct answer, in spite of attackers trying to prevent it. But this attack tricks you into looking up the wrong domain name, and DNSSEC makes sure that you get the correct answer for the wrong name, which isn't the result you want. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Attacking networks using DHCP, DNS - probably kills DNSSEC
Somebody did an interesting attack on a cable network's customers. They cracked the cable company's DHCP server, got it to provide a Connection-specific DNS suffic pointing to a machine they owned, and also told it to use their DNS server. This meant that when your machine wanted to look up yahoo.com, it would look up yahoo.com.attackersdomain.com instead. This looks like it has the ability to work around DNSSEC. Somebody trying to verify that they'd correctly reached yahoo.com would instead verify that they'd correctly reached yahoo.com.attackersdomain.com, which can provide all the signatures it needs to make this convincing. So if you're depending on DNSSEC to secure your IPSEC connection, do make sure your DNS server doesn't have a suffix of echelon.nsa.gov... -- RISKS-LIST: Risks-Forum Digest Saturday 17 June 2003 Volume 22 : Issue 78 http://catless.ncl.ac.uk/Risks/22.78.html -- Date: Fri, 20 Jun 2003 15:33:15 -0400 From: Tom Van Vleck [EMAIL PROTECTED] Subject: ISP's DHCP servers infiltrated http://ask.slashdot.org/article.pl?sid=03/06/19/2325235mode=threadtid=126tid=172tid=95 ... It turns out, Charter Communications' DHCP servers were infiltrated and were providing p5115.tdko.com as the 'Connection-specific DNS suffix', causing all non-hardened Windows (whatever that means in a Windows context) machines to get lookups from a hijacked subdomain DNS server which simply responded to every query with a set of 3 addresses (66.220.17.45, 66.220.17.46, 66.220.17.47). On these IPs were some phantom services. There were proxying Web servers (presumably collecting cookies and username/password combos), as well as an ssh server where the perpetrators were most likely hoping people would simply say 'yes' to the key differences and enter in their username/password... Hmm, my cable ISP was down this morning. Maybe coincidence. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: PGP Encryption Proves Powerful
At 11:38 AM 05/30/2003 -0700, John Young wrote: If the FBI cannot crack PGP that does not mean other agencies with greater prowess cannot. It is unlikely that the capability to crack PGP would be publicly revealed for that would close an invaluable source of information. . Still, it is impressive that PRZ valiantly argues that PGP is algorithmically impregnable. That should satisfy its users as well as its crackers. And Phil was quoted as saying Does PGP have a back door? The answer is no, it does not, he said. If the device is running PGP it will not be possible to break it with cryptanalysis alone. But in fact that's incorrect. PGP doesn't have back doors, but it has two major weaknesses, which are weak user-chosen passphrases, combined with a secret key file format that makes it easy to verify whether a key has been guessed correctly, and human-rememberable passphrases, combined with rubber-hose cryptanalysis and a captured agent. If you're doing good operational security, and the Red Brigades probably are, your passphrases have good enough entropy that they're hard to crack, but if they got sloppy, and someone wants to feed all the information that's known about them to pgpcrack, it's possible that they'll find something. It's less likely than VENONA succeeding, because the importance of good passphrases was known, and unlike one-time pads there's no operational need to occasionally get sloppy under time pressure. I'm not aware of a PGP port to the Psion, but at least the Psion 3/3a/3c generation were 8086-like processors, and there was a C compiler ported to them, so perhaps somebody ported one of the earlier PGPs. (There was an old HP palmtop that ran genuine MS-DOS, unlike the Psion's more interesting operating system, and you could probably run PGP on that directly.) - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: PGP Encryption Proves Powerful
At 08:17 AM 06/03/2003 -0700, bear wrote: what he said was with cryptanalysis alone. Rubber-hose methods are not cryptanalysis, and neither is password guessing. Eh? Password guessing certainly is. I'm not aware of a PGP port to the Psion, but at least the Psion 3/3a/3c generation were 8086-like processors, and there was a C compiler ported to them, so perhaps somebody ported one of the earlier PGPs. IIRC, there was/is a psion linux port, with gcc. Looks like it's still in active development, mainly for the Psion 5 series - they've even got X Windows running on them, as well as PGP. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: New vs Old (was Snake Oil)
At 08:53 AM 06/03/2003 -0700, bear wrote: IDEA is still a good cipher as far as I know, but PGP has been driven away from it in the US due to intellectual-property issues. Rather than continue with incompatible versions for use inside/outside the USA, they're switching to CAST (although this is causing more, rather than less, version incompatibilities). Actually, they switched to letting the user choose algorithms, with CAST as the default but others such as 3DES available. One of the compatibility issues is that people have written patches for GPG that implement IDEA, so some users' systems support it and others don't. On the other hand, that mainly bothers the people who've picked only accept IDEA for their symmetric algorithms. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Maybe It's Snake Oil All the Way Down
At 11:38 AM 06/03/2003 -0400, Ian Grigg wrote: I (arbitratrily) define the marketplace for SSL as browsing. ... There, we can show statistics that indicate that SSL has penetrated to something slightly less than 1% of servers. For transmitting credit card numbers on web forms, I'd be surprised if there were 1% of the servers that *don't* use SSL/TLS. Virtually all deployed browsers support SSL, except a few special-purpose versions. The web servers supporting almost all of the web support SSL if they have keys installed. While many of them haven't bothered paying money for certified keys or doing self-signed keys, I'd be surprised if it's really as low as 1%. What's your source for that figure? While only a small fraction of web pages, and a much smaller fraction of web bits transmitted, use SSL, that's appropriate, because most web pages are material the publisher wants the public to see, so eavesdropping isn't particularly part of the threat model, and even integrity protection is seldom a realistic worry. (By contrast, eavesdropping protection and integrity protection are critical to telnet-like applications, so SSH is a big win.) It's nice to have routine web traffic encrypted, so that non-routine traffic doesn't stand out, and so that traffic analysis is much harder, but there is a significant CPU hit from the public-key phase, which affects the number of pages per hour that can be served. Corporate intranet web traffic carried across the public internet sometimes uses SSL, but usually uses IPSEC because that also supports email. In addition to web browsing and email submission, there's an emerging market for SSL-based VPNs appliances. Neoteris is one of the pioneers, and Aventail and some others are players. The intention is that you can get clientless (browser-based) support for intranet web browsing and email, and lightweight client support for telnet, while only having to buy an overpriced server box. (And the box doesn't even need crypto accelerator help, because the public-key phase only gets used for login, while most sessions are long enough that this amortizes quickly.) - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Nullsoft's WASTE communication system
http://www.nullsoft.com/free/waste/ - Overview http://www.nullsoft.com/free/waste/security.html - Security section http://www.nullsoft.com/free/waste/network.html - Network design http://slashdot.org/article.pl?sid=03/05/29/0140241mode=threadtid=126tid=93 - Slashdot discusssion Nullsoft, who did Winamp and Gnutella, just released a package called W A S T E which does encrypted communications within small groups of people. It doesn't appear to have had outside analysis of its security yet, but they do invite it, and they say it needs some work. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
