Cryptography-Digest Digest #516, Volume #12 Wed, 23 Aug 00 15:13:01 EDT
Contents:
Re: Hidden Markov Models on web site! ("Douglas A. Gwyn")
Re: SHA-2 name rumors (Daniel Leonard)
Re: The DeCSS ruling (Jim Steuert)
Re: Steganography vs. Security through Obscurity (Mike Rosing)
Re: An interesting cryptographic problem (Mike Rosing)
Re: The DeCSS ruling (Ichinin)
Re: The DeCSS ruling (Anonymous)
Re: Steganography vs. Security through Obscurity ("Aztech")
Re: Bytes, octets, chars, and characters ("David C. Barber")
Re: Re-using CD-R discs (S. T. L.)
Re: The future direction ... ("Richard Bembridge")
Re: Decryption (John Myre)
----------------------------------------------------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Hidden Markov Models on web site!
Date: Wed, 23 Aug 2000 13:23:06 -0400
Mok-Kong Shen wrote:
> From what I read in this thread I got the (maybe wrong)
> impression that the sequences dealt with are character
> strings. Would HMM be powerful enough to deal with bit
> strings (which are at a finer granularity) from some
> not too bad PRNGs (to predict future output)?
HMM is a general technique, not related to text characters
except when you choose to apply it to them. The model
is simply a finite number of (internal) states that
have fixed state-transition probabilities (ordinary Markov
model) and the additional feature that the only thing
observable is output that depends probabilistically on
the transition. (Each piece of output for a single
transition can be *called* a "character" for convenience
in discussion, but the only assumed property is that it
is uniquely identifiable. The output "character set"
might be the set {0,1}, for example.) So the output
contains clues about what is going on "inside" the model,
but the clues are indirect since the same output can
result from many possible transitions. There are further
clues about the state sequence contained in the *sequence*
of outputs. The process of fitting the model to an
observed output sequence amounts to estimating what
sequence of states (thus transitions) would be the most
likely way of producing that output. Of course, that
guess could be wrong, but given enough output the
trained model (specified by the parameters for the best
fit) usually tends to reflect what is actually going on
inside the (hidden) system. It's sort of like a fuzzy
X-ray.
How successful one is at fitting an HMM is largely a
function of how well the assumed number of states
"resonates with" the internal system structure. You
could try various assumptions and see if any produce
good fits. Presumably there is an objective measure
of goodness of fit of an HMM to the observations,
although it isn't used directly in the usual fitting
algorithm. Informally, if the transition and output
probability matrices are quite far from random, there
is a good fit. For example, a transition matrix
A B C
A 0.7 0.1 0.2
B 0.2 0.5 0.3
C 0.1 0.4 0.5
shows a fairly good categorization, in that the system
tends to stay in the same state, and there are decided
biases in transitions out of the state (e.g. C->A is
4 times less likely than C->B). Suppose the character
set is {0,1} and the output probabilities are:
out 0: A B C
A 0.1 0.7 0.2
B 0.3 0.1 0.6
C 0.6 0.2 0.2
P(out 1) = 1 - P(out 0)
That shows that most "1"s occur when the system remains
in the same state (at this level of modeling), which is
a potentially valuable clue about how the system works.
Of course, the *actual* system structure would involve
a lot more than 3 states; if we had picked the exact
number *and* had enough data, all the matrix entries
would be very close to 0 or 1 since the system is
deterministic at that level. By using fewer states,
we lose the details and end up with a probabilistic
model, but some trends can still be seen, and these
often indicate some large-scale aspects of how the
system actually functions.
------------------------------
From: Daniel Leonard <[EMAIL PROTECTED]>
Subject: Re: SHA-2 name rumors
Date: Wed, 23 Aug 2000 17:32:36 GMT
On Wed, 23 Aug 2000, Kent Briggs wrote:
> "S. T. L." wrote:
>=20
> > SHA-1 provides 160 bits; isn't that enough?
>=20
> Hash functions make convenient password crunchers and with the new AES st=
andard
> allowing key sizes up to 256 bits, it would nice to have a corresponding =
hash
> function of that size.
>=20
> --
> Kent Briggs, [EMAIL PROTECTED]
> Briggs Softworks, http://www.briggsoft.com
Well, three hash function comes into mind
HAVAL, SNEFRU, RIPEMD256.
==========
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: Jim Steuert <[EMAIL PROTECTED]>
Subject: Re: The DeCSS ruling
Date: Wed, 23 Aug 2000 13:37:31 -0400
Good Point. However, my point was that I (and I assume others as well)
learn a lot via curiosity, before I have any intent. Did Linus Torvalds
intend
to build Linux when he started to study Minix? It is only after
exercising
our curiousity that we might formulate some intent, malicious or
otherwise.
To presume that we are reverse-engineering software for the purpose of
some "illegal" intent "before" we actually reverse-engineer it is a very
serious presumption of guilt. In fact, this would stifle technology
everywhere.
How many s/w engineers at Nokia and elsewhere cut their teeth on ftp
sites
around the world. Their curiosity has fueled today's information age.
Copyright law should not forbid you to look at a painting, or study it,
or
write about it.
I'm still hoping that someone posts the DeCSS code to this newsgroup
(it's not very large), possibly in a "sanitized form without keys and
with
annotation", so that we can look at and understand the algorithms. If
that
is illegal then all those papers attacking various ciphers must be
illegal.
-Jim Steuert
"Douglas A. Gwyn" wrote:
> Jim Steuert wrote:
> > What about just plain curiosity? Can that be a legal reason for
> > reverse engineering?
>
> Should it be? Suppose you're curious what's in somebody's
> house -- should that be a legal excuse for entering without
> permission?
>
> Unfortunately this legal case seems to have involved both
> a possible intent to cause malicious mischief or abet
> criminal activity (theft), and the more intellectual issue
> of right to attack cryptosystems. One way to look at the
> latter is that the DVD vendors chose to use a difficult
> puzzle (CSS) as their primary means of protecting their
> rights to control use of their property. It's much like
> depending on a lock to keep people out of one's house --
> it keeps unskilled honest people out, but provides little
> protection against skilled people and career criminals.
> We use other means such as social and legal sanctions to
> address the latter.
------------------------------
From: Mike Rosing <[EMAIL PROTECTED]>
Subject: Re: Steganography vs. Security through Obscurity
Date: Wed, 23 Aug 2000 12:41:15 -0500
[EMAIL PROTECTED] wrote:
>
> 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?
True. The whole point of steganography is that you don't know a message
is there to be looked for. It doesn't have to be encrypted, but by doing
so you slow down your opponents quite a bit. Obscurity is a nice addition
to security, but not one to be relied on for any purpose.
Patience, persistence, truth,
Dr. mike
------------------------------
From: Mike Rosing <[EMAIL PROTECTED]>
Subject: Re: An interesting cryptographic problem
Date: Wed, 23 Aug 2000 12:37:25 -0500
[EMAIL PROTECTED] wrote:
[...]
>
> 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.
Can you trust the sys-admin on the database cpu? That person could apply
a secret key that's not stored in the program, every time the program starts.
Reduces the disgruntled employee problem to 1 person, but does not
eliminate it.
Another option is 2 layers of database. One layer is just for looking up
the login credentials which get forwarded to the real DB. As long as the
login store is on the same cpu as the database no outside user can get
thru it. This is really just a translator, but it wouldn't be fixed.
Patience, persistence, truth,
Dr. mike
------------------------------
From: Ichinin <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: The DeCSS ruling
Date: Wed, 23 Aug 2000 08:56:23 +0200
Pekka Ala-Mäyry wrote:
> So I dare to say that it is illegal also in Europe.
*EEEEEEEEE* wrong...
You seem to forget that EU "law" is only GUIDANCE, it is up
to EACH INDIVIDUAL STATE to IMPLEMENT that GUIDANCE in law.
Define reverse engineering?
This is cut from 1960:729 (Swedish copyright law)
"Den som har rätt att använda ett datorprogram får iaktta,
undersöka eller prova programmets funktion för att fastställa
de idéer och principer som ligger bakom programmets olika
detaljer. Detta gäller under förutsättning att det sker vid
sådan laddning, visning på skärm, körning, överföring eller
lagring av programmet som han har rätt att utföra."
My translation:
The one who have the right to use a computer program
is allowed to observe, explore or try the programs
functions to establish the ideas and princibles that
are behind the programs different details. This is, under
the condition that it is done under such loading, displaying
on screen, executing, transfering or storing, of the program
that he(*) have right to do.
(* Which excludes Females :o)
So if "Tinkering" with a compiled program is reverse
engineering, then it is legal.
Earlier paragraphs clearly states that:
"...göra sådana
ändringar i programmet som är nödvändiga för att han skall
kunna använda programmet för dess avsedda ändamål. Detta gäller
även rättelse av fel."
My translation:
...make such changes in the program that are necessary to allow
him (Again HIM??) to use the program for it's original purpose.
This also apply to correcting errors.
Further on...
"Återgivning av ett datorprograms kod eller översättning av
kodens form är tillåten om åtgärderna krävs för att få den
information som är nödvändig för att uppnå samverkansförmåga
mellan programmet och ett annat program."
My translation:
Recitiation of a computer programs code or TRANSLATION of the
form of the code is allowed if the actions are necessary to get
the information that is necessary to get interoperability
between the program and another program.
(Note: Norway is not a member of the EU, but Germany is,
the software was written in Germany IIRC. I now wonder if
this text exist in german law to. Anyone from .DE wish to
enlighten us ?)
What i love about Swedish law is the following statement that
pop up on SEVERAL occations in the copyright law:
"Avtalsvillkor som inskränker användarens rätt enligt denna
paragraf är ogiltiga."
My translation:
Terms that prohibit the users right according to this
paragraph is void.
So if i were to translate a purchased player to linux for
legitemate purposes (As in watching movies), the MPAA could
just kiss my butt. Period.
Glenn
Novice crypto dude,
Security researcher,
& Ex law student
On the right side of the pond (= .SE)
------------------------------
Date: Wed, 23 Aug 2000 12:20:23 -0600
From: Anonymous <[EMAIL PROTECTED]>
Subject: Re: The DeCSS ruling
You are speaking from a specific 'country' point of view. Here,
in Australia, we don't shoot people who come to our door, like in
Texas. If you came home and found someone in your house and they
said they stopped in for a drink of water, it might be very hard
to prosecute them for anything. Different case if they are carrying
out the telly as they
go.
Is it the same to post the source as to actually do the reverse-
engineering? That was not
done in America so is it another case of the United States exporting
its laws? What legal
action has occured in Norway?
You can infer malicious mischief but on the other hand people who
used Linux want to be able to play DVD's.
I've seen files called csscramble, scramble and unhash. Are these
the files in question.
In article <[EMAIL PROTECTED]>
"Douglas A. Gwyn" <[EMAIL PROTECTED]> wrote:
>
> Jim Steuert wrote:
> > What about just plain curiosity? Can that be a legal reason for
> > reverse engineering?
>
> Should it be? Suppose you're curious what's in somebody's
> house -- should that be a legal excuse for entering without
> permission?
>
> Unfortunately this legal case seems to have involved both
> a possible intent to cause malicious mischief or abet
> criminal activity (theft), and the more intellectual issue
> of right to attack cryptosystems. One way to look at the
> latter is that the DVD vendors chose to use a difficult
> puzzle (CSS) as their primary means of protecting their
> rights to control use of their property. It's much like
> depending on a lock to keep people out of one's house --
> it keeps unskilled honest people out, but provides little
> protection against skilled people and career criminals.
> We use other means such as social and legal sanctions to
> address the latter.
------------------------------
From: "Aztech" <[EMAIL PROTECTED]>
Subject: Re: Steganography vs. Security through Obscurity
Date: Wed, 23 Aug 2000 18:23:14 GMT
You can have the best of both worlds, i.e. encrypt the content with strong
crypto then using steganography embed the file within an image.
Even though strong crypto shouldn't have to be obscured, in some cases you
might not want it to be viewed at all, i.e. an oppressive government might
take an interest in the message and force you to decrypt it (RIP bill in the
UK?), whereas an image could probably pass by prying eyes without much
attention.
Andrew.
> 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.
------------------------------
From: "David C. Barber" <[EMAIL PROTECTED]>
Crossposted-To: comp.lang.c,alt.folklore.computers
Subject: Re: Bytes, octets, chars, and characters
Date: Wed, 23 Aug 2000 11:23:05 -0700
It's fun to hear these stories about hardware that predates my entry into
the field in 1970 (though my Dad worked for years prior to that for Daystrom
and Control Data Corp, and had stroies to tell).
Also to see the name Dennis Ritchie, which of course I recognise. :^)
*David Barber*
"Dennis Ritchie" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
>
>
> [EMAIL PROTECTED] wrote:
> ...
> > The I/O on Stretch was done in 8-bit bytes. The VFL instruction let you
> > access any byte up to 64 bits in length. There was an add-on processor
> > called Harvest that was limited to 8-bit bytes.
> >
> > Does anyone have a copy of either the 7030 manual, the book "Design of a
> > Computer System" or the procedings of the 1959 Eastern Joint Computer
> > Conference?
>
> Yes, yes, and no.
>
> Stretch was a very interesting project. It was in some ways
> utterly at odds with ISA architecture as it evolved in
> even the fairly-near future (e.g. the /360): it had
> a single 64-bit accumulator which in some contexts could
> be considered as 128 bits, a bunch of very fancy index
> registers, bit-addressible memory.
>
> At the same time, in many implementation details
> (the 8-bit byte and general 2^n bit datapath,
> peripherals and memory interface, OOO execution and instruction
> look-ahead) it was an effort that had far-reaching
> effects.
>
> Dennis
------------------------------
From: [EMAIL PROTECTED] (S. T. L.)
Subject: Re: Re-using CD-R discs
Date: 23 Aug 2000 18:28:41 GMT
<<I have no doubt that there is some temperature sufficiently
high to erase the CD-R.>>
14 billion degrees ought to do it, no?
"To erase, add one supernova"
-*---*-------
S.T.L. My Quotes Page * http://quote.cjb.net * leads to my NEW site.
My upgraded Book Reviews Page: * http://sciencebook.cjb.net *
Optimized pngcrush executable now on my Download page!
Long live pngcrush! :->
------------------------------
From: "Richard Bembridge" <[EMAIL PROTECTED]>
Subject: Re: The future direction ...
Date: Wed, 23 Aug 2000 19:45:45 +0100
I have been doing some research on Quantum Key Distribution, and there is a
surprising amount of literature already available. Do not, however, expect
to be able to walk into a book shop and pick up a "Idiot's Guid to Quantum
Cryptography" just yet!
Some places I found really useful were:
The Los Alamos National Laboratory pre-print archive (quantum physics)
http://xxx.lanl.gov/find/quant-ph
Elsevier Science (hold large archives of journals and reports)
http://www.elsevier.nl/
Infoworld (registration required)
http://www.infoworld.com/
For really exciting news on QKD, read about the work of Richard J. Hughes
and William T. Buttler, both of LANL, and also Paul D. Townsend, of the BT
Laboratory, United Kingdom.
Hughes and Buttler's work on free-space QKD might herald a new era in secure
global communication, without having to rely on fibre-optic cable. (What
will the US and UK governments think about that?)
Townsend's work demonstrated that QKD can be sustained within a regular
broadband fibre-optic link, with little distortion.
If anybody has any further comments to add to the links I gave, or more
specifically (and helpfully for me, as it happens!) to my thoughts on the
new developments I mentioned above, please carry this thread on.
Thanks for reading my reply. Hope it helps!
Rich
------------------------------
From: John Myre <[EMAIL PROTECTED]>
Subject: Re: Decryption
Date: Wed, 23 Aug 2000 12:38:18 -0600
kihdip wrote:
>
> John Savard has an example that shows that you go backwards through the
> computation to extract the plaintaxt from the ciphertext.
> This seems very logical.
And he is completely correct.
> But with the Feistel structure in a decryptation, it seems that you do the
> same computations as when you encrypt (except for using your keys
> backwards).
In the traditional Feistal form, that is correct.
> Why does this work ?? Why isn't it necessary to go through the
> function/s-boxes in the Feistel structure backwards when you decrypt ??
Indeed, you do have to go through cipher backwards to decrypt.
However, the Fiestal structure makes this easy.
> Has it something to do with the nature of the s-boxes/function inside the
> Feistel structure ??
No, and that is the trick.
Assume that the cipher has N rounds, or steps. Suppose that we are
keeping the data block in two halves, in the traditional way, which
we name L (left) and R (right). Then step i of encryption is like
this:
F := ugly_function_#i (R, key(i))
L := L xor F
Here "ugly_function_#i" means whatever s-boxes and other stuff
constitute your computation at step i. To invert the step
above - do the same thing! That is, compute F in the same
way (not backwards), so you can undo the xor by doing another
xor. An important point here is that the step leaves R
unchanged - so that it can be used to restore L. F is just
a temporary variable for the step.
So, if you use different keys at each step, or different s-boxes,
or different functions, you have to go through all that in the
reverse order. But at each step, you compute the same s-boxes
and functions, not their inverses.
There is nothing cryptographically magical about xor; it is
just convenient because it is its own inverse. You could add
for encryption (L + F) and subtract for decryption (L - F),
for example, if you would rather.
The other facet of the Feistal structure is the swapping of
halves. You swap halves after every step during encryption.
Therefore you should swap halves *before* every step to do
decryption. However, we have another trick up our sleeve. We
simply omit the last swap for encryption; this means that
actually we swap *between* steps, and then we can do the same
thing for decryption. That is, we omit the swap after the
last encryption round, which means we have to omit the swap
before the first decryption round, and now both encryption and
decryption have swaps in the same place: in between steps.
The most traditional way to do this is to use the same
s-boxes and functions at every step. Then, as you said,
the only difference between encryption and decryption is
the order of using the key bits.
JM
------------------------------
** 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
******************************
