Cryptography-Digest Digest #72, Volume #10 Wed, 18 Aug 99 21:13:03 EDT
Contents:
Any thoughts on TECSEC's CKM? (James Muir)
Re: Wrapped PCBC mode (Tom St Denis)
Re: Decrypted International Crypto inside the US (JPeschel)
Re: Decrypted International Crypto inside the US (JPeschel)
Re: algorithm (Tom St Denis)
Re: Decrypted International Crypto inside the US ("Dan Kaminsky")
Re: Is RC5 still safe (enough)? (Tom St Denis)
Re: algorithm ("First of One")
Re: Is RC5 still safe (enough)? (Tom St Denis)
Re: VEA - Video Encryption Algorithm ("First of One")
Re: Encryption and Authentication (D. J. Bernstein)
Re: CRYPTO DESIGN MY VIEW (SCOTT19U.ZIP_GUY)
I need strongest weak elliptic curve... (Greg)
Re: Decrypted International Crypto inside the US (SCOTT19U.ZIP_GUY)
Re: CRYPTO DESIGN MY VIEW (John Savard)
Re: Decrypted International Crypto inside the US (JPeschel)
Re: Using floating-point arithmetic in cryptography ("Michael T. Babcock")
----------------------------------------------------------------------------
From: James Muir <[EMAIL PROTECTED]>
Subject: Any thoughts on TECSEC's CKM?
Date: Wed, 18 Aug 1999 21:12:21 GMT
TECSEC has received press lately about their role-based encryption
software called CKM ( Constructive Key Management ) -- follow the links
on their webpage to read some interesting articles, http://www.sts-
ckm.com/news.htm .
The most notable thing about this product is that it has been "approved
for export with a key length of 392 bits". After reading the white
paper, http://www.sts-ckm.com/CKMWhitePaper049926.htm , that statement
may not have much to do with the actual security of CKM.
A "domain authority" in a given CKM system decides what crypto will be
used for encrypting objects. The CKM demo comes loaded with Triple-DES
and P-Squared ( a proprietary algorithm ). I don't know where
the number 392 was pulled from but it seems to me the key length is
determined by what crypto you use. Triple-DES has 3*56 bits of key.
Has anyone else looked at CKM?
-James
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Wrapped PCBC mode
Date: Wed, 18 Aug 1999 22:18:58 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> I meresly said it slowed them. I am not saying that such slowing down
was
> necessary in that case, merely that all-or nothing encryption is a
valid
> security enhancing technique, and does provide some security benefit.
> Whether in this case it is worth the performance hit, needed, or is
just a
> case of throwing everything but the kitchen sink into a cypher and
producing
> something secure, but lumbering, clumbersome, and ugly is annother
thing
> entirely.
>
> As Bruce S. has said before at 100 to 150 rounds of most student
cyphers
> become very resistant to attack. The art of the thing is getting that
attack
> resistance with as little effort, space, etc. as possible
So we both agree then that multiple wraps modes are in fact totally
useless unless the keysize is fixed, AND SMALL, and the cipher IS NOT A
GROUP....
Basically I was trying to discount (discredit) his method
as 'practical' or really that much better then say CBC and CBCC....
Even simple ciphers at 32 rounds can be secure if done right....
However i rather use 12 rounds of RC5 or Blowfish then 12 rounds of my
30mins of work cipher ...
rounds = strength only in the face of known plaintext. If you have say
20 known plaintext blocks out of 100000, then well it's not alot. If
20 plaintext blocks allows you to find the key....
If you have 10000 blocks and know or can guess zero of them, even week
ciphers are secure after 1 round.
Tom
--
PGP 6.5.1 Key
http://mypage.goplay.com/tomstdenis/key.pgp
PGP 2.6.2 Key
http://mypage.goplay.com/tomstdenis/key_rsa.pgp
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED] (JPeschel)
Subject: Re: Decrypted International Crypto inside the US
Date: 18 Aug 1999 22:37:58 GMT
Dan Kaminsky<[EMAIL PROTECTED]> writes:
>Do you have any evidence anywhere that directly contraverts this legal
>interpretation?
>
What legal interpretation?
>> I have heard in personal discussions with the powers in control words
>> to the effect that if strong crypto is used off shore, it is presumed
>> that someone, possibly the recipient, had previously violated the
>> export regulations. How else would they obtain it? I believe that the
>> same would be true for sending a strongly encrypted message to a
>> foreign party. There seemed to be little or no recognition that a
>> foreign party could develop a compatible implementation without U.S.
>> involvement (their words).
>>
>> "without U.S. envolvement" = "clean room implementation"
>
>If a european partner of an American multinational company sends *us* a
>propietary decryption application, is it illegal for us to use it?
No, but you likely cannot export the application.
Joe
__________________________________________
Joe Peschel
D.O.E. SysWorks
http://members.aol.com/jpeschel/index.htm
__________________________________________
------------------------------
From: [EMAIL PROTECTED] (JPeschel)
Subject: Re: Decrypted International Crypto inside the US
Date: 18 Aug 1999 22:35:31 GMT
Doug Stell writes:
>Having spent many years worrying about export issues, I have never
>heard this. Of course, it could be relatively new and I am out of
>touch.
>
There is no US law that makes it illegal to receive and decrypt
encrypted messages. Period.
>I have heard in personal discussions with the powers in control words
>to the effect that if strong crypto is used off shore, it is presumed
>that someone, possibly the recipient, had previously violated the
>export regulations. How else would they obtain it? I believe that the
>same would be true for sending a strongly encrypted message to a
>foreign party. There seemed to be little or no recognition that a
>foreign party could develop a compatible implementation without U.S.
>involvement (their words).
Personal discussions only amount to speculation, and speculation
has little to do with EAR.
Joe
__________________________________________
Joe Peschel
D.O.E. SysWorks
http://members.aol.com/jpeschel/index.htm
__________________________________________
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: algorithm
Date: Wed, 18 Aug 1999 22:27:02 GMT
In article <[EMAIL PROTECTED]>,
"Ancort" <[EMAIL PROTECTED]> wrote:
> We think our russian algorithm is beter
> Look our site www.ancort.ru
How then say RC5 or Blowfish or Cast or IDEA.... you post here you
document here...
1. is it faster
2. is it more secure against iterative attacks
3. is it smaller
4. is it ?
What...
I am not going to read your site. If you have valid information please
abstract here.
Tom
--
PGP 6.5.1 Key
http://mypage.goplay.com/tomstdenis/key.pgp
PGP 2.6.2 Key
http://mypage.goplay.com/tomstdenis/key_rsa.pgp
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: "Dan Kaminsky" <[EMAIL PROTECTED]>
Subject: Re: Decrypted International Crypto inside the US
Date: Wed, 18 Aug 1999 15:55:06 -0700
JPeschel <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Doug Stell writes:
>
> >Having spent many years worrying about export issues, I have never
> >heard this. Of course, it could be relatively new and I am out of
> >touch.
> >
>
> There is no US law that makes it illegal to receive and decrypt
> encrypted messages. Period.
Do you know of any court cases, or citations I can use to prove this fact?
Some interesting stuff at work rides on this being proved(or disproved).
Yours Truly,
Dan Kaminsky
DoxPara Research
http://doxpara.netpedia.net
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Is RC5 still safe (enough)?
Date: Wed, 18 Aug 1999 22:23:44 GMT
In article <7pf6gd$i3v$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> Hi,
> I'm rather new to the crypto stuff and I know I probably shouldn't be
> posting here as a newbie. But I just couldn't find definitive answers
> to this question anywhere. So I figured I'd ask the specialists.
> I need to encrypt a couple of files as part of a software project. I
> ran into RC5 and after some research on the net found that it seems to
> be fairly safe.
> I know you're going to ask: "how much is the data worth?" and "for how
> long does it have to remain safe?". Let's just assume it's worth
enough
> to justify the search for a *good* algorithm and it should remain safe
> for at least 10-15 years.
> If we don't take brute force into account, will an RC5-32/16/16 cipher
> be broken in the near future? What about Schneier's mod3-attack? Does
> it apply to "normal" RC5? Or did Yin in her recent FSE-paper on linear
> attacks on RC5 bring any new results (I couldn't get a hold of that
> paper)?
> I'd appreciate help on this one. Also, you may want to recommend
> another algorithm if RC5 is not safe anymore. Can RC6 be trusted
> already? That about Blowfish?
Well you asked quite a bit.
The fastest attack on RC5 I have found is 2^53 plaintexts (is that
right). In this case RC5 would be considered safe at 12 rounds if less
then that is encrypted.
With a 128-bit key you can expect that key to be hidden for a VERY long
time. However if you can compromise any other part of the design you
can get the key easily.
RC6 is still considered secure cause the easiest attack is 2^118 with
16 rounds... not with 20...
Blowfish is secur after 4 rounds ... except with weak keys. 16 rounds
is safe...
Does that help?
Tom
--
PGP 6.5.1 Key
http://mypage.goplay.com/tomstdenis/key.pgp
PGP 2.6.2 Key
http://mypage.goplay.com/tomstdenis/key_rsa.pgp
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: "First of One" <[EMAIL PROTECTED]>
Subject: Re: algorithm
Date: Wed, 18 Aug 1999 23:38:08 GMT
Not going to your site, but is it GOST?
--=20
--
First of One, primary adjunctive grid Alpha-01, but you may call me =
First of One.
Ancort <[EMAIL PROTECTED]> wrote in message =
news:[EMAIL PROTECTED]...
> We think our russian algorithm is beter
> Look our site www.ancort.ru
>=20
>=20
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Is RC5 still safe (enough)?
Date: Wed, 18 Aug 1999 22:36:33 GMT
<snip>
BTW the mod3 attack only works against RC5P cause rotation and xor do
not work well together (non isomorphic). They also have bad
approximations.
ALWAYS use RC5 with ((A xor B) <<< B) + r[2i], etc...
I can send you the files
rc5rev.ps The original RC5 paper
rc6.ps The rc6 papper
cryptanalysis of rc5.ps The Diff attack
correlations in rc6.ps The attack on RC6
is you want, just email me.
Tom
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: "First of One" <[EMAIL PROTECTED]>
Subject: Re: VEA - Video Encryption Algorithm
Date: Wed, 18 Aug 1999 23:22:49 GMT
The number of cable users accounts for a neglible percentage of the =
entire population, and not all cable users pirate videos. So just how =
many people will be really affected by the VEA?
--=20
--
First of One, primary adjunctive grid Alpha-01, but you may call me =
First of One.
<[EMAIL PROTECTED]> wrote in message =
news:7pe81n$pe1$[EMAIL PROTECTED]...
> P.S. As for all the cable pirates out there, you have to remember =
this.
> This algorithm probably uses the same principle as the lock on your
> door: it was designed to keep honest people out. If you really want =
it,
> you will get in with this.
------------------------------
From: [EMAIL PROTECTED] (D. J. Bernstein)
Subject: Re: Encryption and Authentication
Date: 18 Aug 1999 21:40:10 GMT
Gabriel Belingueres <[EMAIL PROTECTED]> wrote:
> In the later, I can authenticate first, and if the MAC not the same, I
> can save a decryption.
Right. A flood of fake packets will waste lots of CPU time if you have
to decrypt before checking the authenticator.
On the other hand, this really doesn't matter for SSL, since there are
much easier ways to destroy SSL service.
---Dan
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: CRYPTO DESIGN MY VIEW
Date: Thu, 19 Aug 1999 01:06:00 GMT
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Jerry
Coffin) wrote:
>In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] says...
>> Okay, while our local network was down today I did a bit of research
>> in the tech library, and found that "arithmetic coding" seems to be
>> the compression method of choice. The basic idea seems to be to
>> dynamically repartition the code space so as to always minimize the
>> expected size of the *next* symbol; if you have a good model of the
>> population statistics, this method is supposed to achieve nearly
>> optimal compression (better than Huffman coding). There is supposed
>> to be a good tutorial in the Mar. 1984 IBM J. of Rsch. & Devel., and
>> it's described in some textbooks. The library closed before I could
>> find out more, but that should be enough to get you started.
>> http://www.cs.toronto.edu/~radford/ac.software.html contains pointers
>> to software for this and an associated article by Moffat et al.
>
>For a commercial product, arithmetic encoding has a basic problem.
>The general idea of arithmetic encoding was kicked around for a long
>time, but nobody could figure out a practical method of actually doing
>it. IBM finally figured out a way to make it work, and work quite
>well at that. They, however, patented it. Since then, they've gotten
>a number (rather a large number, AAMOF) of patents on related
>technology, such as hardware implementations, parallel
>implementations, etc. In addition, a number of other companies have
>patents on other related technology.
>
>It comes down to the fact, that by the time you implement arithmetic
>encoding in a product, chances are that you'll owe royalties to a
>number of different companies, many of whom are not ones you'd prefer
>to get into fights with. OTOH, since nobody in their right mind would
>use Dave Scott's garbage anyway, he might as well use the patents
>themselves as tutorials on how to do things (patent number 4,122,440
>for a start). Given Mr. Scott's apparent coding ability, using the
>patent as a tutorial on how to do things will ensure against actually
>infringing the patent at all. It will also reduce the chances of his
>code working, but since he doesn't seem to know how (or even that) to
>works right now, that shouldn't be a problem...
I take it I am getting on your nerves. At least my compression program works
and it may be better to have a working program to look at than same vague
worthless description in a patent. People at one time could patent antigravity
and perpetual motion machines. But try to follow a patent and get it to work.
Many people like the last writter are to dam lazy or stupid to follow code
that compiles and works. Just because you don't handfeed them and burp
them they get upset when they can't follow the code.
Which brings up another point when I post my code for dscussion how could
lawyer types like you prove I violated any patent if my coding is such that
no one can even decipher what I did even when it is in plain site.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
http://members.xoom.com/ecil/index.htm
NOTE EMAIL address is for SPAMERS
------------------------------
From: Greg <[EMAIL PROTECTED]>
Subject: I need strongest weak elliptic curve...
Date: Wed, 18 Aug 1999 23:10:12 GMT
Does anyone know what is the largest Koblitz elliptic curve (using
polynomial basis) that can be freely exported without an export
license? If so, can you post the curve parameters? I need to make a
free downloadable demo of my software, and I would like the stronget
possible curve that is still weak enough that it would not require an
export license.
--
The US is not a democracy - US Constitution Article IV Section 4.
Democracy is the male majority legalizing rape.
UN Security Council is a Democracy. NO APPEALS! Welcome to the NWO.
Criminals=Crime. Armies=Tyranny. The 2nd amendment is about tyranny.
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Decrypted International Crypto inside the US
Date: Thu, 19 Aug 1999 01:12:31 GMT
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
(JPeschel) wrote:
>Doug Stell writes:
>
>>Having spent many years worrying about export issues, I have never
>>heard this. Of course, it could be relatively new and I am out of
>>touch.
>>
>
>There is no US law that makes it illegal to receive and decrypt
>encrypted messages. Period.
>
Joe there are laws about sending encrypted messages out over the
ham radio airways. Because I remember the Ham teacher saying it
was illegal since the government wants to know about all messages
sent over the airwaves. I asked about morse code and he said that
was not considered encryption. So you might be able to recieve
such message but the US does have limits on how you send
encrypted messages in some cases like the Ham example.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
http://members.xoom.com/ecil/index.htm
NOTE EMAIL address is for SPAMERS
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: CRYPTO DESIGN MY VIEW
Date: Thu, 19 Aug 1999 00:38:30 GMT
Mok-Kong Shen <[EMAIL PROTECTED]> wrote, in part:
>I have only scanty knowledge about arithmetic coding. But I vaguely
>remember that arithmetic coding, because it operates on real
>numbers, could have some implementation difficulties if the real
>numbers supported by hardware are not long enough. I hope experts
>would comment whether this is true or false.
I know from reading about the topic that the algorithms used limit the
necessary precision required, and so this is not a problem.
It is partly because of the need for such algorithms that arithmetic
coding is quite complicated and difficult. Also, there are patent
issues with it.
John Savard ( teneerf<- )
http://www.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED] (JPeschel)
Subject: Re: Decrypted International Crypto inside the US
Date: 19 Aug 1999 00:40:44 GMT
>"Dan Kaminsky" <[EMAIL PROTECTED]> writes:
>Do you know of any court cases, or citations I can use to prove this fact?
>Some interesting stuff at work rides on this being proved(or disproved).
It's difficult to cite a court case to challenge or uphold a law that never
existed.
The export of certain crypto applications is, however, restricted by EAR.
You can find EAR on the web:
http://www.bxa.doc.gov/Encryption/Default.htm
What rule did your friend think he was interpreting?
Joe
__________________________________________
Joe Peschel
D.O.E. SysWorks
http://members.aol.com/jpeschel/index.htm
__________________________________________
------------------------------
Date: Wed, 18 Aug 1999 20:46:49 -0400
From: "Michael T. Babcock" <[EMAIL PROTECTED]>
Subject: Re: Using floating-point arithmetic in cryptography
Mind you, on the low end, Intel decided to create MMX which is essentially
multi-byte integer math functions ... (I know of some really good
cryptographic optimizations using MMX and variations thereof). MMX ended
up being pretty much a bomb in useability because very few applications (as
you stipulate) benefit much ... graphics rendering in two dimensions being
one of the few (especially true colour work).
Does anyone have a good website reference for crypto-optimizations using
3Dnow! or other SIMD implementations that support integers?
"D. J. Bernstein" wrote:
> Thomas Pornin <[EMAIL PROTECTED]> wrote:
> > There are few applications that really use intensively
> > the possibility to go beyond 32-bit arithmetic without using the math
> > coprocessor. In that respect, cryptography is the exception.
>
> The main reason that big-integer arithmetic is an exception here is that
> most big-integer software is written for an unrealistic machine model.
>
> The market for fast floating-point arithmetic is huge. Big companies
> blow incredible wads of money on giant stacks of computers dedicated to
> floating-point computations. CPU designers know this.
>
> In contrast, the market for fast double-length integer arithmetic is, to
> put it bluntly, nonexistent. CPU designers know this.
>
> Consequently most CPUs have far better support for floating-point
> arithmetic than for double-length integer arithmetic. Fortunately,
> big-integer arithmetic can be built on top of floating-point arithmetic.
> This is what new implementors should be learning.
>
> (I don't mean to suggest that 100% of the world's computer power is
> available through floating-point operations. New CPU manufacturers,
> lacking the expertise needed to break into the floating-point market,
> usually hold off for a while on serious floating-point support. Often
> the fastest way to perform arithmetic is with a strange combination of
> floating-point operations and other operations. But pure floating-point
> arithmetic is a much better starting point than double-length integer
> arithmetic.)
>
> ---Dan
--
_____/~-=##=-~\_____
-=+0+=-< Michael T. Babcock >-=+0+=-
~~~~~\_-=##=-_/~~~~~
http://www.linuxsupportline.com/~pgp/ ICQ: 4835018
------------------------------
** FOR YOUR REFERENCE **
The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:
Internet: [EMAIL PROTECTED]
You can send mail to the entire list (and sci.crypt) via:
Internet: [EMAIL PROTECTED]
End of Cryptography-Digest Digest
******************************
