Cryptography-Digest Digest #989, Volume #10 Thu, 27 Jan 00 20:13:01 EST
Contents:
Re: NEC claims New Strongest Crypto Algor ("Trevor Jackson, III")
Re: Reversibly combining two bytes? ("Trevor Jackson, III")
Re: NEC claims New Strongest Crypto Algor (Glenn Larsson)
Re: Newbie to PGP: RSA vs DH/DSS (Frank the_root)
Re: NEC claims New Strongest Crypto Algor (John Savard)
Re: NEC claims New Strongest Crypto Algor (John Savard)
Re: New to cryptology question, rolling XOR ("Jonas")
Re: Any Reference on Cryptanalysis on RSA ? ("Markus Eiber")
Re: NIST, AES at RSA conference (John Savard)
Re: *** ECC Strong and Weak combined (Greg)
Re: Why did SkipJack fail? (Greg)
Re: Why did SkipJack fail? (Greg)
Re: Why did SkipJack fail? (Greg)
Re: NIST, AES at RSA conference ([EMAIL PROTECTED])
Re: Why did SkipJack fail? (Greg)
Re: Why did SkipJack fail? (Greg)
Re: Why did SkipJack fail? (Greg)
Re: Why did SkipJack fail? (GJJ)
----------------------------------------------------------------------------
Date: Thu, 27 Jan 2000 18:16:48 -0500
From: "Trevor Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: NEC claims New Strongest Crypto Algor
Arthur Dardia wrote:
> Apparently NEC thinks they've developed the strongest crypto in the
> world. In addition, they claimed that they've met and surpassed the AES
> standards. The algorithm is backwards compatible with DES and AES as
> well. It's a rather interesting read, but I'd like to see some source.
> I highly suggest you check it out.
>
> http://www.currents.net/newstoday/00/01/25/news4.html
>
I am 99.9bar% certain that the NEC researchers didn't make they claims
stated above, or even in the referenced article.
The claim "strongest crypto in the world" is certainly more grandiose than
"... currently the strongest form of
encryption technology for securing e-commerce (sic) transactions as they
travel over public data networks."
And the article is probably garbled with respect to the compatibility issue
because it states the _interface_ is compatible, not that the encryption is
compatible.
It will be interesting to see the actual system description.
------------------------------
Date: Thu, 27 Jan 2000 17:35:53 -0500
From: "Trevor Jackson, III" <[EMAIL PROTECTED]>
Crossposted-To: sci.crypt.research
Subject: Re: Reversibly combining two bytes?
Alan Lawrence wrote:
> Hi -
>
> Thanks for your suggestions - in particular the use of a balanced Latin
> square, that is a 256*256 grid where each row and each column contains
> each of the numbers 0..255 exactly once. This seems a good solution
> provided a good method of generating such squares can be found.
>
> A method suggested was to generate two byte arrays c[0..255] and
> r[0..255], both containing all the numbers from 0.255 once, permuted
> randomly (and hopefully differently).; then, the <x>th row of the latin
> square contains the numbers in c rotated r[x] spaces to the right. How
> about this alternative method: instead make the <x>th row contained the
> numbers in c, all multiplied (modulo 257, a byte of value 0 meaning 256)
> by r[x]. A third byte array b[0..255] could be used to rotate the rows as
> well if this would increase security. (?)
A critical aspect of the original proposal was that it cannot cause duplicates
in a row or column. If you add a second transform, whether rotation or
modular multiplication you will almost certainly create duplicates.
The original proposal contained(256!)^2 states. A true latin square filled by
backtracking or a similar technique has far more state than this. If you want
to increase security you must add to the number of possible states without
creating an invalid state (duplicates).
>
>
> Secondly, Terry Ritter's glossary <http://www.io.com/~ritter/GLOSSARY.HTM>
> states that a balanced Latin Square has "massive internal state". The
> "state" is presumably the large table of numbers forming said square,
> however this state does not change during operation. Would a dynamic
> version not be better? After the cipher byte is selected by key and
> plaintext bytes, the square could be altered similarly to a dynamic
> substitution cipher: swapping the rows of the table indicated by key and
> plaintext, and swapping the columns also.
>
> Is this decryptable (given the key)? In the simplest case, yes, but
> imagine the case where a plaintext byte is put through such a square twice
> to produce a cipher. When decrypting, we have the cipher text - the output
> of the second table - and the first table (i.e. before it was altered). To
> produce the second table from the first, we need the plaintext or
> intermediate bytes; but to produce either of these, we need the second
> table....can anyone see a way round this? (the square may even be used >2
> times).
There are (spatially expensive) solutions to this problem, but iterating on
pure substitution does not buy you much security. You've got an 8 bit input
and an bit output. After one substitution any input can map to any output.
After two substitutions you have the same set of possible maps.
Now if you alternate substitution with (say) transposition you get some value
out of multiple iterations.
------------------------------
From: Glenn Larsson <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: NEC claims New Strongest Crypto Algor
Date: Thu, 27 Jan 2000 23:57:00 +0100
>From the page:
> Instead of a fixed encryption code 128 bits in length, a a
> dynamic encryption code is used, capable of using key lengths
> of either 128 bits, 192 bits and 256 bits.
So..
-"Instead of a banana we've used a yellow-fruitlike thing
called a banana that's longer than a banana..."
> The CIPHERUNICORN-A encryption software interface is
> compatible with the Data Encryption Standard (DES)
> encryption standard, as well as with the next-generation
> Advanced Encryption Standard (AES).
Pretty strong statement - How can something be compatible
with something that haven't been decided yet?
Anyone have any better links written by a non-journalist?
.Reg's
Glenn
_________________________________________________
Spammers will be reported to their government and
Internet Service Provider along with possible legal
reprocussions of violating the Swedish "Personal
Information Act" of 1998. (PUL 1998:204)
------------------------------
From: Frank the_root <[EMAIL PROTECTED]>
Subject: Re: Newbie to PGP: RSA vs DH/DSS
Date: Thu, 27 Jan 2000 23:17:43 GMT
> RSA, while a good choice, would not be on my list. It is rumored that
> the US Gov't doesn't use RSA (not for patent-related reasons), which
> gives me an uncomfortable clue.
Why? Is that because there is too much poeple working on its breaking?
Frank
--
Ceux qui r�vent le jour, savent des choses qu'ignorent ceux qui r�vent
la nuit.
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: NEC claims New Strongest Crypto Algor
Date: Thu, 27 Jan 2000 16:21:01 GMT
Arthur Dardia <[EMAIL PROTECTED]> wrote, in part:
>Apparently NEC thinks they've developed the strongest crypto in the
>world. In addition, they claimed that they've met and surpassed the AES
>standards. The algorithm is backwards compatible with DES and AES as
>well. It's a rather interesting read, but I'd like to see some source.
>I highly suggest you check it out.
>
>http://www.currents.net/newstoday/00/01/25/news4.html
NEC's official news release on CIPHERUNICORN-A is at
http://www.nec.co.jp/japanese/today/newsrel/9804/1001.html
unfortunately, as you may be able to guess from the URL, it's in
Japanese.
In fact, a GeoCities site, and a Ziff-Davis news article, mentioning
this cipher were also in Japanese. Actually, the GeoCities site
mentioned CIPHERUNICORN-E, which is an earlier NEC cipher using this
technique, whatever it might be...
John Savard (jsavard<at>ecn<dot>ab<dot>ca)
http://www.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: NEC claims New Strongest Crypto Algor
Date: Thu, 27 Jan 2000 16:14:27 GMT
Arthur Dardia <[EMAIL PROTECTED]> wrote, in part:
>Apparently NEC thinks they've developed the strongest crypto in the
>world. In addition, they claimed that they've met and surpassed the AES
>standards. The algorithm is backwards compatible with DES and AES as
>well. It's a rather interesting read, but I'd like to see some source.
>I highly suggest you check it out.
It might be very interesting to design a strong algorithm, such that
if all but the last 56 bits were zero, it would be weaker, and
equivalent to DES.
Since the AES hasn't been decided yet - and some of the finalists, if
they lose, will remain proprietary, though, I find the claim of AES
compatibility interesting.
Or maybe this was garbled, and what is *really* meant is that it can
be used with a 64- or 128- bit blocksize, and 56-, 128-, 192-, or 256-
bit keys, without "compatibility" in the sense of interoperability,
just the ability to act as a replacement.
And NEC could *easily* invent a stronger algorithm than an AES
candidate. Just double the rounds, add complications - so designing
something stronger in symmetric cryptography is no big major claim.
That part, therefore, stimulates no doubt in me. Look at some of my
Quadibloc designs (on my web site)...and I'm only an amateur.
John Savard (jsavard<at>ecn<dot>ab<dot>ca)
http://www.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: "Jonas" <[EMAIL PROTECTED]>
Subject: Re: New to cryptology question, rolling XOR
Date: Fri, 28 Jan 2000 00:16:40 +0100
Actually i used 8 bit to make an example, let's say i use 20 byte, 160
randomed bits that won't be reused, could you break a message if i supported
you with the java script that do the encrypttion decryption?
I don't know if it's safe but i'll say it's fast.
It's here i can send you a text would be nice to see an cryptoanalyst at
work.
What's the time space to break the 160 bit key?
Douglas A. Gwyn skrev i meddelandet <[EMAIL PROTECTED]>...
>Jonas wrote:
>> To me it seems like you never can predict the outcome without
>> knowing the text or password?
>
>The thing is, usually the cryptanalyst "knows" (i.e., can guess
>with non-negligible probability) some of the plaintext; he only
>needs 8 bits in your example, which amounts to one ASCII character.
>That allows him to easily recover some of the effective key, which
>can be applied to the position 8 bits farther back to recover
>an earlier key bit, and so forth.
------------------------------
From: "Markus Eiber" <[EMAIL PROTECTED]>
Subject: Re: Any Reference on Cryptanalysis on RSA ?
Date: Fri, 28 Jan 2000 00:24:19 +0100
"Bob Silverman" <[EMAIL PROTECTED]> schrieb im Newsbeitrag
news:86q7v3$nuq$[EMAIL PROTECTED]...
> Good for you. There is a problem, however. It is generally
> impossible. Breaking DES requires time only. Breaking RSA requires
> lots of time and MASSIVE space.
>
> If breaking both took 10 hours, but DES required 2KB RAM while RSA took
> 10 Gbytes, one might say RSA is harder [at the very least one has to
> spend more on hardware]. But suppose DES took 10 hours while
> RSA took "only" 8 hours but required 1 Tbyte of memory. Which would
> you say is harder?
>
> You can't easily compare the two. The dimensions which measure the
> difficulty of the two problems are not compatible.
Of course you are in principle right. But isn�t it possible to express the
amount of ressources needed to break cipher as a cost factor?
Both, time and space costs money. I think on this level the two algorithms
(especially their security-levels) are comparable.
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: NIST, AES at RSA conference
Date: Thu, 27 Jan 2000 16:27:07 GMT
CLSV <[EMAIL PROTECTED]> wrote, in part:
>[EMAIL PROTECTED] wrote:
>> Alas the situation is still worse. We don't even know that
>> practical and secure ciphers exist. We cannot disprove, or
>> even bound the probability away from 1, that an attacker has
>> a single algorithm that breaks all key-based ciphers given
>> ciphertext that covers the unicity distance.
>A *single* algorithm that breaks *all* key-based ciphers?
>I think/believe that this is awfully close to being
>reducible to the Halting Problem. It does not sound very
>realistic to me.
Actually, the reverse case, proving that some cipher can't be broken
with less effort than a certain amount, is closely related to the
Halting Problem. It is certainly quite unlikely that a single
algorithm will "break all ciphers", but even the nonexistence of that
is likely not _provable_ for the same reason.
But we rely on things that can't be mathematically proven all the
time; for example, we trust other human beings. The absence of proof
simply means we need to use other criteria for determining which
cipher systems to use. Using multiple ciphers _in a reasonable
fashion_, may well contribute, under some circumstances, to improved
confidence in security.
John Savard (jsavard<at>ecn<dot>ab<dot>ca)
http://www.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: Greg <[EMAIL PROTECTED]>
Subject: Re: *** ECC Strong and Weak combined
Date: Thu, 27 Jan 2000 23:50:26 GMT
> > I was doing some testing recently with my ECC code and I noticed
> > that if I have a curve over a large field and a key that has the
> > most significant bit set, it takes about one second to complete
> > a point operation.
> >
> > Yet, if I keep the key value very small where, say, the 80% MSBs
> > are clear, then the operation is very fast. This makes me think
> > that given a very strong public key for a server, a client can
> > use a random small private key which can be used to quickly generate
> > both the client's public key and shared secret. The client side
> > is very fast on these operations because its private key is
> > small. The client's public point is then sent to the server
> > and the server performs a point operation of its own to derive
> > the same shared secret.
> >
> > While the server takes as long as usual, the benefits of this
> > strategy (limiting the client private key size) include:
> >
> > Faster client key setup
> > Faster client secret setup
> > Weak secret does not weaken server public key
> >
> > Any thoughts?
>
> The problem is that it makes finding the client's
> secret easy. An attacker will know that the value
> to search for is smaller than the whole space, and
> they can brute force search for the right secret.
> Once they have it, it will be easy to create the
> shared secret using the server's public key.
>
> You can compromise and make the client's key 50%
> clear. Then brute force is harder (assuming
> you're above 160 bits) than a mathematical search.
> The client only has an 80 bit key, but that's still
> plenty secure since you're over a 160 bit field.
> Anything below 64 bits on the client side (independent
> of the field size) makes brute force search possible.
> Once you get a field size that makes brute force
> infeasable, the attacker still knows the answer will
> be half zeros, but they won't know how to easily find
> it and will have to do a full math attack (which is
> order 2^80 for 160 bit field size).
You know, I was looking at this from the point of view
of a faster key setup on the client side in exchange for
encryption strength. But now you got me thinking...
Would you say that a mathematical search is preventable
for any key, even if it is limited to say 8 bits, if the
field size is large enough? If so, I would certainly
like to know why. If such an explanation is already
found in your book, could you direct me to it? Or some
other documentation on the web perhaps?
And if I understand you correctly, I could make a server public
key from a curve over a field of say 200+ bits and it should
remain a secret for the rest of my life while I can then speed
up the shared secret calculations and limit its encryption
strength to a life time of say a few years by limiting the
number of bits to around 60 bits. Thus while my private key
is well guarded for the rest of my life, the calculation time
on the client side can be reduced to match the required life
time of the secret being encrypted.
Would you agree?
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Greg <[EMAIL PROTECTED]>
Subject: Re: Why did SkipJack fail?
Date: Fri, 28 Jan 2000 00:03:44 GMT
In article <[EMAIL PROTECTED]>,
"Douglas A. Gwyn" <[EMAIL PROTECTED]> wrote:
> Vernon Schryver wrote:
> > ... What was (and perhaps is) the cost
> > of the various efforts to tap the Russian undersea cables?
>
> A proper economic evaluation requires that one also take into
> account the expected benefits. (See Hazlitt.)
In the case cited above, ecomonic evaluation is more akin
to risk analysis.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Greg <[EMAIL PROTECTED]>
Subject: Re: Why did SkipJack fail?
Date: Fri, 28 Jan 2000 00:05:10 GMT
> Oh, let's see: assume some large bank decides that DES isn't
> particularly secure anymore, and starts to use SkipJack to carry out
> transactions between its offices. I could easily see a large bank
> doing FAR more than $200M/year in transactions, and I think most
banks
> know the value of money well enough that they wouldn't sell you $200M
> for a lot less than that...
Forget the transaction- what about the assests in the vaults?
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Greg <[EMAIL PROTECTED]>
Subject: Re: Why did SkipJack fail?
Date: Fri, 28 Jan 2000 00:05:45 GMT
In article <[EMAIL PROTECTED]>,
"Douglas A. Gwyn" <[EMAIL PROTECTED]> wrote:
> Jerry Coffin wrote:
> > In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] says...
> > > True, but what would it be that couldn't be bought more cheaply?
> > Oh, let's see: assume some large bank ...
>
> You missed the "bought more cheaply" part. I'm pretty sure
> that for less than $200,000,000.00 one could bribe enough bank
> officers to accomplish the same effect.
many times over...
--
The only vote that you waste is the one you never wanted to make.
RICO- we were told it was a necessary surrender of our civil liberties.
Asset Forfeiture- the latest inevitable result of RICO.
http://www.ciphermax.com/book
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: NIST, AES at RSA conference
Date: Fri, 28 Jan 2000 00:09:44 GMT
Terry Ritter wrote:
>
> On Thu, 27 Jan 2000 04:04:34 GMT, in <86og4f$fu5$[EMAIL PROTECTED]>, in
> sci.crypt [EMAIL PROTECTED] wrote:
>
> >Terry Ritter wrote:
> >
> >[...]
> >>
> >> Another way to deal with real life ciphering is to use methods
which
> >> tend to isolate and protect the ciphers we cannot trust. For
example,
> >> multi-ciphering with a sequence of different ciphers has
advantages.
> >
> >Giving us a multi-cipher we cannot trust. The probability
> >of weakness argument still applies and with the same
> >parameters.
>
> That argument is false: Any cipher you are willing to trust alone can
> be made one layer of a multi-cipher. So if your favorite cipher
> really is strong, the multi-cipher stack of ciphers will be strong.
> But if your cipher is *not* strong, the other ciphers may provide the
> strength your selection lacked. That added possibility clearly *is*
> an increased probability of strength.
By how much did it increase? Can you now bound the
probability of a break away from one? If so please do, and
if not then the same problem applies with the same numbers.
If we cannot show that our adversary lacks a general
solution, then we do not know that the probability of the
chain falling is less than that of a single cipher falling.
> Furthermore, the other ciphers in the stack obviously prevent
> simultaneous access to plaintext and ciphertext for your favorite
> cipher. This protects your cipher against known-plaintext and
> defined-plaintext attacks of all sorts. This added protection clearly
> *is* a form of added strength.
But where is the proof that the adversary will have to
attack it that way? If in fact he has a general solution,
then the argument is irrelevant. Does adding additional
cipher layers seem stronger? Absolutely. Does it help us
prove strength? No, at least it hasn't yet.
>
> >
> >[...]
> >> Your "warm and fuzzy" detector perhaps has failed to take into
account
> >> the little detail of *risk*: In particular, the risk of an entire
> >> society locked-in to using a single cipher, or any small set of
> >> ciphers.
> >
> >Alas we cannot show that the risk of using a large, or even
> >open-ended set of ciphers is any smaller.
>
> False yet again: By partitioning plaintext for protection under many
> different ciphers (instead of protecting all plaintext under the same
> cipher), we find that the whole of the plaintext can be exposed only
> by breaking *all* of the ciphers, instead of just one. Since this
> would involve breaking your favorite cipher plus many other ciphers,
> it is obviously harder than just breaking your cipher alone, which is
> once again a proof of added strength.
All we can prove is that the stack is at least as strong as
its component ciphers. We cannot prove that strong
multi-ciphers even exist.
In fact a multi-cipher with independent keys is a special
case of a single cipher with one key. We cannot justify
dismissing single ciphers with no regard to their internal
structure, then admitting multi-ciphers. My single cipher
might be equivalent to Blowfish followed by IDEA followed by
Rijndael, each with independent keys. If we dismiss that
cipher simply because we cannot accept a single cipher with
no proof of security, it makes no sense to accept a
multi-cipher that happens to be equivalent.
--Bryan
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Greg <[EMAIL PROTECTED]>
Subject: Re: Why did SkipJack fail?
Date: Fri, 28 Jan 2000 00:09:46 GMT
> The way to slow down brute force search is with more bits of keyspace,
> not more complexity to the cipher.
This is always the cheap way to increase security, but does it
always work? Does DES used three times with a total key size
of 168 bits yield the same strength of a cipher that uses a
native key size of 168 bits, like Blowfish?
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Greg <[EMAIL PROTECTED]>
Subject: Re: Why did SkipJack fail?
Date: Fri, 28 Jan 2000 00:15:00 GMT
> ...Of course, if an representative of the
> NSA shows up, he probably automatically has a better bargaining
> position than a representative of the EFF in any case.
Well, if I were the owner of the foundry, I would feel in a better
position to bargain if the NSA showed up- they have an almost
unlimited supply of financing. That being said, I am quite
certain they have their own foundry or use one that the CIA runs?!
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Greg <[EMAIL PROTECTED]>
Subject: Re: Why did SkipJack fail?
Date: Fri, 28 Jan 2000 00:23:20 GMT
> probably reasonably safe -- I'd bet more messages encrypted with PGP
> have to do with what the new secretary looks like in a mini-skirt
than
> with anything worth tens or hundreds of millions of dollars a year...
I don't work for a financial institution, civilian law enforcement
agency, private eye, research group, insurace business, or the local
library. So I just wouldn't know myself...
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: GJJ <[EMAIL PROTECTED]>
Subject: Re: Why did SkipJack fail?
Date: Thu, 27 Jan 2000 16:59:33 -0800
You may be interested to know that the Skipjack algorithm is still
being used in a chip sold to government and businesses by the original
company contracted to do the Clipper chip i.e. Mykotronx. (I was at
their parent company - Rainbow Technologies (http://www.rainbow.com) -
recently so I did some research on their products). The chip is known
as the MYK-78E. Check out this site:
http://www.rainbow.com/mykoweb/crypchip.htm
GJJ
* Sent from RemarQ http://www.remarq.com The Internet's Discussion Network *
The fastest and easiest way to search and participate in Usenet - Free!
------------------------------
** 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
******************************
