Cryptography-Digest Digest #514, Volume #12 Wed, 23 Aug 00 10:13:01 EDT
Contents:
Re: Comment from Hardware Experts Please ([EMAIL PROTECTED])
Re: The DeCSS ruling and the big shots (Daniel Leonard)
Re: Questions about stream cipher (Mark Wooding)
Re: The DeCSS ruling (Jim Steuert)
Re: The DeCSS ruling (Gisle =?iso-8859-1?Q?S=E6lensminde?=)
Re: An interesting cryptographic problem (Mark Currie)
Re: Crypto Coprocessor on Javacard (Daniel James)
Re: Questions about stream cipher ([EMAIL PROTECTED])
Steganography vs. Security through Obscurity ([EMAIL PROTECTED])
----------------------------------------------------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Comment from Hardware Experts Please
Date: Wed, 23 Aug 2000 12:37:11 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Mack) wrote:
> >My question is about performming a hardware multiplication in GF(2^n)
> >modulo an appropriate primitive polynomial. Sorry if my questions
> >seems vague, I am not a hardware expert.
> >
> >Generally I have two questions:
> >
> >1. Can it be done with relatively low amounts of hardware. I.e
> >cheaper unit. Low power as well.
> >
> >2. Can it be done with a relatively high output rate. Relative to
> >what I am not sure, i.e can it be done quickly? Say something close
to
> >nlog n steps?
>
> lets see.
>
> Note that Bits is a class
> of bit strings with operation ^ and <<
> and functions zero,bit and log 2
>
> Bits mulpol(Bits X,Bits Y,Bits M)
> {
> int n,i;
> Bits R;
>
> n=M.log2();
> R.zero();
> for (i=0;i<N;i++)
> {
> if (Y.bit(i)) R=R^X;
> X=X<<1;
> if (X.bit(n)) X=X^M;
> }
> return R;
> }
>
> let me know if I have it wrong but that
> seems like the algorithm to me.
>
> for 64 bits it can be simplified
> note that the highest bit of M is dropped
> this assumes a type equivalent to U64
> and corresponding operations
>
> #define U64 unsigned long long
>
> U64 mul64(U64 X,U64 Y,U64 M)
> {
> int i;
> for (i=0;i<63;i++)
> {
> if ((Y&(((U64)1)<<i)!=0) R^=X;
> if ((X&(0x8000000000000000))!=0) X=(X<<1)^M;
> else X<<=1;
> }
> if ((Y&(0x8000000000000000))!=0) R^=X;
> return R;
> }
>
> >
> >I want to design a 128-bit block cipher using decorrelation in eight
> >rounds, this requires a 64-bit GF multiply which is very costly in
> >software. In hardware this cipher would require 1024 bits of SRAM
but
> >this could be fed into the unit any way (i.e fed into latches in the
> >execution pipeline), and if the GF multiply is efficient in hardware
> >then the cipher could be practical for real usage.
>
> In hardware you have a trade off in speed and silicon usage.
>
> you can use a single shift register (fixed shift) and one bit
selector and
> two xor units (both bit controlled) with a 6 bit counter.
>
> or you can use 64 shift registers (fixed shift) and 64 xor units
> all of them bit controlled and 64 polynomial division units.
>
> Note that the polynomial division units take a LOT of silicon.
Hmm thanks for the info. Wouldn't it be possible to speed up the
routine by pipelining it such that as one quantity is being xor'ed to
the result the next 'shift' value is being found?
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Daniel Leonard <[EMAIL PROTECTED]>
Subject: Re: The DeCSS ruling and the big shots
Date: Wed, 23 Aug 2000 13:08:56 GMT
On 22 Aug 2000, Mark Wooding wrote:
> rot26 <[EMAIL PROTECTED]> wrote:
>=20
> > I'd just like to know what the general attitude of sci.crypt readers ar=
e
> > towards the DeCSS case... Isn't it about time the "big shots" use their
> > influence to stop the bullying by the MPAA, educate the public and
> > perhaps give 2600 their support? (It could be my ignorance and that the=
y
> > are doing it already... I stand to be corrected.)
>=20
> The list of people who gave statements to Martin Garbus (who is
> representing 2600 in this case) reads like a cryptographic who's-who.
> There are lots of familiar names there saying sensible things.
>=20
> -- [mdw]
>=20
Where do I find such a list ?
==========
Daniel L=E9onard
OGMP Informatics Division E-Mail: [EMAIL PROTECTED]
D=E9partement de Biochimie Tel : (514) 343-6111 ext 5149
Universit=E9 de Montr=E9al Fax : (514) 343-2210
Montr=E9al, Quebec Office: Pavillon Principal G-312
Canada H3C 3J7 WWW :
------------------------------
From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: Questions about stream cipher
Date: 23 Aug 2000 13:01:14 GMT
[EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] (Mark Wooding) wrote:
> > No, SEAL can't do random seeking.
>
> Um yes it can. Why do you think it allows for stretching of 32- bit
> 'index' variables? That's fairly close to seeking.
No, it's almost completely different. What you can do with a BBS
generator, if you know the factors, is seeking. SEAL gives you a
mapping from a key to 2^32 different nonseekable pseudorandom streams.
That's not the same at all.
-- [mdw]
------------------------------
From: Jim Steuert <[EMAIL PROTECTED]>
Subject: Re: The DeCSS ruling
Date: Wed, 23 Aug 2000 09:20:47 -0400
What about just plain curiosity? Can that be a legal reason for
reverse engineering? Otherwise we have thought police. Of course,
I know there are valid limitations: it could be dangerous to reverse-engineer
"and publish" things which could endanger (such as weapons), but software
does not fit that category. Anyone with a debugger can step through and
record any software.
I can't tell me how many times I have learned things via curiousity from
ftp sites (ftp.funet.fi) or others that I have since applied in my job.
Indeed, isn't
this eu law a bit hypocritical given that nature of the ftp.funet.fi and
garbo sites
(which were basically reverse-engineering of US intel/dos/pc/c computing
issues over the years). Didn't Linus Torvalds reverse-engineer Minix?
-Jim Steuert
Gisle Sælensminde wrote:
> In article <[EMAIL PROTECTED]>, Pekka Ala-Mäyry wrote:
> >lcs Mixmaster Remailer wrote:
> > ...
> >> A note: In the Europeon Union reverse-engineering is legal.
> >> The reverse engineering was not done in the United States.
> >
> >In Finland reverse engineering of software if illegal. When I checked
> >the situation in the EU I found "391L0250 Council Directive 91/250/EEC
> >of 14 May 1991 on the legal protection of computer programs" which is
> >seeminly identical to that of Finland legistlation. So I dare to say
> >that it is illegal also in Europe. If I remember right this was the
> >reason for action of the Norvegian Police.
> >
> >Ref: http://europa.eu.int/eur-lex/en/lif/dat/1991/en_391L0250.html
>
> The intention of this law is to allow revese engineering
> if there is sensible reason for doing so. If the reason was to develop a
> player for Linux, it's legal, but not if the intention is to
> make unatorized copies. The problem is that this becomes a question of
> intention of the one doing the reverse engineering. Jon Johansen must
> prove for the court that he was not doing this
> in order to make illegal copies.
>
> A difference between the European union law and the Norwegian,
> that applies for Jon Johansen, is that the Norwegian law says
> somthing like: "No agreement can make an exception from this right".
> In other words, a licence that forbids any revese engineering will
> be illegal according to Norwegian law. I cannot find such a rule in
> the EU laws, and I don't know how courts in the European Union will
> do in cases where reverse engineering is forbidden by agreement,
> like I think is the case for DVD.
>
> I know that the central European court tradition is more restrictive
> in how far an agreement can go compared to the American tradition,
> so it's possible that such a agreement not would have been legal
> anyway, but I'm not a lawyer, and as far as I know, there has been
> no supreme court decisions in any European country regarding this
> law.
>
> >
> >Decompilation
> >
> >1. The authorization of the rightholder shall not be required where
> > reproduction of the code and translation of its form within the
> > meaning of Article 4 (a) and (b) are indispensable to obtain the
> > information necessary to achieve the interoperability of an
> > independently created computer program with other programs, provided
> > that the following conditions are met:
> > (a) these acts are performed by the licensee or by another person
> > having a right to use a copy of a program, or on their behalf by
> > a person authorized to to so;
> > (b) the information necessary to achieve interoperability has not
> > previously been readily available to the persons referred to in
> > subparagraph (a); and (c) these acts are confined to the parts of
> > the original program which are necessary to achieve
> > interoperability.
> >
> >2. The provisions of paragraph 1 shall not permit the information
> > obtained through its application:
> > (a) to be used for goals other than to achieve the interoperability
> > of the independently created computer program;
> > (b) to be given to others, except when necessary for the
> > interoperability of the independently created computer program; or
> > (c) to be used for the development, production or marketing of a
> > computer program substantially similar in its expression, or for
> > any other act which infringes copyright.
> >
> >--
> >mailto:[EMAIL PROTECTED] http://www.iki.fi/pam/
> >
> >köyhdytetty uraani kyynelkaasu laukaisin Loviisa LSD Luonto-Liitto mafia
> >malaria marihuana Matts Dumell MC Finland Mika Marenk Mossad MP5 napalmi
> >MVR Mustavihreät Päivät neutroni Neuvostoliitto Olkiluoto Olli Mattila
>
> --
> --
> Gisle Sælensminde ( [EMAIL PROTECTED] )
>
> With sufficient thrust, pigs fly just fine. However, this is not
> necessarily a good idea. It is hard to be sure where they are going
> to land, and it could be dangerous sitting under them as they fly
> overhead. (from RFC 1925)
------------------------------
From: [EMAIL PROTECTED] (Gisle =?iso-8859-1?Q?S=E6lensminde?=)
Subject: Re: The DeCSS ruling
Date: 23 Aug 2000 15:23:25 +0200
In article <[EMAIL PROTECTED]>, Jim Steuert wrote:
>
>Yes, I got a copy some time ago (before it was illegal to post
>it). Although
>I didn't study it yet, now I am very curious about it.
>
>Can anyone in this group explain the code (with annotations). I
>really am
>curious as to why it is breakable. Perhaps posting it with
>annotations but
>without the keys would allow us to understand the algorithm and
>steer us
>away from making that same mistake again. Is that legal? If not,
>then maybe
>a legal description of that algorithm or family of algorithms
>exists
DeCSS was made by breaking keys brute force, and is not that
interesting. It is probably more interesting to read the
cryptanalysis of CSS, that was published after DeCSS was
released.
http://people.a2000.nl/mwielaar/dvd-css/csspaper/css.html
--
Gisle Sælensminde ( [EMAIL PROTECTED] )
With sufficient thrust, pigs fly just fine. However, this is not
necessarily a good idea. It is hard to be sure where they are going
to land, and it could be dangerous sitting under them as they fly
overhead. (from RFC 1925)
------------------------------
Subject: Re: An interesting cryptographic problem
From: [EMAIL PROTECTED] (Mark Currie)
Date: 23 Aug 2000 13:24:17 GMT
Relying purely on access control mechanisms can often be problematic. A
stronger method would be to encrypt the info in the database using a key
derived from the user name and password (Kup). This method is a basic file
encryption method. If there is shared database info, then one could create an
additional user record which consists of a shared key encrypted using Kup. The
shared key can be decrypted by the user and used to access shared database
info.
This is a very basic method, and it also may not be practical for you, but I
merely wanted to show that by encrypting the data, you can provide much
stronger access control.
Mark
In article <8o091n$24v$[EMAIL PROTECTED]>, [EMAIL PROTECTED] says...
>
>[this is a fairly lengthy posting, for which I apologise, but the
>problem is a complex one to explain]
>
>Modern line-of-business systems typically rely on a relational database
>to store information. A user supplies a set of credentials
>(login,password) to the system and is then connected to the RDBMS.
>
>A naive implementation of such a system (and unfortunately, this is a
>common implementation) simply forwards the user's credentials to the
>RDBMS and if the RDBMS validates them, the user is directly connected.
>
>The problem with such an implementation is that the user must often be
>given quite broad rights to database tables in order for the line-of-
>business application to function correctly. Although most modern RDBMS
>products have excellent security systems, enforcing table-level
>security is tedious and in many cases causes the application code to
>malfunction, because it was written with the assumption that full
>permissions to the base tables are available.
>
>Because the user can easily access the database using third-party query
>and reporting tools, any application-level security is easily bypassed.
>This leads to serious security weaknesses and potential audit
>nightmares.
>
>In order to circumvent this problem, some systems map the user's
>credentials indirectly to a database logon and password. By doing so,
>it is intended that the user cannot guess the actual database
>credentials and therefore, although the 'secondary login' has quite
>broad rights, the user would not be able to access the database through
>third party tools since their primary login credentials do not map to a
>database login.
>
>Although this concept is sound in theory, implementation is
>problematic. If the transform from user credentials (username,password)
>to database login (username-prime,password-prime) is via a fixed
>algorithm, i.e security through obfuscation, then a disgruntled
>employee or ex-employee of the software company can penetrate any
>customer's system, since they know the transform.
>
>The alternative is to encrypt the user credentials {u,p} to create
>{u',p'} via a well-known encryption algorithm such as DES. In this
>case, an encryption key must be provided.
>
>If the encryption key is site-specific, then an attack by an ex-
>employee is more difficult since although the algorithm is known, the
>key is not. However, the application software must somehow retrieve the
>key in order to perform the transform.
>
>The problem is therefore to secure the key in such a way that the
>application software can retrieve it programmatically yet a
>knowledgeable outsider could not do so. This means that simply
>sprinkling the key around a large file and knowing the bit offsets
>won't do, if these offsets are stored in a program, you might as well
>have stored the key.
>
>While it is also obvious to think of public-key encryption as somehow
>offering an answer, this does not seem apparent. While PK systems solve
>the problem of key interchange between cooperating parties, they do not
>solve this problem, since encryption and decryption must be essentially
>automated.
>
>Does anyone know of any research that has been done in this area?. For
>example, might it be possible to use an infrastructure such as Kerberos
>in order to grant a ticket which would allow access to an RDBMS?
>
>Since most RDBMS products don't integrate directly with authentication
>services such as Kerberos, there has to be some secure way to transform
>a ticket into a set of logon credentials.
>
>Essentially any solution, however it is implemented must
>
>1. Work with RDBMS products for which the only authentication mechanism
>is to supply a login and password
>
>2. Prevent a user from determining the actual login and password used
>to connect to the RDBMS, even though the user knows their own login
>credentials.
>
>3. Prevent a knowledgeable outsider from penetrating the system by
>avoiding a fixed algorithm.
>
>I should be most interested if anyone can offer any assistance in this
>area. Because all good security systems are absolutely open in their
>implementation, I would much prefer to discuss these issues openly in
>this forum rather than via email.
>
>
>Sent via Deja.com http://www.deja.com/
>Before you buy.
------------------------------
From: Daniel James <[EMAIL PROTECTED]>
Subject: Re: Crypto Coprocessor on Javacard
Date: Wed, 23 Aug 2000 14:42:23 +0100
Reply-To: [EMAIL PROTECTED]
In article <[EMAIL PROTECTED]>, Mack wrote:
> >> Private key operations (decryption and
> >>signing) generally take on the order of 10 seconds, public key
> >>operations (encryption and signature verification) take a second or
> >>so.
> >
> >The GPK400 takes 1.4 seconds for verifying a 1024 bit RSA signature.
> >
>
> The assymetry in the times suggests that the GPK400 has not been corrected
> for some of the more recent attacks on small public keys.
That's not an asymmetry - the 10 second and 1.4 second figures are for
different cards (the GPK4000 can sign or unwrap in a little under a second -
faster than verify because it uses CRT for private key operations).
However, the GPK cards do use a fixed public exponent of 2^16+1, so they are
susceptible to those small-key attacks.
Cheers,
Daniel.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Questions about stream cipher
Date: Wed, 23 Aug 2000 13:44:24 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Mark Wooding) wrote:
> [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> > [EMAIL PROTECTED] (Mark Wooding) wrote:
> > > No, SEAL can't do random seeking.
> >
> > Um yes it can. Why do you think it allows for stretching of 32- bit
> > 'index' variables? That's fairly close to seeking.
>
> No, it's almost completely different. What you can do with a BBS
> generator, if you know the factors, is seeking. SEAL gives you a
> mapping from a key to 2^32 different nonseekable pseudorandom streams.
> That's not the same at all.
Depends on how you use the index. If you have a HD with 4kb clusters
you can seek to any cluster by using using the LBA as the index into
SEAL. That my friend is seeking.
By your logic an HD cannot seek either because technically you cannot
read byte 400014 off any HD, you must read a sector and filter out what
you want. This means file seeking doesn't exist either, which means
files must only be opened for read from 0 to end. Which also means to
open a file you must read all previous files ...
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED]
Subject: Steganography vs. Security through Obscurity
Date: Wed, 23 Aug 2000 13:47:21 GMT
I recently had a discussion concerning the differences between
cryptography and steganography.
I maintained that one of the differences between the two is that
strong cryptography doesn't need obscurity. However, every system
I've seen for steganography requires some obscurity. If the algorithm
is known, then the steganography can be defeated.
In other words, security through obscurity is a requirement for
steganography.
True or false?
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
** 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
******************************
