Cryptography-Digest Digest #994, Volume #10 Fri, 28 Jan 00 13:13:01 EST
Contents:
Re: Court cases on DVD hacking is a problem for all of us (Troed)
Re: Shamir Secret Sharing ("Scott Fluhrer")
Re: Mac encryption algorithm? (Paul Schlyter)
Re: NEC claims New Strongest Crypto Algor (Volker Hetzer)
Re: NEC claims New Strongest Crypto Algor ([EMAIL PROTECTED])
Re: Why did SkipJack fail? (Greg)
Re: Strong stream ciphers besides RC4? (Uri Blumenthal)
Re: NEC claims New Strongest Crypto Algor (Greg)
Re: How much does it cost to share knowledge? (Paul Schlyter)
Re: WW2 Cypher Yet Unbroken ... (Tim Tyler)
Re: "Trusted" CA - Oxymoron? (Anne & Lynn Wheeler)
Re: *** ECC Strong and Weak combined (Mike Rosing)
Re: Strong stream ciphers besides RC4? (Stefan Lucks)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Troed)
Subject: Re: Court cases on DVD hacking is a problem for all of us
Reply-To: [EMAIL PROTECTED]
Date: Fri, 28 Jan 2000 13:22:59 GMT
[EMAIL PROTECTED] (Terje Elde) wrote:
>Please keep in mind they I might be wrong, as I'm working with second hand
>info here.
Yes, and your info is wrong.
Not going into actual details, the CSS algorithm was reverse
engineered and re-implemented. Not necessarily from Xing's player, not
necessarily by Jon (actually, he did not do it).
Extracting a player key was done from Xing, and the subsequent finding
of flaws in the algorithm itself made it possible to in very short
time find all other DVD keys (there is a limited number of them).
There was really no need to get a key from Xing's player - just
brute-forcing it would have sufficed and would only had taken a few
hours.
Reverse engineering the CSS algorithm (both authentication and
decrypting the data) and then exploiting the flaws in them (they're
nowhere near reaching the 40 bit strength they _could_ have had)
involves more than just creating a GUI for things gotten from Xing ;)
It's a lot like black box reverse engineering, with some "white box"
help. (I would assume this is a lot like the finding of the GSM
comp128 algorithm ... a rumoured full card-readout helped there?)
Fact is, what MoRE did a lot of people posting here regulary do. The
difference is that exploits found this way, even when assembled into
ready-for-use programs, have never gotten so much attention before. My
guess is that DVD-CCA claimed that their algorithm prevented _copying_
(something it's never been able to do) and that they now have to face
serious accusations from their licensees and the members of the MPAA.
Don't let them take this out on a 16 year old Norwegian who's just
been doing what computer enthusiasts have been doing since the days of
the Altaire. Raise your voice, now.
___/
_/
------------------------------
From: "Scott Fluhrer" <[EMAIL PROTECTED]>
Subject: Re: Shamir Secret Sharing
Date: Fri, 28 Jan 2000 06:00:44 -0800
<[EMAIL PROTECTED]> wrote in message
news:86roiu$rag$[EMAIL PROTECTED]...
> Hi all,
>
> I have a question about Shamir Secret Sharing.
>
> In this scheme, we produce a random prime number P > S where S is the
> secret key.
>
> My question is what is the method to produce P, I talk in terme of
> size, not in the method to find a random prime number.
You need P to be larger than the largest valid S. So, if S is a 56 bit DES
key,
then P needs to be a prime greater than 2**56.
Note that this is selecting P based on possible values of S, not the actual
value. Selecting P based on the actual S value is silly, because the
attacker will presumbly known your selection criteria for P, and so if P
depends on S, he will gain some knowledge of S, even if he doesn't have
enough shares. Selecting P based on potential values of S gives the
attacker no additional information, because we assume he knows the
potential values of S already.
>
> The problem is that P is a public data in this scheme.
>
> I explain, if we search the first next prime number after S, it's not
> good for example, beacuse to get S, you test P, P-1, P-2, ... and
> rapidly you get S.
Actually, with secret sharing, it's not possible to test P, P-1, P-2 in
any meaningful way. If you have enough shares,there's no reason.
If you don't have enough shares, then all potential S's are equally
possible with the information you have.
--
poncho
.
------------------------------
From: [EMAIL PROTECTED] (Paul Schlyter)
Subject: Re: Mac encryption algorithm?
Date: 28 Jan 2000 08:28:05 +0100
In article <[EMAIL PROTECTED]>,
Paul Koning <[EMAIL PROTECTED]> wrote:
> About the only hassle you may run into is that some want to do
> arithmetic on multi-byte values in the wrong (Intel style) byte
> order.
And why is this byte order "wrong" ? Little Endian and Big
Endian are merely two different byte orders, both of which have
their advantages and disadvantages.
Ever read Gulliver's travels? There Gulliver meets a people of
dwarves, who had a war with a neighbour dwarf people. What did they
fight about? They fought about which end one should knock an egg
when one wants to eat it: one side, the Big Endians, claimed the egg
should be knocked at the big end, while the other side, the Little
Endians, claimed the egg should be knocked at the little end. Both
sides considered the other side's way of knocking an egg to be
horribly wrong -- and the war between them had raged for centuries,
when Gulliver arrived....
This story should give some food for thought to anyone who claims
that either Little Endian or Big Endian byte ordering is "wrong"....
--
================================================================
Paul Schlyter, Swedish Amateur Astronomer's Society (SAAF)
Grev Turegatan 40, S-114 38 Stockholm, SWEDEN
e-mail: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
WWW: http://hotel04.ausys.se/pausch http://welcome.to/pausch
------------------------------
From: Volker Hetzer <[EMAIL PROTECTED]>
Subject: Re: NEC claims New Strongest Crypto Algor
Date: Fri, 28 Jan 2000 14:39:09 +0000
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.
Well it says that the software interface is compatible, which is entirely
different.
As to surpassed, I didn't see any of that other than a claim of that.
The key requirements are the same as for AES.
Lots of hogwash if you ask me.
Volker
--
Hi! I'm a signature virus! Copy me into your signature file to help me spread!
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: NEC claims New Strongest Crypto Algor
Date: Fri, 28 Jan 2000 14:32:46 GMT
In article <[EMAIL PROTECTED]>,
Arthur Dardia <[EMAIL PROTECTED]> 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
Since they claim to be "backward" compatible with AES, which isn't
even decided on yet, this is even more interesting.
I wonder if this is really a wrapper protocol that they
somehow feel increases security, not an actual an encryption
algorithm.
Marc
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 17:00:37 GMT
> If you don't mind my editorializing for a minute (and this is nothing
> personal),
Hey, I have been flamed by some of the best...
> worrying about brute force cryptanalysis of properly
> designed block ciphers with reasonable keyspace is a common and
> generally pointless obsession of newbies.
Perhaps, but what you may not realize is that I am a what you
affectionately call a newbies. When it comes to ECC, I have spent
the last year intensly developing my own ECC C++ library.
And believe me, I am more surprised that it works than anyone
else. Dr Rosing's book is a completely amazing piece of work.
Before 1999, I did zippo with encryption.
When it comes to RSA, I am just beginning to learn about that
in depth; yet I really am not interested in it because I see it
as an older generation design. I had a very negative opinion
of it being a cryptosystem on its last leg, pushing the envelope
of self credibility. A number of posts here have lead me to think
otherwise in just the last few weeks. While I am not interested
in RSA, these posts have stimulated my curiosity in it.
When it comes to symmetric key ciphers, I am very interested and
I am just recently beginning to spend a large quantity of time
learning about them in depth. Part of this has to do with the
fact that at my company I know more about encryption than anyone else
and we want to use encryption for our Internet services. So I was
the one chosen to work on this part.
One good example of my curiosity is found in Bruce Schneier's
document regarding the impossible differential with Twofish.
The first time I looked at that document, I thought, "My God, how
I would love to understand what these math expressions mean."
But now I have a clue as I read more about impossible differentials.
> It's much more worthwhile
> to worry about protocol bugs, implementation bugs, key management
> lapses, and other issues which have much more frequent practical
> consequence. Those represent far larger vulnerabilities than the
> underlying block ciphers in just about any real-world cryptography
> system.
I completely understand what you are saying here. But as you imagine
(and you imagine correctly) I am not as quick to dismiss brute force
attack, much for the reasons you imply- it is not as intuitive to
me as it is for, say, yourself.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Uri Blumenthal <[EMAIL PROTECTED]>
Subject: Re: Strong stream ciphers besides RC4?
Date: Fri, 28 Jan 2000 12:09:36 -0500
Reply-To: [EMAIL PROTECTED]
Stefan Lucks wrote:
> Daniel Bleichenbacher and Savar Patel have broken SOBER, see
> Daniel Bleichenbacher and Savar Patel: "SOBER Cryptanalysis",
> Fast Software Encryption =B499, Springer LNCS 1636.
Yuck! Do you know if the paper is available in softcopy?
Thanks!
-- =
Regards,
Uri [EMAIL PROTECTED] M.C.Ht N2RIU
-=3D-=3D-=3D=3D-=3D-=3D-
<Disclaimer>
------------------------------
From: Greg <[EMAIL PROTECTED]>
Subject: Re: NEC claims New Strongest Crypto Algor
Date: Fri, 28 Jan 2000 17:07:11 GMT
In article <[EMAIL PROTECTED]>,
"Douglas A. Gwyn" <[EMAIL PROTECTED]> wrote:
> "NFN NMI L." wrote:
> > <<creates a number of fake keys in addition to the true encryption
key. >>
> > What?
>
> That indeed seems to be the "new" feature of the NEC system.
> It would be interesting to hear some detail about this notion.
It would be even more interesting to hear why their engineers
thought this was useful.
>
> > <<NEC says when compared to its previous technology, 1039
calculations
> > would be necessary to crack the new code.>>
> > Reporters never understand anything. Surely NEC isn't this stupid.
>
> I *think* what was meant is that 10^39 (^ meaning "to the power")
> times as many operations are necessary to *brute-force* the cipher.
>
> That's around 2^129.5 which maybe is supposed to be 2^128.
>
--
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] (Paul Schlyter)
Subject: Re: How much does it cost to share knowledge?
Date: 28 Jan 2000 18:00:19 +0100
In article <86qvmm$9ku$[EMAIL PROTECTED]>, Greg <[EMAIL PROTECTED]> wrote:
>That does not mean that some do not exploit it at the expense of
>others. But that is like saying, "Since hackers use computers,
>and we don't want hackers, let's pass a ban on all PCs."
That actually makes sense, because if there hadn't been any hackers,
there would be no PC's either, because the personal computer revolution
started among hackers.
I assume you know the difference between a hacker and a cracker....
--
================================================================
Paul Schlyter, Swedish Amateur Astronomer's Society (SAAF)
Grev Turegatan 40, S-114 38 Stockholm, SWEDEN
e-mail: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
WWW: http://hotel04.ausys.se/pausch http://welcome.to/pausch
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: WW2 Cypher Yet Unbroken ...
Reply-To: [EMAIL PROTECTED]
Date: Fri, 28 Jan 2000 17:39:54 GMT
[EMAIL PROTECTED] wrote:
: This may very well be an old, done-by-hand version of a One Time Pad.
: This particular version uses a random table of 5 digit numbers which is
: added to each character of a message, one letter per 5 digit number.
: Here's an example:
: Suppose the first number in the pad is 12345. Now, we encrypt the
: letter A, which has a value of 1, by adding it to 12345, thus the
: resulting ciphertext is 12346.
: Now, I could be wrong and it may not be a one time pad, but it certainly
: is the closest thing I've seen that produces that type of ciphertext. []
There seem to be two disadvantages compared to an OTP.
* No modulo addition/EOR. This means the plaintext letter corresponding
to the cyphertext 100025 is likely to be known to be "Z". Similarly
00001 is known to be "A".
* Unnecessarily large key. Why use a five digity number when a two-digit
one with XOR would work as well? It seems completely pointless.
--
__________
|im |yler The Mandala Centre http://www.mandala.co.uk/ [EMAIL PROTECTED]
SECRET VIPAR GAMMA GUPPY
------------------------------
Crossposted-To:
alt.privacy,alt.security.pgp,comp.security.pgp,comp.security.pgp.discuss
Subject: Re: "Trusted" CA - Oxymoron?
Reply-To: Anne & Lynn Wheeler <[EMAIL PROTECTED]>
From: Anne & Lynn Wheeler <[EMAIL PROTECTED]>
Date: Fri, 28 Jan 2000 17:55:18 GMT
let's put identity certificates another way ...
the transfer request comes in via smime/email, the body of the message
contains the account number and the directions. this is signed and has
a certificate attached. the bank takes the certificate ... and
authenticates the certificate with the CA's public key ... which comes
from some certificate that it has laying around ... which also may
need authenticating (the trust chain not only has all of their
certificates ... but may also require OCSP transactions).
in any case, eventually after the attached certificate is
authenticated, the message gets authenticated with the public key. THe
account number from the body of the message is then used to look up
the account record. The "name" of the account owner is retrieved from
the account record ... and needs to be compared against some
information in the body of the identity certificate. Supposedly if the
character string in the body of the message matches the character
string on record in the account record ... then the transaction is
supposedly valid.
The CA infrastructure not only has to absolutely bind some set of
identity information to the public key going into the certificate
... but that set of information also has to have some exact match with
the owner "string" in the bank record. The CA infrastructure can
absolutely be sure that they have correctly bound the identity
information ... and the transaction still won't work because the
identity strings don't exactly match (the one in the certificate and
the one in the account record).
So, some number of banks have looked at issuing relying-party-only
certificates ... for privacy and liability issues (as well as
relevency, will the strings match). The "identity" bound in the
certificate is just the bank account number. That slightly simplifies
the process ... since there is no strings to mismatch ... after
verifying the certificates in the trust hierarchy ... the account
number is taken directly from the transaction and reads the account
record (and only the account numbers have to match).
The next step is realizing that the whole CA infrastructure allows
that if the relying party is known to have the trust hierarchy CA
certificates (and/or can expect to easily obtain them) ... the
certificate(s) don't have to be transmitted on every transaction
(i.e. the CA certificates to validate a individual's certificate is
assumed to be already at the relying party ... and/or the relying
party can easily obtain it). In the case of relying-party-only
certificates, the bank has stored the original certificate in the
account record and sent a copy to the individual. Then under current
CA infrastructure policies, if the relying party can be assumed to
have a copy of the certificate(s) (&/or can easily obtain them, they
don't have to be retransmitted) ... then the individual signing the
transaction doesn't have to retransmit copies. In this case, the
relying party is known to have all certificates, including the
original of the individuals certificate.
So, the bank just pulls the account number from the transaction, reads
the account record, pulls the public key out of the account record,
and uses it to validate the digital signature on the transaction.
For efficiency purposes the public key will be stored in unencoded
form in the account record. Certificates are defined in encoded for
for interoperable network transmission, but have to be decoded in
order to access the fields, the bank can store the unencoded
certificate fields in the account record since the ASN.1/encoded form
is only needed for interoperble transmission & revalidation of the
CA's signature. Since they create the original of the certificate,
they have signed it ... just for redundancy they could reverify their
own signature at certificate manufactor time, before decoding and
loading into the account record.
--
Anne & Lynn Wheeler | [EMAIL PROTECTED], [EMAIL PROTECTED]
http://www.garlic.com/~lynn/ http://www.adcomsys.net/lynn/
------------------------------
From: Mike Rosing <[EMAIL PROTECTED]>
Subject: Re: *** ECC Strong and Weak combined
Date: Fri, 28 Jan 2000 11:55:31 -0600
Greg wrote:
> 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?
No, you could easily brute force find an 8 bit key. You could
even easily brute force find an 8 bit hamming weight key over
a very large field size. The idea I was trying to explain is
that you can find a "cross over" point where brute force takes
as long or longer than a mathematical search. With today's
technology, we know the cross over point has to be well beyond
56 bits. 64 bits is secure today and 80 bits will be secure
for at least 10 years.
> 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.
Correct. By changing client keys as personal computers increase
in speed you can keep current with security while making previous
transmissions possible to attack. You'll have to figure out the
time value of the secrets and make the client's key long enough
to ensure it stays secret to cover that time. Most financial
transactions only need a year of cover at most, but political
communications may require full maximum security forever. That's
your call ;-)
Patience, persistence, truth,
Dr. mike
------------------------------
From: Stefan Lucks <[EMAIL PROTECTED]>
Subject: Re: Strong stream ciphers besides RC4?
Date: Fri, 28 Jan 2000 18:54:28 +0100
On Fri, 28 Jan 2000, Uri Blumenthal wrote:
> Stefan Lucks wrote:
> > Daniel Bleichenbacher and Savar Patel have broken SOBER, see
> > Daniel Bleichenbacher and Savar Patel: "SOBER Cryptanalysis",
> > Fast Software Encryption ´99, Springer LNCS 1636.
>
> Yuck! Do you know if the paper is available in softcopy?
I doubt it. You may try to ask the authors Daniel Bleichenbacher and Savar
Patel -- both work at Lucent Technologies (lucent.com) or have a look at
Counterpane's Crypto Papers page:
Linkname: Crypto Papers Online
URL: http://www.counterpane.com/biblio/
--
Stefan Lucks Th. Informatik, Univ. Mannheim, 68131 Mannheim, Germany
e-mail: [EMAIL PROTECTED]
home: http://th.informatik.uni-mannheim.de/people/lucks/
===== Wer einem Computer Unsinn erzaehlt, muss immer damit rechnen. =====
------------------------------
** 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
******************************
