daveb@geac.UUCP (David Collier-Brown) (02/29/88)
An associate, Mr. Max Southall of Micro/Access, was recently asked
to comment on the possible need for a Canadian cryptographic
standard, rather than the proposed ISO DEA-1.
As neither he nor I have a strong opinion, we are passing the
question on the the portion of the user/researcher community active on
the net:
For the guidance of the Data Cryptographics Technical Committee of
the Standards Council of Canada, do you feel that Canada needs a
unique data encryption standard, and if so, what relation should it
have to the ISO DEA-1 standard?
Responses by email or net, please: we will post more information
and the address for written responses presently... (Max is
discussing it by phone right now).
--dave
--
David Collier-Brown. {mnetor yunexus utgpu}!geac!daveb
Geac Computers International Inc., | Computer Science loses its
350 Steelcase Road,Markham, Ontario, | memory (if not its mind)
CANADA, L3R 1B3 (416) 475-0525 x3279 | every 6 months.daveb@geac.UUCP (David Collier-Brown) (03/18/88)
[This is a followup to a discussion of Canadian versus US
cryptographic devices and standards, which is probably of direct
interest to the crytographic community worldwide --dave c-b]
Unfortunately, the new LSI-based COMSEC standard appears to have
the trap door mandated by Congress for international traffic built
in to it. While it's admirable for the U.S. to propose a standard
for its allies which will (hopefully) uniformly deny the enemy
access to our secrets, it's not in the interest of those same allies
to have their nearest and dearest independent secrets subject to
perusal by NSA.
The actual algorithms for the type I modules are being treated
like the crown jewels and are NOT open for scrutiny by engineers
designing product around them. Moreover, design-in sessions
necessary to those using these black boxes in a product are being
held ONLY in the U.S. with access denied to non-U.S. citizens. The
result is that the only "Canadian" companies able to actually
participate are the American headquarters of Canadian branch plants.
We're well aware of the catch-22 syndromes involved because of our
partial development of data encryption for commercial cellular
telephone nets.
We strongly believe that for sensitive Canadian secrets, a
proprietary Canadian algorithm should be embedded into LSI, and the
details shared with no one outside Canada. Failure to do this makes
a mockery of our already limited sovereignty. If we wish as
Canadians to have our world views taken seriously by our allies, we
must make the necessary expenditures not to be dependent.
--
Max Southall, {mnetor yunexus utgpu}!geac!lethe!max
Micro/Access, voice: 488-1799, 463-9535
1425 Bayview Ave.,
Toronto, Ontario.
CANADA, M4G 3A9gamiddleton@watmath.waterloo.edu (Guy Middleton) (03/20/88)
In article <2463@geac.UUCP> daveb@geac.uucp (David Collier-Brown) writes: > We strongly believe that for sensitive Canadian secrets, a > proprietary Canadian algorithm should be embedded into LSI, and the > details shared with no one outside Canada. Failure to do this makes > a mockery of our already limited sovereignty. If we wish as > Canadians to have our world views taken seriously by our allies, we > must make the necessary expenditures not to be dependent. Having an algorithm without trapdoors for nasty foreign intelligence agencies is a good idea, but keeping the details of the aglorithm secret is a bad way to make it secure. At some time, *somebody* will find out, and all the secrecy will be pointless. It is better to assume that the enemy knows everything about the encryption method except for the key. Also, keeping the details secret would provoke the same kind of worry about trapdoors as the NSA does. -Guy Middleton, University of Waterloo Institute for Computer Research gamiddleton@math.waterloo.edu, watmath!gamiddleton "nobody uses it, anyway"
gwyn@brl-smoke.ARPA (Doug Gwyn ) (03/20/88)
In article <2463@geac.UUCP> daveb@geac.uucp (David Collier-Brown) writes: > We strongly believe that for sensitive Canadian secrets, a >proprietary Canadian algorithm should be embedded into LSI, and the >details shared with no one outside Canada. Well, of course -- why would anyone think otherwise? You better also have an experience team of cryptanalysts evaluate any proposed system for its security. It's amazing how easy it is to walk right through some apparently complex cryptosystems.
mdr@reed.UUCP (Mike Rutenberg) (03/20/88)
In article <2463@geac.UUCP> daveb@geac.uucp (David Collier-Brown) writes: > We strongly believe that for sensitive Canadian secrets, a >proprietary Canadian algorithm should be embedded into LSI, and the >details shared with no one outside Canada. Failure to do this makes >a mockery of our already limited sovereignty. If we wish as >Canadians to have our world views taken seriously by our allies, we >must make the necessary expenditures not to be dependent. Your suggestion sounds like "lets emulate U.S. practice" rather than general support for strong cryptographic research and commercial development within Canada. If you are suggesting that a Canadian standard be developed solely for the Government and military contractors, that might be appropriate (I must admit some ignorance of where the encryption schemes used by the Canadian government originate - does the Communications Security Establishment (CSE) make them or do they come from the NSA?). A more difficult problem would seem to be a public encryption standard. It is probably just my existence outside of the military that makes me desire open cryptographic research and systems. Black boxes concern me, no matter who they come from (I also don't like centralized key scheduling). I also think there is a need for generally available encryption, not just for national security applications. Banks, businesses, and even humble love letters all need to be protected. Maybe DES or the NSA chips are enough for these applications, but I certainly wouldn't mind having the option of an open, independent, "made-in-Canada" solution. The subject of resources also comes to mind (maybe some messages on this topic haven't made it out of Canada). How does one make strong cryptographic standards appear? Where would they come from? Thoughts which come to mind are National Research Council (NRC) and the CSE, but I don't know what resources they would have to tackle this seemingly difficult project. The open work that I know of is coming from places like Queen's University and the University of Waterloo. Do there already exist proposals for a Canadian standard or is this a thought which will later be turned into resources? Anyways, neat stuff. I'll buy one if it is cheap enough! Mike -- Mike Rutenberg specializing in fast, robust software and food (503)771-5516
karn@thumper.bellcore.com (Phil R. Karn) (03/21/88)
> We strongly believe that for sensitive Canadian secrets, a >proprietary Canadian algorithm should be embedded into LSI, and the >details shared with no one outside Canada. Why repeat the same heavy-handed tactics that you so justly criticize the NSA for engaging in? As a layperson interested in cryptography (but not competent to pass judgement on the relative merits of any particular encryption system) I am forced to trust the judgement of others. In order for me to do this, I have to be able to trust the system under which these other people operate. To me this means 1) avoiding even the appearance of a conflict of interest and 2) applying the tmme-honored scientific principles of openness and peer review to the process. I am far more willing to trust the collective judgement of independent specialists in academic and commercial organizations openly working in parallel on a publicly-specified algorithm whose design principles are also public than I would trust a government organization, with its inherent conflict of interest, working in secret, that says "trust us, it's secure, but we can't tell you anything more about it". It doesn't matter how much more capable the government cryptologists may be, or how much additional security might theoretically accrue from keeping the algorithm design process secret. The two principles above have to be paramount. I also trust mathematics a lot more than I trust people. Phil
daveb@geac.UUCP (David Collier-Brown) (03/21/88)
|In article <2463@geac.UUCP> max@syntron (Max Southall) writes: || proprietary Canadian algorithm should be embedded into LSI, and the || details shared with no one outside Canada. In article <17654@watmath.waterloo.edu> gamiddleton@watmath.waterloo.edu (Guy Middleton) writes: | Having an algorithm without trapdoors for nasty foreign intelligence | agencies is a good idea, but keeping the details of the algorithm secret is | a bad way to make it secure. At some time, *somebody* will find out, and | all the secrecy will be pointless. It is better to assume that the enemy | knows everything about the encryption method except for the key. Perhaps we should have made the LSI-embedding proprietary, or some other mechanism for going from algorithm to the actual processing proprietary. The concern here is the easy availability of chipsets for doing parallell brute-force attacks on the encoded data. Not the algorithm proper's security. --dave (sorry, guy!) c-b -- David Collier-Brown. {mnetor yunexus utgpu}!geac!daveb Geac Computers International Inc., | Computer Science loses its 350 Steelcase Road,Markham, Ontario, | memory (if not its mind) CANADA, L3R 1B3 (416) 475-0525 x3279 | every 6 months.
rae@unicus.UUCP (Reid) (03/23/88)
daveb@geac.UUCP (David Collier-Brown) writes: | The concern here is the easy availability of chipsets for doing |parallel brute-force attacks on the encoded data. Not the |algorithm proper's security. Given that we are not going to keep the algorithm secret, could we just tweak an existing standard [DES?] such that it renders existing hardware solutions for that standard incompatible with our spiffy Canadian version? And if we do this, is the demand for Canadian secrets [how much money does Wayne Gretzky make?] so low that no-one will bother to design and implement hardware to crack such a 'tweaked' version? --- Reid Ellis <rae@unicus.com> "Howdy, howdy!" 176 Brookbanks Drive, Don Mills, Ontario M3A 2T5, Canada (416) 446-1644
mdr@reed.UUCP (Mike Rutenberg) (03/23/88)
In article <2475@geac.UUCP> daveb@geac.UUCP (David Collier-Brown) writes: > Perhaps we should have made the LSI-embedding proprietary > The concern here is the easy availability of chipsets for doing >parallell brute-force attacks on the encoded data. Not the >algorithm proper's security. It would seem that to make the algorithm public necessarily leaves you open to somebody building a brute force machine. Even if you control the supply of the chips ("I think we should reject Mr.Rutenberg's order for 10,000 chips") the people who have the capability to build such a machine could also (easily) make their own chips to do it. Mike p.s. Speaking of which, does anyone know of any DES chips designed outside of the US, or even outside of COCOM control. Just curious. -- Mike Rutenberg for fast, robust food and software (503)771-5516
karn@thumper.bellcore.com (Phil R. Karn) (03/24/88)
> > The concern here is the easy availability of chipsets for doing > >parallell brute-force attacks on the encoded data. Not the > >algorithm proper's security. Brute force attacks get a lot of attention only because existing algorithms like DES are marginally susceptible to them. However, if you design a proper algorithm with a large enough key size (say 128 bits, like the original Lucifer) then brute force attacks are clearly out of the question no matter how fast the technology gets in our lifetime (or many lifetimes, for that matter). Again I'd much rather place my trust in mathematics than bet against advancing technology. Phil
daveb@geac.UUCP (David Collier-Brown) (03/24/88)
In article <2414@unicus.UUCP> rae@Unicus.COM (Reid Ellis) writes: | Given that we are not going to keep the algorithm secret, could we just | tweak an existing standard [DES?] such that it renders existing hardware | solutions for that standard incompatible with our spiffy Canadian | version? And if we do this, is the demand for Canadian secrets [how | much money does Wayne Gretzky make?] so low that no-one will bother to | design and implement hardware to crack such a 'tweaked' version? An existing standard, probably. DES? probably not, as it's behavior is not fully known. There is some reason to believe it is not as secure as intended, and speculation about a trap-door continues. There is also a canadian-made encryption chip in test, with decent throughput: further information expected next week. --dave -- David Collier-Brown. {mnetor yunexus utgpu}!geac!daveb Geac Computers International Inc., | Computer Science loses its 350 Steelcase Road,Markham, Ontario, | memory (if not its mind) CANADA, L3R 1B3 (416) 475-0525 x3279 | every 6 months.
karn@thumper.bellcore.com (Phil R. Karn) (03/25/88)
> Given that we are not going to keep the algorithm secret, could we just > tweak an existing standard [DES?] such that it renders existing hardware > solutions for that standard incompatible with our spiffy Canadian > version? A good start. But I think I have a better idea. Surely there must be plenty of independent expertise out there that hasn't sold their souls either to the NSA or IBM (or non-US counterparts thereof). Why can't they get together and develop an informal "counterstandard" secret-key encryption algorithm as an alternative to DES? It would have the following properties: 1. Complete public disclosure of all algorithmic details and design principles. 2. A widespread consensus as to the mathematical strength of the algorithm, given point #1 above. 3. A design tailored for efficient software implementation (no "initial permutations" or similar gratuitous garbage meant to sabotage software in favor of custom hardware). Unfortunately, this seems to rule out public-key systems; that's why I said "secret-key" above. 4. A key size sufficient to rule out all brute force attacks, even those by custom hardware. If such an algorithm can be devised, I for one would be willing to implement it in portable C, tune it up, and put the code into the public domain. Comments? Phil
leonard@bucket.UUCP (Leonard Erickson) (03/25/88)
Assuming only a moderately paranoid point of view, the following thought came up: NSA is trying to push use of a "black box" encryption standard which they almost certainly will have a "back door" to. Now it is suggested that Canada come up with its *own* black box. (probably with a back door :-) So if I get both and run my data thru the in sequence, would that mean that neither NSA nor it's Canadian equivalent code crack it without either luck (finding the other guy's backdoor) or sharing their black boxes (which defeats the purpose of having seperate black boxes)? I think I like this... -- Leonard Erickson ...!tektronix!reed!percival!bucket!leonard CIS: [70465,203] "I used to be a hacker. Now I'm a 'microcomputer specialist'. You know... I'd rather be a hacker."
gwyn@brl-smoke.ARPA (Doug Gwyn ) (03/26/88)
In article <1009@thumper.bellcore.com> karn@thumper.bellcore.com (Phil R. Karn) writes: >Surely there must be plenty of independent expertise out there that >hasn't sold their souls either to the NSA or IBM (or non-US counterparts >thereof). Why can't they get together and develop an informal >"counterstandard" secret-key encryption algorithm as an alternative to >DES? The main reason is that very few of the "public" cryptologists are qualified cryptanalysts; training of the latter is almost exclusively done by government agencies who intimidate their employees into Never Saying Anything. Knowledge that the secret agencies have is not generally available to help the public evaluate cryptosystems. >1. Complete public disclosure of all algorithmic details and design >principles. One of the problems is that the secret agencies tend to jealously guard design principles. For example, the Lucifer S-boxes were strengthened using guidelines that I believe have never been publicly disclosed. >2. A widespread consensus as to the mathematical strength of the algorithm, >given point #1 above. Consensus means little. What you want is for several independent attacks by competent cryptanalytic teams to fail to find exploitable weaknesses. Few systems would pass such a test. Note that there have been several recent public cryptosystems for which the (public) consensus initially was that they were secure, and only later was it shown that the consensus had been wrong. >4. A key size sufficient to rule out all brute force attacks, even those >by custom hardware. Brute-force attacks are stupid. Of course they must be made impractical, but so must more clever techniques. Guaranteed security at a certain confidence level requires a key length comparable in size to the amount of text being encrypted (just how much less depends on details of the system). This brings up the practical issue of key distribution. Most common systems implement a compromise that relies more on system complexity than on information-theoretic security. But you still need frequent key changes.
gwyn@brl-smoke.ARPA (Doug Gwyn ) (03/27/88)
In article <821@bucket.UUCP> leonard@bucket.UUCP (Leonard Erickson) writes: >So if I get both and run my data thru the in sequence, would that mean that >neither NSA nor it's Canadian equivalent code crack it without either luck >(finding the other guy's backdoor) or sharing their black boxes (which >defeats the purpose of having seperate black boxes)? I don't know whether there is a "back door" to the DES, but from its structure I rather think not. In any event, the combination of two complex cryptosystems is not necessarily theoretically much more secure than using just one, but any specialized automated procedure for cracking one of the "standard" systems that some secret agency may have set up would not work when applied to the combination. Whether this would deter them depends on how important they consider reading your traffic to be. If it's just a "personal" application, I doubt they'd bother to try cracking your traffic, since there would be insufficient return for the resources invested. Ultimately, you're protected by economics!
dee@cca.CCA.COM (Donald Eastlake) (03/29/88)
In article <821@bucket.UUCP> leonard@bucket.UUCP (Leonard Erickson) writes: >NSA is trying to push use of a "black box" encryption standard which they >almost certainly will have a "back door" to. >Now it is suggested that Canada come up with its *own* black box. (probably >with a back door :-) There are a number of well known cases where persons working at NSA were in the pay of or defected to foreign powers. The people at NSA are probably of at least average intelligence. Therefore they must assume that a few of the people currently working there are in the pay of others or will defect in the future. Putting a trap door into an ecryption algorithm that will be used to protect the highest level secrets strikes me as pretty stupid. You have to assume that other countries are recording your transmissions and keep copies for umpteen years so if the trap door ever leaked they could read all of your messages not to mention the cost and effort that would be involved in replacing all the hardware to protect current and future message. -- +1 617-492-8860 Donald E. Eastlake, III ARPA: dee@CCA.CCA.COM usenet: {cbosg,decvax,linus}!cca!dee P. O. Box N, MIT Branch P. O., Cambridge, MA 02139-0903 USA
daveb@geac.UUCP (David Collier-Brown) (03/29/88)
In article <1009@thumper.bellcore.com> karn@thumper.bellcore.com (Phil R. Karn) writes: >Surely there must be plenty of independent expertise out there that >hasn't sold their souls either to the NSA or IBM (or non-US counterparts >thereof). Why can't they get together and develop an informal >"counterstandard" secret-key encryption algorithm as an alternative to >DES? Well, we may have a chip-level product already: I just spoke to Gord Agnew of the University of Waterloo, who was kend enough to pass on an advance spec sheet for the CalMos CA34C168 Public Key Encryption Processor, designed in concert with Cryptech Systems and UW. In brief: CMOS VLSI Cryptographic device, 40-pin dip Public key or conventional cryptosystems Block size 600 bits or greater 2 stream and 2 block cypher modes Generates digital signatures, message authentication codes This was written up in the Science column of the Toronto Star last January (17 Jan 87) when the companies first got together. The principal designers were from Waterloo: Gordon Agnew, Faculty of Engineering, Ron Mullin and Scott Vanstone, Faculty of Math, and Ivan Onyzschuk with help from the University commercial deveopment officer, Robert Nally. The implementers are CalMos Systems Inc., Canata, Ontario. Regrettably, I don't have their address (although the above is probably sifficent: Canata is a smallish suburb of Ottawa (:-)) -- David Collier-Brown. {mnetor yunexus utgpu}!geac!daveb Geac Computers International Inc., | Computer Science loses its 350 Steelcase Road,Markham, Ontario, | memory (if not its mind) CANADA, L3R 1B3 (416) 475-0525 x3279 | every 6 months.
greg@xios.XIOS.UUCP (Greg Franks) (04/05/88)
In article <2508@geac.UUCP> daveb@geac.UUCP (David Collier-Brown) writes: > Well, we may have a chip-level product already: I just spoke to >Gord Agnew of the University of Waterloo, who was kend enough to >pass on an advance spec sheet for the CalMos CA34C168 Public Key >Encryption Processor, designed in concert with Cryptech Systems and >UW. [...] > The implementers are CalMos Systems Inc., Canata, Ontario. >Regrettably, I don't have their address (although the above is >probably sifficent: Canata is a smallish suburb of Ottawa (:-)) >-- > David Collier-Brown. {mnetor yunexus utgpu}!geac!daveb Calmos systems: 20 Edgewater Dr. Kanata, Ontario, Canada. (613) 836-1014 It is left as an exercise for Canadian readers to look up the postal code. American readers can ignore the postal code - Canada Post usually does... Disclaimer. I looked this address up in the telephone book. I also don't know where *Canata* is :-). Perhaps in Mexico? -- Greg Franks XIOS Systems Corporation, 1600 Carling Avenue, utzoo!dciem!nrcaer!xios!greg Ottawa, Ontario, Canada, K1Z 8R8. (613) 725-5411. "Those who stand in the middle of the road get hit by trucks coming from both directions." Evelyn C. Leeper.