Re: [Cryptography] The paranoid approach to crypto-plumbing
On Mon, Sep 16, 2013 at 12:44 PM, Bill Frantz fra...@pwpconsult.com wrote: Symmetric encryption: Two algorithms give security equal to the best of them. Three protect against meet-in-the-middle attacks. Performing the multiple encryption at the block level allows block cyphers to be combined with stream cyphers. RC4 may have problems, but adding it to the mix isn't very expensive. A paper of mine on combining a stream cipher with a block cipher: http://eprint.iacr.org/2008/473 AES-256 uses 14 rounds vs. 10 for AES-128, so it is about 40% slower. Given 256 bits of key and a stream cipher that is 5x faster than AES, you can use AES-128 and have 128 bits to key the stream cipher. AES-128 plus whitening that changes for every block (two 128-bit blocks of stream cipher output) has roughly the same cost as AES-256. There are several ways to reduce the cost and/or increase the security from there; see the paper for details. I am still working on this notion and will have a new and much improved version of that paper sometime this year. Anyone I know moderately well who wants to review it can contact me off-list for the current draft. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Thoughts on hardware randomness sources
On Tue, Sep 10, 2013 at 10:59 AM, Marcus D. Leech mle...@ripnet.com wrote: I wonder what people's opinions are on things like the randomsound daemon that is available for Linux. I have not looked at that. A well thought out well documented RNG based on a sound card is: http://www.av8n.com/turbid/paper/turbid.htm I wrote a very simple one (perhaps not yet trustworthy because it has not had much analysis) based on timer calls. Its documentation discusses a few others: ftp://ftp.cs.sjtu.edu.cn:990/sandy/maxwell/ ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Using Raspberry Pis
On Mon, Aug 26, 2013 at 4:12 PM, Phillip Hallam-Baker hal...@gmail.com wrote: I really like RPis as a cryptographic tool. The only thing that would make them better is a second Ethernet interface so they could be used as a firewall type device. Two things to look at. Onion Pi turns one into a WiFi hotspot Tor input node: http://learn.adafruit.com/onion-pi/overview Freedom Box is working on low-power home servers with goals overlapping yours. They use a different machine as their reference server, but it should work on Pi. There is some discussion in their mailing list archive: http://freedomboxfoundation.org/ ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: Intel to also add RNG
On 7/13/10, Perry E. Metzger pe...@piermont.com wrote: It is disturbing to me that people oppose this so much. Yes. A hardware RNG seems an obvious Good Thing. Not a complete solution, but a very useful component. For a lot of applications -- servers run in isolation, networking equipment, etc. -- having hardware RNGs available is a really big win, because there is no good local source of randomness. (We had a long discussion of ways to mitigate this some time ago.) Plugging in an external unit is not going to happen in practice. If it isn't nearly free and built in, it won't be used. IPsec gateways and web servers doing a lot of SSL are obvious cases. Neither has much mouse or keyboard activity, they may have solid state drives or smart RAID so disk timings are not random. Packet timings might be somewhat random, but they may also be knowable by an enemy. I would suggest that in most cases, you are better off with a very very mildly untrusted but ubiquitous hardware RNG than with the kinds of kludges to get random numbers on unattended hardware we end up with in the real world. In some cases, a non-kludge alternative is Turbid: http://www.av8n.com/turbid/paper/turbid.htm That uses a sound card or on-board equivalent. Some boards will have this, or it is cheap easy to stick in a slot. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
What is required for trust?
India recently forbade some Chinese companies from bidding on some cell phone infrastructure projects, citing national security concerns: http://www.chinatechnews.com/2010/05/25/12102-indias-bsnl-excludes-chinas-huawei-zte-from-gsm-bidding Of course, the Chinese gov't and companies are by no means the only ones one might worry about. ATT and other US telcos have given customer data to the NSA. What about fear of NSA trickery in Lucent products? Or French intelligence in Alcatel? Or Israeli or Taiwan or whoever? In all cases, you can argue about how plausible such threats are, but it seems clear they are not utterly implausible. Nor are the companies the only threat. Cisco and many other firms have factories in China; if you are worried about Huawei colluding with government here to spy on or sabotage other nations, then you likely have to worry about that government slipping a team into Cisco staff to subvert those products. I don't think this threat is realistic, but I could be wrong. The main devices to worry about are big infrastructure pieces -- telephone switches, big routers and the like. However, those are by no means the only potential targets. Small home routers and various embedded systems are others. So, if one is building some sort of hardware that people may be reluctant to buy because of security concerns, what does it take to reassure them? Obviously, this is going to vary with both the application and the people involved, but can we say anything useful in general? Standard components help. If you use IPsec, or AES, or a commodity processor, I can have some confidence in those parts, though I'll still worry about other things. Use your own protocol or crypto algorithm and I definitely won't trust it without publication and a lot of analysis. Put big lumps of your own VLSI on the board and I'll worry about what might be hidden in them. Openness helps. Put an open source OS on the thing and give me the application code in source for auditing. If you must use some VLSI or FPGA parts, publish source for those. Auditing helps. Intel got outsiders to audit their random number generator. This is probably needed for some critical components, but which? All of those help, but are they enough? If not, what else is needed? Or is this an impossible task? - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: hedging our bets -- in case SHA-256 turns out to be insecure
On 11/12/09, David-Sarah Hopwood david-sa...@jacaranda.org wrote: Sandy Harris wrote: On 11/8/09, Zooko Wilcox-O'Hearn zo...@zooko.com wrote: Therefore I've been thinking about how to make Tahoe-LAFS robust against the possibility that SHA-256 will turn out to be insecure. [...] Since you are encrypting the files anyway, I wonder if you could use one of the modes developed for IPsec where a single pass with a block cipher gives both encrypted text and a hash-like authentication output. That gives you a free value to use as H3 in my scheme or H2 in yours, and its security depends on the block cipher, not on any hash. Tahoe is intended to provide resistance to collision attacks by the creator of an immutable file: the creator should not be able to generate files with different contents, that can be read and verified by the same read capability. An authenticated encryption mode won't provide that -- unless, perhaps, it relies on a collision-resistant hash. I was suggesting using the authentication data in the construction: C(x) = H1(H2(x)||A(x)) where H1 is a hash with he required output size, H2 a hash with a large block size and A the authentication data from your encryption. This is likely a very bad idea if you already use that data in some other way, e.g. for authenticating stored data. However, if C is going to be your authentication mechanism, then this might be a cheap way to get one input to it. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: hedging our bets -- in case SHA-256 turns out to be insecure
On 11/8/09, Zooko Wilcox-O'Hearn zo...@zooko.com wrote: Therefore I've been thinking about how to make Tahoe-LAFS robust against the possibility that SHA-256 will turn out to be insecure. NIST are dealing with that via the AHS process. Shouldn't you just use their results? We could use a different hash function ... There are fourteen candidates left in the SHA-3 contest at the moment. Several of them have conservative designs and good performance, but there is always the risk that they will be found to have catastrophic design flaws or that a great advance in hash function cryptanalysis will suddenly show how to crack them. Yes, but there's also a risk that whatever you come up with will turn out to be flawed. I propose the following combined hash function C, built out of two hash functions H1 and H2: C(x) = H1(H1(x) || H2(x)) This requires two hash(x) operations. A naive implementation needs two passes through the data and avoiding that does not appear to be trivial. This is not ideal since you seem very concerned about overheads. What about this construction: C(x) = H1(H2(x) || H3(x)) H1 is something that gives the output size you require. Use SHA-256 or choose an AHS candidate conservatively. This only hashes a few blocks so you need not worry much about overheads here. H2 is the 512-bit variant of a different AHS candidate, or Whirlpool, or even Skein-1024. Here speed is a criterion, though of course not the only one. H3 might be some really cheap fast function invented for the situation. As I recall, the GOST hash just used a sum of input blocks, and that's enough to defeat the multi-block attacks. If it is simple enough, you can code it into your implementation of H2 so you only need one pass. Since you are encrypting the files anyway, I wonder if you could use one of the modes developed for IPsec where a single pass with a block cipher gives both encrypted text and a hash-like authentication output. That gives you a free value to use as H3 in my scheme or H2 in yours, and its security depends on the block cipher, not on any hash. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: TLS man in the middle
On 11/6/09, mhey...@gmail.com mhey...@gmail.com wrote: From http://www.ietf.org/mail-archive/web/tls/current/msg03928.html and http://extendedsubset.com/?p=8 From what I gather, when TLS client certificates are used, an attacker can post a command to a victim server and have it authenticated by a legitimate client. I'm in China and use SSL/TLS for quite a few things. Proxy connections, Gmail set to always use https and so on. This is the main defense for me and many others against the Great Firewall. Should I be worrying about man-in-the-middle attacks from the Great Firewall servers? - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Factoring attack against RSA based on Pollard's Rho
On Mon, Jun 8, 2009 at 11:51 AM, Victor Duchovni victor.ducho...@morganstanley.com wrote: On Sun, Jun 07, 2009 at 05:41:00PM -0700, Greg Perry wrote: The significance of this method is the ability to determine any properties of p and q from a simple operation to n. To be blunt, I see no significance of any kind... You have observed that unless N is divisible by 3, p and q are both also not divisible by 3. This is not new, and ... I do not have it to hand, but at one point I had a solution for N = pq = (a-b)(a+b) = a^2 - b^2 where I could find unique values for a^2 and b^2 mod 9, mod 16, or by combining those mod 144. Mod 25, mod 49 et cetera gave constraints but not unique solutions. After playing with this a while, I concluded that it was not actually useful, -- Sandy Harris, Quanzhou, Fujian, China - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Fwd: 80-bit security? (Was: Re: SHA-1 collisions now at 2^{52}?)
On Fri, May 8, 2009 at 10:28 AM, Brandon Enright bmenr...@ucsd.edu wrote: Steven M. Bellovin s...@cs.columbia.edu wrote: On Thu, 30 Apr 2009 17:44:53 -0700 Jon Callas j...@callas.org wrote: The accepted wisdom on 80-bit security (which includes SHA-1, 1024-bit RSA and DSA keys, and other things) is that it is to be retired by the end of 2010. That's an interesting statement from a historical perspective -- is it true? And what does that say about our ability to predict the future, and hence to make reasonable decisions on key length? See, for example, the 1996 report on key lengths, by Blaze, Diffie, Rivest, Schneier, Shimomura, Thompson, and Wiener, available at http://www.schneier.com/paper-keylength.html -- was it right? It was a best guess by a group of clever and well-informed people. There's no way to tell if it was precisely right, but there's no way to get a better estimate either, short of getting a similar group to re-do the work today. A back-of-the envelope approximation to today's requirements can be had by saying Moore's Law gives twice the computer speed every 18 months, so ciphers needs one more key bit every 18months to keep up. They said minimum 75 bits to keep an existing cipher in service, minimum 90 for any new ones, as of 1996. Add 10 bits to each for a rough estimate as of 2011. Now, even assuming 64 bits is within reach of modern computing power, ... I'd have thought that was obvious, and had been for a decade or so. EFF broke DES in a few days for $200,000 ten years ago. A 64-bit cipher is only 256 times harder, easily within reach on an intelligence agency budget. Copacobana break DES in a week for 9,000 euro. 256 of them would break a 64-bit cipher in a week. This is within reach for a high-stakes industrial espionage situation, say Boeing and Airbus competing for big orders. -- Sandy Harris, Quanzhou, Fujian, China - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: [tahoe-dev] SHA-1 broken!
On Sat, May 2, 2009 at 12:33 PM, Perry E. Metzger pe...@piermont.com wrote: As just one obvious example of a realistic threat, consider that there are CAs that will happily sell you certificates that use SHA-1. Various clever forgery attacks have been used against certs that use MD5, see: http://www.win.tue.nl/hashclash/rogue-ca/ Those attacks can now be extended to SHA-1 pretty easily. It might require a bit of compute infrastructure -- say a lot of FPGAs and a bunch of cleverness -- to turn out certs quickly, but it can be done. Given that there are lots of high value certs out there of this form, this is rather dangerous. Off-the-shelf FPGA-based device that breaks DES by brute force in about a week, costs 9,000 euros: http://www.copacobana.org/ These are commercially available and programmable. Setting a few of them up to break SHA-1 certainly would not be trivial, but it looks feasible. -- Sandy Harris, Quanzhou, Fujian, China - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Destroying confidential information from database
On Mon, Mar 9, 2009 at 10:32 PM, Mads m...@lsitec.org.br wrote: I know of procedures and programs to erase files securely from disks, Guttman did a paper on that Yes, but that paper is over ten years old. In the meanwhile, disk designs and perhaps encoding schemes have changed, journaling file systems have become much more common and, for all I know the attack technology may have changed too. Is there a more recent analysis or is Guttman still the best reference? -- Sandy Harris, Quanzhou, Fujian, China - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: CSPRNG algorithms
On Sat, Mar 14, 2009 at 3:16 AM, Travis travis+ml-cryptogra...@subspacefield.org wrote: I have never seen a good catalog of computationally-strong pseudo-random number generators. It seems that everyone tries to roll their own in whatever application they are using, and I bet there's a lot of waste and inefficiency and re-inventing the wheel involved. If this true, or is there a survey somewhere? If not, would people like to help me create one by emailing me references to extant PRNG definitions? Not complete, but this encyclopedia article has some links: http://en.citizendium.org/wiki/Random_number#Random_sequences_from_physical_phenomena It is a wiki so if you can improve it, please do. No doubt Wikipedia has a list as well. All the usual crypto texts have chapters on it, too. -- Sandy Harris, Quanzhou, Fujian, China - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: CPRNGs are still an issue.
Bill Frantz fra...@pwpconsult.com wrote: Short of building special random number generation hardware, does anyone have any suggestions for additional sources? Any unused input device with noise can be used. Examples: Soundcard: http://www.av8n.com/turbid/ Camera: http://www.lavarnd.org/ If anything in the system changes a lot, like processes starting and stopping or files opening closing, periodically hashing the tables that describe that state is useful. Is your threat model one-sided? e.g. for a home router, attacks from the Internet side might be more of a worry than attacks from the LAN. In that case, things like packet timing on the LAN side are unknown to the feared attacker. Also, if you are doing NAT, the port numbers on the LAN side since those are not sent outside. If the device does any crypto, mixing ciphertext into the pool is nowhere near ideal since you would not be encrypting unless some enemy might get the text and using things an an enemy can get is exactly what you do not want here. However, it is cheap and random-looking, and the volume is proportional to the amount of crypto done, so it might help in some cases. -- Sandy Harris, Quanzhou, Fujian, China - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Hybrid cipher paper
A paper of mine just went up on http://eprint.iacr.org/ It has some ideas that I hope are new, I think are good, and I know are unorthodox. I'm well aware of the usual fate of such innovations, especially from amateurs. If anyone would like a break from looking at new hashes, perhaps they could have a look. Number2008/473 Title Exploring Cipherspace: Combining stream ciphers and block ciphers Abstract: This paper looks at the possibility of combining a block cipher and a stream cipher to get a strong hybrid cipher. It includes two specific proposals for combining AES-128 and RC4-128 to get a cipher that takes a 256-bit key and is significantly faster than AES-256, and arguably more secure. One is immune to algebraic attacks. -- Sandy Harris, Quanzhou, Fujian, China - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: combining entropy
John Denker [EMAIL PROTECTED] wrote: To say the same thing in more detail: Suppose we start with N generators, each of which puts out a 160 bit word containing 80 bits of _trusted_ entropy. That's a 50% entropy density. So you need a 2:1 or heavier compression that won't lose entropy. If you just need one 160 word out per N in, then hashing them is the obvious way to do that. We next consider the case where N-1 of the generators have failed, or can no longer be trusted, ... XOR is provably correct because it is _reversible_ in the thermodynamic sense. That means it cannot increase or decrease the entropy. Yes, but the proof holds for any reversible mapping. XOR makes each output bit depend on exactly two inputs bits. Sometimes you want a mapping that mixes them better. If one input is entirely random, XOR is fine; random ^ x is random for any x. It is also fine in the case above, where only one generator works. If 1 inputs have some entropy but none have enough, which seems to me the commonest case, XOR is not the best choice; it does not mix well enough. Nyberg's perfect s-boxes are in some ways the ideal mixer. 2n bits in, n out, all columns and all linear combinations of columns are bent functions. Big S-boxes are expensive though, and building even small Nyberg S-boxes is going to take significant effort. Designing something that uses a bunch of say 8 by 4 S-boxes to do good mixing on 160-bit chunks is not trivial either. You could use IDEA multiplication in mixing. Two 16-bit words in, one out, and every output bit depends on all input bits. If every 16-bit input word has 50% entropy density (not the same as every 160-bit word does, but perhaps close enough) then the output should have 100%. For N 1, you need to combine those and worry about overall mixing. If entropy density is known to be ~50%, you can combine pairs with IDEA to get ~100%, then use cheaper operations for any other mixing needed. I'd use addition, which costs about the same as XOR but gives slightly better mixing because of carries. For N 2 and density 50%, you could use a cascade of IDEA operations 8-4-2-1 or whatever. Or do something like: combine two 160-bit chunks with 10 IDEA multiplications, circular shift the result 8 bits, combine with next 160-bit input, ... At some point, you may find yourself designing a hash. If that happens, just give up and use a standard hash. -- Sandy Harris, Quanzhou, Fujian, China - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Cruising the stacks and finding stuff
Jack Lloyd [EMAIL PROTECTED] wrote: Making a cipher that uses an N bit key but is only secure to 2^M operations with MN is, firstly, considered broken in many circles, as well as being inefficient (why generate/transmit/store 512 bit keys when it only provides the security of a ~300 bit (or whatever) key used with a perfect algorithm aka ideal cipher - why not use the better cipher and save the bits). Saving bits may not matter, or may not be possible. For example, if you are ealing with a hybrid system -- say, using RSA to transmit the symmetric cipher key or Diffie-Hellamn to construct it -- then for any symmetric cipher key size less than the public key size, your overheads are the same. -- Sandy Harris, Nanjing, China - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Cruising the stacks and finding stuff
Perry E. Metzger [EMAIL PROTECTED] wrote: Now, it is entirely possible that someone will come up with a much smarter attack against AES than brute force. I'm just speaking of how bad brute force is. The fact that brute force is so bad is why people go for better attacks, and even the A5/1 attackers do not use brute force. I'd suggest that Allen should be a bit more careful when doing back of the envelope calculations... Another back-of-the-envelope estimate would be to look at the EFF machine that could brute force s 56-bit DES key in a few days and cost $200-odd thousand. That was 10 years ago and Moore's Law applies, so it should be about 100 times faster or cheaper now. Round numbers are nice. Overestimating the attacker a bit is better than underestimating. So assume an attacker can brute force a a 64-bit key (256 times harder than DES) in a second (a few 100 thousand times faster). Brute force against a 96-bit key should take 2^32 times as long. Since pi seconds is a nano-century, that's somewhat over a century. For a 128-bit key, over 2^32 centuries. If brute force is the best attack, this is obviously secure. -- Sandy Harris, Nanjing, China - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Gutmann Soundwave Therapy
What I don't understand is why you think tinc is necessary, or even worth the trouble. IPsec is readily available -- built into Windows, Mac OS and various routers, and with implementations for Linux and all the *BSDs -- has had quite a bit of expert security analysis, and handles VPNs just fine. Does tinc do something that IPsec cannot? -- Sandy Harris, Nanjing, China - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Death of antivirus software imminent
On Jan 12, 2008 9:32 AM, Alex Alten [EMAIL PROTECTED] wrote: Generally any standard encrypted protocols will probably eventually have to support some sort of CALEA capability. ... That's a rather large and distinctly dangerous assumption. Here's the IETF's official line on the question, the abstract section of RFC 2084: The Internet Engineering Task Force (IETF) has been asked to take a position on the inclusion into IETF standards-track documents of functionality designed to facilitate wiretapping. This memo explains what the IETF thinks the question means, why its answer is no, and what that answer means. http://www.faqs.org/rfcs/rfc2804.html The whole question was extensively discussed on an IETF mailing list set up for the purpose before that RFC was written: http://www1.ietf.org/mail-archive/web/raven/current/index.html The aptly named RFC 1984 is also relevant. Among the more obvious problems are the fact that complexity is bad for security, that the US government has some history of abusing wiretaps, and that other governments who would have access to any such technology are even less trustworthy. -- Sandy Harris, Nanjing, China - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Password vs data entropy
On 10/26/07, Alex Pankratov [EMAIL PROTECTED] wrote: Or, rephrasing, what should the entropy of the password be compared to the entropy of the value being protected (under whatever keying/encryption scheme) ? The entropy of the data is irrelevant. The question is its value; that affects both the resources an attacker might use to get it and the cost to you if it is lost. If there is no attack on the crypto algorithm better than brute force (a huge if!, but there are available algorithms for which we can at least say no such attack has been published) and you can estimate attacker's resources, then you can estimate key size required for safety. Te EFF's DES cracker (many custom-built chips in parallel) broke 56-bit DES in a few days. Assume our brute force enemy can search a 64-bit space (256 times larger) in a second (a few million times faster). Then searching a 96-bit space takes him 2**32 seconds, well over a century. For a 128-bit space, multiply that by another 2**32, so something over 400 billion years. You really don't care about minor variation here, e.g.if our estimates are off by a million and he can do it in 400 million years instead. So, if your crypto is sound,128 bits should theorectically be enough for any data and any human time scale. Practice and theory can differ, though, and you cannot be utterly certain there's not some unpublished attack that does awful things to the crypto. I'd use 256 bits and a well-analyzed algorithm. -- Sandy Harris, Nanjing, China - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: ad hoc IPsec or similiar
On 6/23/07, Eugen Leitl [EMAIL PROTECTED] wrote: The general idea is that if you use keys in DNS to authenticate gateways Aye, that's the rub. Most hosts are in dynamic address space, and anything involving DNS will not fly. It is certainly a problem, but you can get around it partially even if your IP address is dynamically assigned: http://www.freeswan.org/freeswan_trees/freeswan-2.00/doc/quickstart.html#opp.client You do need to use a dynamic DNS server to handle your keys, but there are lots of those, and many do provide that service. Also, this is limited to initiate-only IPsec; it does not handle incoming connections. However, that may be enough for many client machines that live in dynamic address space. -- Sandy Harris Quanzhou, Fujian, China - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: ad hoc IPsec or similiar
On 6/22/07, Eugen Leitl [EMAIL PROTECTED] wrote: So what's the state in ad hoc IPsec/VPN setup for any end points? The Linux FreeS/WAN project was working on opportunistic encryption. The general idea is that if you use keys in DNS to authenticate gateways and IPsec for secure tunnels then any two machines can communicate securely without their administrators needing to talk to each other or to set up specific pre-arranged tunnels. http://www.freeswan.org/freeswan_trees/freeswan-2.00/doc/glossary.html#carpediem http://www.freeswan.org/freeswan_trees/freeswan-2.00/doc/quickstart.html There is an RFC based on that work: ftp://ftp.rfc-editor.org/in-notes/rfc4322.txt The FreeS/WAN project has ended. I do no know if the follow-on projects, openswan.org and strongswan.org, support OE. -- Sandy Harris Quanzhou, Fujian, China - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Entropy of other languages
Travis H. [EMAIL PROTECTED] wrote: On Wed, Feb 07, 2007 at 05:42:49AM -0800, Sandy Harris wrote: He starts from information theory and an assumption that there needs to be some constant upper bound on the receiver's per-symbol processing time. From there, with nothing else, he gets to a proof that the optimal frequency distribution of symbols is always some member of a parameterized set of curves. Do you remember how he got from the upper bound on processing time to anything other than a completely uniform distribution of symbols? No. There was some pretty heavy math in the paper. With it in my hand, I understood enough to follow the argument. 20 years later with no paper to hand, I haven't a clue. Paper is likely somewhere under his home page. http://www.math.yale.edu/mandelbrot/ Seems to me a flat distribution has the minimal upper bound on information content per symbol for a given amount of information! Probably, but he did have a proof that the skewed distribution is more efficient in some ways. -- Sandy Harris Quanzhou, Fujian, China - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Entropy of other languages
Allen [EMAIL PROTECTED] wrote: An idle question. English has a relatively low entropy as a language. Don't recall the exact figure, but if you look at words that start with q it is very low indeed. What about other languages? Does anyone know the relative entropy of other alphabetic languages? What about the entropy of ideographic languages? Pictographic? Hieroglyphic? The most general answer is in a very old paper of Mandelbrot's. Sorry, I don't recall the exact reference or have it to hand. He starts from information theory and an assumption that there needs to be some constant upper bound on the receiver's per-symbol processing time. From there, with nothing else, he gets to a proof that the optimal frequency distribution of symbols is always some member of a parameterized set of curves. Pick the right parameters and Mandelbrot's equation simplifies to Zipf's Law, the well-known rule about word, letter or sound frequencies in linguistics. I'm not sure if you can also get Pareto's Law which covers income wealth distributions in economics. -- Sandy Harris Quanzhou, Fujian, China - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Entropy Definition (was Re: passphrases with more than 160 bits of entropy)
Aram Perez [EMAIL PROTECTED] wrote: So, if you folks care to educate me, I have several questions related to entropy and information security (apologies to any physicists): I'll answer the easier questions. I'll leave the harder ones for someone with a better grounding in information theory. * What is the relationship between randomness and entropy? Roughly, they both measure unpredictability. Something that is hard to predict is random, or has high entropy. There are mathematical formulations that make this a lot more precise, but that's the basic idea. * Does processing an 8 character password with a process similar to PKCS#5 increase the entropy of the password? Absolutely not! At best, you preserve the original entropy, just distributing it differently. If you get the processing wrong, you can reduce or even entirely destroy it, but no amount of any kind of processing can increase it. * Can you add or increase entropy? You can add more entropy, either from another source or more from the same source. That is the only way to increase it. -- Sandy Harris Zhuhai, Guangdong, China - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: 3DES performance
Lee Parkes wrote: Hi, I'm working on a project for a company that involves the use of 3DES. They have asked me to find out what the overheads are ... Some info at: http://www.freeswan.org/freeswan_trees/freeswan-2.06/doc/performance.html - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: potential new IETF WG on anonymous IPSec
Zooko O'Whielcronx wrote: On 2004, Sep 09, , at 16:57, Hal Finney wrote: ... 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. No. It can also use RSA public keys without embedding them in certificates or requiring a CA, let alone a 3rd party one. The new proposal would let connections go forward using a straight Diffie-Hellman type exchange without authentication. I don't think anonymous is the right word for this, and I hope the IETF comes up with a better one as they go forward. Sounds right to me, though unauthenticeted might be more precise. I believe that in the context of e-mail [1, 2, 3, 4] and FreeSWAN this is called opportunistic encryption. That is certainly not what FreeS/WAN meant by opportunistic encryption. http://www.freeswan.org/freeswan_trees/freeswan-1.99/doc/glossary.html#carpediem OE does authenticate all connections. The trick is that the public keys are stored in DNS so you do not have to exchange keys with the admin of a site before you can do secure communications to it. For this to be secure, you need DNSsec widely deployed. In effect you are using DNS as a PKI. Without DNSsec, this reduces to something fairly anonymous -- anyone who can lie in DNS can pretend to be anyone they choose. However, that was never the design intent of OE. If you want anonymous connections, there are easier ways. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: cryptograph(y|er) jokes?
bear wrote: Bob and Alice routinely discuss bombs, terrorism, tax cheating, sexual infidelity, and deviant sex over the internet. They conspire to commit crimes, share banned texts and suppressed news, or topple tyrannical governments whose agents eavesdrop on their every communication. They do all this with utmost secrecy and unbreakable codes. However, Alice and Bob do not even trust each other. A protocol designer then, is someone who does not think that Alice and Bob are insane. For the original, see: http://www.conceptlabs.co.uk/alicebob.html - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: cryptograph(y|er) jokes?
Hadmut Danisch wrote: does anyone know good jokes about cryptography, cryptographers, or security? There's always the sys admin's mantra: I know I'm paranoid, but I worry about whether I'm paranoid enough. FreeS/WAN docs have links to several collections of crypto quotes, many funny: http://www.freeswan.org/freeswan_trees/freeswan-2.06/doc/web.html#quotes - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: efficiency?? vs security with symmetric crypto? (Re: Tinc's response to Linux's answer to MS-PPTP)
Adam Back wrote: What conceivable trade-offs could you have to make to get acceptable performance out of symmetric crypto encrypted+authenticated tunnel? All ciphers you should be using are like 50MB/sec on a 1Ghz machine!! There's fairly detailed performance data for Linux FreeS/WAN IPsec http://www.freeswan.org/freeswan_trees/freeswan-2.02/doc/performance.html It's around 50 M bit/second on a GHz machine with 3DES. You can roughly double that with AES. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: authentication and ESP
John S. Denker wrote: On 06/19/2003 01:49 PM, martin f krafft wrote: As far as I can tell, IPsec's ESP has the functionality of authentication and integrity built in: It depends on what you mean by built in. 1) The RFC provides for ESP+authentication but does not require ESP to use authentication. 2) Although the RFC allows ESP without authentication, typical implementations are less flexible. In FreeS/WAN for instance, if you ask for ESP will get ESP+AH. ESP without authentication may be vulnerable to replay attacks and/or active attacks that tamper with the bits in transit. The degree of vulnerability depends on details (type of chaining, higher-level properties of payload, ...). There's some discussion and links in the FreeS/WAN docs: http://www.freeswan.org/freeswan_trees/freeswan-2.00/doc/ipsec.html#encnoauth - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
