Opinions regarding PointSec "Protect!"
We're trying to evaluate a security product called "Protect!" from Pointsec Mobile Technologies Inc. Their public information is scant, at best; a white paper about their encryption says enough good words to be not obviously snake oil, but not enough to actually feel confident about the product either. Does anyone have any experience with the product, or know more about its actual security? Please reply to me, and I'll summarise afterward. thanks, Greg.
Re: 3G crypto algorithms
You're missing the document that specifies f8 and f9, which is the glue between 33.102 and the Kasumi spec. Unfortunately I can't get to their server at the moment for some reason, so I can't give you it's number, but I think it is 33.2xx. thanks and regards, Greg. At 01:53 PM 1/19/2001 -0500, Janos A. Csirik wrote: >Dear cryptographers, > >In contrast with GSM, the 3GPP organisation (responsible for 3G >wireless phone standards) is making all of its documents public. >However, the way in which these documents are made public is >unlikely to result in immediate gratification for those who would >just like to go in and look at the crypto algorithms. > >For that reason, I have undertaken to construct a Web page to >help cryptographers learn about and study the crypto algorithms >for 3G wireless phones. I believe that the algorithms will >receive much more and better scrutiny if it is easy to find them >(and other 3G documents that are relevant to them). This page >can be found at > > http://www.research.att.com/~janos/3gpp.html > >Thank you for your attention! > >Janos A. Csirik. >-- >Janos A. Csirik, Mathematics & Cryptography, AT&T Labs - Research > > Greg Rose INTERNET: [EMAIL PROTECTED] Qualcomm Australia VOICE: +61-2-9817 4188 FAX: +61-2-9817 5199 Level 3, 230 Victoria Road,http://people.qualcomm.com/ggr/ Gladesville NSW 2111232B EC8F 44C6 C853 D68F E107 E6BF CD2F 1081 A37C
want speaker about traffic analysis
I'm organising the Invited Talks track of the next USENIX Security Symposium, to be held in Washington DC 13-17th August. We've had a couple of requests for a talk about Traffic Analysis -- what it is, how it works, maybe some anecdotes, defence against it, related privacy issues, and so on. The trouble is, I'm having difficulty locating a good speaker for the topic. (I'm sure there are a couple at Fort Meade, but...) If anyone wants to nominate someone (perhaps themselves) who might be able to give a ~1 hour talk on this subject in return for free registration at the conference and public recognition, please pass on this message, or tell me and I'll contact the prospect myself. Any pointers are appreciated. Greg. Greg Rose INTERNET: [EMAIL PROTECTED] Qualcomm Australia VOICE: +61-2-9817 4188 FAX: +61-2-9817 5199 Level 3, 230 Victoria Road,http://people.qualcomm.com/ggr/ Gladesville NSW 2111232B EC8F 44C6 C853 D68F E107 E6BF CD2F 1081 A37C
Re: Cryptographic Algorithm Metrics
A couple of people have taken me to task for complicating the question about One Time Pads. The purpose of my original text was just to say that yes, there are other useful and deployed algorithms out there that have unconditional security, and that it is not the case that One Time Pads are special in that sense. I have often seen the claim that "only one time pads are provably secure", and this bugs me. >Greg Rose wrote: > > > > At 11:01 PM 1/3/2001 +, someone wrote: > > >Don't you think that's a pretty good reason for singling it out? Is > > >there any additional merit in the more complex realisations? > > > > I just meant that there's a widespread assumption that the *only* > > unconditionally secure algorithm is the One Time Pad. This assumption is > > incorrect. But I don't think it is worth cluttering the list with this > > point... I shouldn't have said anything. > >Well, it may be, but that would require answering the second question in >the affirmative: do they have any additional merit? Well, I gave one example. Shamir Secret Sharing is: . unconditionally information-theoretically secure . requires truly random information to be secure . is clearly useful . is implemented in a number of publicly available packages . is not equivalent to a one-time-pad except in a degenerate case >Clearly I can obfuscate any crypto algorithm by adding other stuff to it >(e.g. Blowfish+RSA by using the first two primes above the key to >generate an RSA key) but it doesn't get us anywhere. Yes, there are an infinite number of ways to use shared random information in complicated ways, or to complicate other algorithms, but that wasn't what I was getting at. >What intrigues me is the idea that there may (or may not) be more to the >methods you describe than mere obfuscation, though I doubt there is. To further expand the stated example, the way Shamir secret sharing works is to give to n parties information such that any t (threshold) of them can reconstruct the secret. It does this by choosing AT RANDOM t-1 coefficients of a t-th degree polynomial, and using the secret data as the other coefficient. The "shares" are the values of the polynomial evaluated at independent points. When you have only t-1 data points, the interpolating polynomial is incompletely specified, and the set of possible polynomials (and therefore the set of possibilities for the secret) is as large as the underlying group. When there are t data points available, the interpolating polynomial is completely specified, and the data is uniquely revealed. See page 526 of the Handbook of Applied Cryptography for the full detail here, in particular note 12.72. I claim that this is not obfuscation, and is a non-trivial application. QED. I guess I should mention that the packages I've looked at that implement it use non-random numbers generated for example by DES, thus artificially limiting its security (for example, with two shares, one could brute-force the DES key to verify guesses for the "randomly generated" coefficients and recover the secret, even if more than two shares were otherwise needed). So it really is like the OTP in that regard -- if the numbers are truly random, it is provably perfectly secure, but if they aren't, all bets are off. >Feel free to reply to this on the list. :-) Done. regards, Greg. Greg Rose INTERNET: [EMAIL PROTECTED] Qualcomm Australia VOICE: +61-2-9817 4188 FAX: +61-2-9817 5199 Level 3, 230 Victoria Road,http://people.qualcomm.com/ggr/ Gladesville NSW 2111232B EC8F 44C6 C853 D68F E107 E6BF CD2F 1081 A37C
Re: Cryptographic Algorithm Metrics
At 03:06 PM 1/3/2001 -0500, John Young wrote: >Yes, the one-time pad. However, I wondered if Smith >was hinting at another cipher(s) not yet publicized, >perhaps computational -- or more exotic technology >such as quantum, DNA, ultra-spectral and beyond. It always amazes me that people single out the OTP here. There are any number of other algorithms that are unconditionally secure. The simplest is Shamir's secret sharing, when you don't have enough shares. At Crypto a couple of years ago the invited lecture gave some very general results about unconditionally secure ciphers... unfortunately I can't remember exactly who gave the lecture, but I think it might have been Oded Goldreich... forgive me if I'm wrong. The important result, though, was that you need truly random input to the algorithm in an amount equal to the stuff being protected, or you cannot have unconditional security. The OTP is just the simplest realisation of this. Greg. NOTE NEW ADDRESS AND PHONE NUMBERS BELOW! Greg Rose INTERNET: [EMAIL PROTECTED] Qualcomm Australia VOICE: +61-2-9817 4188 FAX: +61-2-9817 5199 Level 3, 230 Victoria Road,http://people.qualcomm.com/ggr/ Gladesville NSW 2111232B EC8F 44C6 C853 D68F E107 E6BF CD2F 1081 A37C
Re: IBM press release - encryption and authentication
At 05:14 PM 12/11/2000 -0800, Nikita Borisov wrote:
>But in his examples, addition mod 2^128 - 159 can be implemented rather
>quickly:
>
>S_i = S_{i-1} + b [regular 128-bit addition]
>if (b > S_i) S_i += 159
Ahhh, yes, a classical example of premature optimisation. This is, of
course, a different definition of modular arithmetic than most people would
use.
Suppose that the result of the addition S_i falls into the range
[2^128-159 .. 2^128)
then his nice quick method gives an answer that isn't reduced at all,
whereas it really ought to be in the range [0 .. 159) by most people's
definitions of modular arithmetic.
So long as both ends use the broken method, or you aren't terribly unlucky
(since only about 1 in 2^121 calculations will hit this case), it will all
still work.
Greg.
Greg Rose INTERNET: [EMAIL PROTECTED]
Qualcomm Australia VOICE: +61-2-9181-4851 FAX: +61-2-9181-5470
Level 3, 230 Victoria Road,http://people.qualcomm.com/ggr/
Gladesville NSW 2111232B EC8F 44C6 C853 D68F E107 E6BF CD2F 1081 A37C
Re: Oh for a decently encrypted mobile phone...
At 22:08 00/09/13 -0700, Bram Cohen wrote: >Wouldn't it be ironic if they resort to buying a bunch of stariums ... >-Bram Cohen > >[That would require that Stariums actually appear on the market at >some point. --Perry] Stariums (a) should appear RSN (I have one) but (b) are not mobile. There's the Qsec-800 CDMA mobile from Qualcomm, but that won't work in England I don't think. See http://www.qualcomm.com/govsys/qsec.html . Disclaimer: I work for one and invest in both, so I'm biased. Greg. Greg Rose INTERNET: [EMAIL PROTECTED] Qualcomm AustraliaVOICE: +61-2-9181-4851 FAX: +61-2-9181-5470 Suite 410, Birkenhead Point, http://people.qualcomm.com/ggr/ Drummoyne NSW 2047232B EC8F 44C6 C853 D68F E107 E6BF CD2F 1081 A37C
reflecting on PGP, keyservers, and the Web of Trust
I use PGP actively on a daily basis. Nevertheless, I have been disillusioned for some time, and today's fun prodded me into writing this. Here is a list of things which I consider to be problems with "the PGP Scene": . PGP might be the easiest crypto package to use, but it's still an order of magnitude too hard. (See "Why Johnny Can't Encrypt", by Alma Whitten and Doug Tygar, http://www.usenix.org/publications/library/proceedings/sec99/whitten.html ) . The keyservers are polluted. My own keys have old, stale email addresses on them, and no matter how hard I try to keep the current addresses at the top, sometimes a stale key will come in and reorder them again. . More keyserver pollution is caused by people signing keys so that PGP doesn't warn them about using untrusted keys, and then the signatures "escape" to keyservers somehow. Newer versions try to address this by making it explicit whether the signature should be exportable or not, but... . The keyservers are inadequate too. Unless keys appear on them, they don't help, yet people often don't seem to put their keys there. . There are disjoint groups of keyservers which don't communicate updates. . Many of the keys now on the keyservers are only self-signed, and don't contribute to the Web of Trust at all (except to slow down the keyservers). This is at least partly an education problem: new users have enough trouble creating a key, without actually getting connected into the WoT. . I find that interoperability problems are finally reducing in magnitude again, but they fragmented the PGP world so badly that important services were dismantled. In short, PGP is only useful to me, today, to communicate to a small group of well informed people who I know personally or through very close mutual friends. Funnily enough, that is *exactly* where we were nearly 10 years ago! Has PGP failed? To answer my own question, I don't think it has failed. It very much helped to awaken and mobilise the public, and I *do* use it a lot. But it hasn't really succeeded either. There is a lot more work to be done yet. I blame it on PKI. Greg. Greg Rose INTERNET: [EMAIL PROTECTED] Qualcomm AustraliaVOICE: +61-2-9181-4851 FAX: +61-2-9181-5470 Suite 410, Birkenhead Point, http://people.qualcomm.com/ggr/ Drummoyne NSW 2047232B EC8F 44C6 C853 D68F E107 E6BF CD2F 1081 A37C
Re: Elgamal
At 21:02 00/07/19 +0100, Simon Aronson wrote: >In an implementation of the ElGamal cryptosystem, is it acceptable to always >use the same prime and generator for every transmission? Or should a new >prime/generator pair be chosen for each communication? Yes, in fact you pretty much have to, since they are used to create the public key from the private key. Except for creating a very big target, there's no real reason why eveyone shouldn't share the same prime and generator; IPSec standardises a couple (of different sizes). Greg. Greg Rose INTERNET: [EMAIL PROTECTED] Qualcomm AustraliaVOICE: +61-2-9181-4851 FAX: +61-2-9181-5470 Suite 410, Birkenhead Point, http://people.qualcomm.com/ggr/ Drummoyne NSW 2047232B EC8F 44C6 C853 D68F E107 E6BF CD2F 1081 A37C
Re: secret-sharing code
At 13:22 29/03/2000 +0930, Steve Bellovin wrote: >Are there any freely-available secret-sharing packages around? Specifically, >I need to be able to set up modestly complex policies to protect a sensitive >signature key. > >While source code would be best, I'd also be interested in smart card-based >products. I use Hal Finney's "secsplit". Google found it in a couple of places; it doesn't seem to have been updated since 1993. It doesn't do the more complicated schemes, just straight (m, k) splitting. regards, Greg. Greg Rose INTERNET: [EMAIL PROTECTED] Qualcomm AustraliaVOICE: +61-2-9181-4851 FAX: +61-2-9181-5470 Suite 410, Birkenhead Point, http://people.qualcomm.com/ggr/ Drummoyne NSW 2047232B EC8F 44C6 C853 D68F E107 E6BF CD2F 1081 A37C
Re: Looking for a cryptographic primitive
At 05:50 9/03/2000 -0800, bram wrote: >Does anybody know of a field in which a + b and a * b can be computed >quickly but (and this is important) it's computationally intractable to >compute the additive inverse of a? If you literally mean "field", there must be a multiplicative identity, called "1". If you calculate its additive inverse, which is surely tractable as a one-time computation, then additive inverses generally can be computed as x*-1, which you postulate to be easy. Greg. Greg Rose INTERNET: [EMAIL PROTECTED] Qualcomm AustraliaVOICE: +61-2-9181-4851 FAX: +61-2-9181-5470 Suite 410, Birkenhead Point, http://people.qualcomm.com/ggr/ Drummoyne NSW 2047232B EC8F 44C6 C853 D68F E107 E6BF CD2F 1081 A37C
Re: Debit card fraud in Canada
At 10:49 13/12/1999 -0500, Steven M. Bellovin wrote: > If so, a simple visual recorder -- already used by >other thieves -- might suffice, and all the tamper-resistance in the world >won't help. Crypto, in other words, doesn't protect you if the attack is on >the crypto endpoint or on the cleartext. This doesn't work. The PIN is derived by adding a "PIN Offset" which is stored on the magstripe to the "Real PIN" which is cryptographically derived from the account information. If you can't duplicate the magstripe the pin you have shoulder-surfed is useless. (To caveat my own words... this is one of the internationally standardised and widely deployed methods. I don't know how the other ones handle this problem.) Greg. Greg Rose INTERNET: [EMAIL PROTECTED] Qualcomm AustraliaVOICE: +61-2-9181-4851 FAX: +61-2-9181-5470 Suite 410, Birkenhead Point, http://people.qualcomm.com/ggr/ Drummoyne NSW 2047232B EC8F 44C6 C853 D68F E107 E6BF CD2F 1081 A37C
Re: having source code for your CPU chip -- NOT
At 09:02 23/09/1999 -0400, Steven M. Bellovin wrote: >By example, I >could verify the machine code for IDEA, but not PGP and certainly not your >favorite version of UNIX. Actually, while there are bugs and security holes, it's pretty certain that V6 Unix didn't have any crypto trapdoors ... and you can now own your very own source code license for early Unix including C compiler, complete with source for a PDP-11 emulator to run it on... this might come in handy one day as a stable, recreatable base. See http://minnie.cs.adfa.edu.au/PUPS , the PDP and Unix Preservation Society. [Of course, what guarantees does one have about the provenance of the code? --Perry] regards, Greg. Greg Rose INTERNET: [EMAIL PROTECTED] Qualcomm Australia VOICE: +61-2-9181-4851 FAX: +61-2-9181-5470 Suite 410, Birkenhead Point, http://people.qualcomm.com/ggr/ Drummoyne NSW 2047 232B EC8F 44C6 C853 D68F E107 E6BF CD2F 1081 A37C
Re: message-signing at the MTA level
At 22:09 21/08/1999 -0400, Russell Nelson wrote: >I've been thinking about cryptographic signing of messages at the mail >transfer agent level. I can think of how to do it, but I'm not sure >what problem it solves. :) Anyone have any ideas? Signing messages at the MTA level solves no problem at all unless there's a widely deployed PKI. >[I remember that someone in Australia built some experimental patches >to do this for sendmail some time back. That was me/us. There's a paper coming up and a rerelease of the software in about three weeks. I'll send another message then. regards, Greg. Greg Rose INTERNET: [EMAIL PROTECTED] Qualcomm Australia VOICE: +61-2-9181-4851 FAX: +61-2-9181-5470 Suite 410, Birkenhead Point, http://people.qualcomm.com/ggr/ Drummoyne NSW 2047 232B EC8F 44C6 C853 D68F E107 E6BF CD2F 1081 A37C
Re: Proposal (was Summary re: /dev/random)
At 19:49 1/08/99 -0700, bram wrote: >No, block ciphers are weak against related-key attacks, which happen all >over the place in the threat model on SRNGs. I think this statement is overly general. Most of the AES candidates appear to have taken this into consideration, for example. There is nothing inherent in the concept of a block cipher which would imply that there would be a weakness against related key attacks; however it is true that many key scheduling algorithms have been too simplistic in the past. Greg. Greg Rose INTERNET: [EMAIL PROTECTED] Qualcomm Australia VOICE: +61-2-9181-4851 FAX: +61-2-9181-5470 Suite 410, Birkenhead Point, http://people.qualcomm.com/ggr/ Drummoyne NSW 2047 232B EC8F 44C6 C853 D68F E107 E6BF CD2F 1081 A37C
Salt (was: ICSA certifies weak crypto as secure)
At 16:38 1/06/99 -0400, it was written: >At 11:48 AM -0400 6/1/99, Steven M. Bellovin replied to John Kelsey ><[EMAIL PROTECTED]> message: >>Why 32 bits? Salts are good, and often cheap, but I'm curious what your >>rationale is. Traditionally, a salt serves two purposes: to increase the >>expense (CPU and storage) of precomputing a dictionary, and to make it harder >>to find two passwords with the same salt. UNIX uses a 12-bit salt, which is >>often quite sufficient. Given a million-entry dictionary, and using your >>number of .5 seconds/guess, with no salt at all it would take ~139 hours to >>precompute the hash of all guesses. Clearly, that's too low. But 4096*139 >>is ~24000 days. Granted, that process can be parallelized, but it's still >>a lot of computing -- 240 days for a hundred machines crunching. > >I would argue that UNIX is an excellent object lesson for John's point. 12 >bits was a bad design decision, even in the 70's. I take exception to this last statement. The design (of the salted passwords) was done in the late 70s, and given the constraints of the time was quite a reasonable decision. Remember that memory and long term storage on PDP-11s was tight. The machines couldn't possibly support user populations greater than hundreds (in particular, UIDs were only 8 bits!); 10-12 was typical, and 40 was a hugely overloaded university. Therefore, 2^12 salts came pretty close to guaranteeing uniqueness of the passwords on each machine. Networking was *not* common, let alone ubiquitous, so gathering password files off other machines was not part of the threat model. And lastly, as with any security design, all you need to do is move the weak point somewhere else; nobody tries to precompute the lists (well, let's face it, you're not stopping the people who *do*), because cracking them individually is essentially more cost efficient... so the salt did what it was designed to do. In fact, I think that (intentionally or not) this choice makes a great example of the right kind of engineering tradeoffs. As Bruce Schneier recently said more eloquently than I, anyone can overengineer it... designing to constraints is much harder and more interesting. People who believe in day-to-day use of One Time Pads (I'm not accusing anyone here of this :-) ) are merely the furthest away from practicality. Today, the design parameters are not so tight; even inside mobile phones, we are looking at 32 bits of salt; why not? We have 32 bits of spare stuff lying around that we can use and SHA will take the same time no matter what we shove in (note: can't store it or communicate it, we have to use what both ends already know and can agree on). But if there didn't happen to be 32 bits lying around... say only 16 bits... we'd be happy with that. Overengineering leads to things like SET, multimegabyte key schedules (I hope David Scott isn't listening), and software bloat in general. I *like* the elegance of the UNIX salt scheme, and we all learned from it. Sure, we'd do it differently today. That's partly because of what it taught us. But, knowing what we know now, would we have done it differently *then*, with that set of constraints? The answer to that is not at all obvious. (IMHO the design decision that would most profitably have changed was the limitation to 8 character passwords, not the salt. But that's another story. That we are still using password based schemes at all, and patching the problems with other mechanisms like shadow password files, is also another story. If I design something like this that is still in very widespread use in 2020, I'll consider myself to have done very well, or society will be to blame, one or the other. More kudos to Bob Morris, Ken Thompson and (IIRC) Fred Grampp.) apology for the rant, Greg. [PS. Perry, it's Menezes, *van* Oorschot, *and Vanstone*. I, too, think Stinson is a more appropriate reference for a beginner. I rarely recommend the encyclopaedia as a starting point for anything. (I apologise again.)] Greg Rose INTERNET: [EMAIL PROTECTED] Qualcomm Australia VOICE: +61-2-9181-4851 FAX: +61-2-9181-5470 Suite 410, Birkenhead Point, http://people.qualcomm.com/ggr/ Drummoyne NSW 2047 232B EC8F 44C6 C853 D68F E107 E6BF CD2F 1081 A37C
Re: [IRR] Problems with Eudora plugin for PGP 6.0.2i
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 At 12:16 14/05/99 +0530, Udhay Shankar N wrote: >Jon Callas wrote: > >> You probably have the preference for "use PGP/MIME by default" turned on. >> Turn it off. MIME security encodings are a crock, as you well know. > >Nope, I don't have this turned on. It still sends out the messages as >attachments. Well, I use 6.0.2i too, and eudora, and I just sent myself a test message to check, and it doesn't make it an attachment. Please check again under the pgp preferences menu, email tab, that the box to use PGP/MIME is not checked. Perhaps the default changed when you installed it. As for signing the .sig, that is definitely considered a feature not a bug. If you clearsign the message, it shows through... if it is encrypted, it shouldn't. C'est la Guerre. regards, Greg. Greg Rose INTERNET: [EMAIL PROTECTED] Qualcomm Australia VOICE: +61-2-9181-4851 FAX: +61-2-9181-5470 Suite 410, Birkenhead Point, http://people.qualcomm.com/ggr/ Drummoyne NSW 2047 232B EC8F 44C6 C853 D68F E107 E6BF CD2F 1081 A37C -BEGIN PGP SIGNATURE- Version: PGPfreeware 6.0.2i iQA/AwUBNzw+1ua/zS8QgaN8EQLCAwCg54+JwBnxHgT/IRUY2yFW4pmsVbwAoNXb PZnQwcPy0FjyyqeRp9396zuo =6JS6 -END PGP SIGNATURE-
Re: references to password sniffer incident
Thanks for the good pointers that a number of people gave. The particular incident I remembered was the BARRnet one http://www.geek-girl.com/bugtraq/1993_4/0032.html (thanks Dan Riley). I had no idea there had been so many, so well hushed up! MILNET, JANET (4 independent incidents in the UK in Q3 1995 alone), Panix and other ISPs, several universities, the USENIX terminal room, ... Some other URLs: http://email.tqn.com/library/nus/bl110498-3.htm http://www.chips.navy.mil/chips/archives/94_jul/file14.html http://www.nic.mil/ftp/mgt/bul-9402.txt I was also reminded of a paper by Nathaniel Borenstein and others at First Virtual, about sniffing (network and keyboard) for credit card numbers using the check digit to identify them. I haven't found the actual paper, but it was a precursor to: http://www.inet-one.com/cypherpunks/dir.96.01.25-96.01.31/msg00618.html thanks Greg. Greg Rose INTERNET: [EMAIL PROTECTED] Qualcomm Australia VOICE: +61-2-9181-4851 FAX: +61-2-9181-5470 Suite 410, Birkenhead Point, http://people.qualcomm.com/ggr/ Drummoyne NSW 2047 232B EC8F 44C6 C853 D68F E107 E6BF CD2F 1081 A37C
references to password sniffer incident
This is a little off topic, I know, but I'm writing a paper about the work we've done on an encrypting sendmail (I'll announce details as soon as it restabilises, but if anyone wants to see the old version it's at http://www.home.aone.net.au/qualcomm ). For part of this, I wanted to refer to the incident where someone mounted a password sniffer at a major network hub (MAE-West?) a couple of years ago. But I haven't turned up anything useful in a Web search. I didn't dream this incident, did I? Does anyone have any references? thanks, Greg. Greg Rose INTERNET: [EMAIL PROTECTED] QUALCOMM AustraliaVOICE: +61-2-9181 4851 FAX: +61-2-9181 5470 Suite 410, Birkenhead Point http://people.qualcomm.com/ggr/ Drummoyne NSW 2047 B5 DF 66 95 89 68 1F C8 EF 29 FA 27 F2 2A 94 8F
Re: Triple DES "standard"?
I've taken the liberty of Cc:ing the list on a reply to individual email, so I've anonymised the sender. At 17:00 1/01/99 -0800, someone wrote: >Greg Rose wrote: >> It was Phil Karn, I've seen the form. He was trying to export a VPN box >> of some kind to the QUALCOMM office in Singapore. They did allow IDEA, >> eventually. Phil thinks that allowing a 128-bit algorithm but not 112-bit >> 3des was some sort of mind game. >> > >I thought IDEA has a large number of weak/semi-weak keys? > >Without knowing better I'd think the usable key space is smaller than >3DES? (I haven't worked out the math) I've forgotten the actual number, but the vaguely weak keys are something of the order of 2^-72 of the actual keyspace. When you think about it this way, the chance of accidentally getting a weak key is *much* less than the chance of guessing a DES key first try. Expressed in terms of the supposed strength of an IDEA key, the IDEA keyspace is about 2^127.8 or something; still much larger than the 2^112 of two-key 3des. Yes, the number of weak IDEA keys is numerically large. Proportionally, it is tiny. (The word "known" should be assumed to appear in appropriate places above.) regards, Greg. Greg Rose INTERNET: [EMAIL PROTECTED] Qualcomm Australia VOICE: +61-2-9181-4851 FAX: +61-2-9181-5470 Suite 410, Birkenhead Point, http://people.qualcomm.com/ggr/ Drummoyne NSW 2047 232B EC8F 44C6 C853 D68F E107 E6BF CD2F 1081 A37C
Re: Triple DES "standard"?
[EMAIL PROTECTED] writes: >Someone (memory says Phil Karn, but I'm probably wrong) applied for some >kind of >export license and was denied. Interestingly, the form had an >obviously-newly-added >reason appended to the "checklist of reasons for denial." The addition was >"uses >triple-DES." It was Phil Karn, I've seen the form. He was trying to export a VPN box of some kind to the QUALCOMM office in Singapore. They did allow IDEA, eventually. Phil thinks that allowing a 128-bit algorithm but not 112-bit 3des was some sort of mind game. >Trolling through the cypherpunks archives around 12-18 months ago should >find the >story. I think it was longer ago than that; they already knew what to ask for for the (now 2 1/2 year old) Australian office. regards, Greg. Greg Rose INTERNET: [EMAIL PROTECTED] QUALCOMM AustraliaVOICE: +61-2-9181 4851 FAX: +61-2-9181 5470 Suite 410, Birkenhead Point http://people.qualcomm.com/ggr/ Drummoyne NSW 2047 B5 DF 66 95 89 68 1F C8 EF 29 FA 27 F2 2A 94 8F
