Cryptography-Digest Digest #39, Volume #10 Fri, 13 Aug 99 11:13:05 EDT
Contents:
Please help a HS student with an independent study in crypto ("Jeff Moser")
Re: language confusion, would it work? (wtshaw)
Re: About Algorithm M (Jerry Coffin)
Re: About Algorithm M (Jim Gillogly)
Re: Journal of huffman coding (Andras Erdei)
Newbie Question - Do you need to have the message when you have a digest? ("Andrew
Rutherford")
Re: Infallible authentication scheme (Jerry Coffin)
Re: Why does MS-Visual C++ ABSOLUTELY REQUIRE . . . ("Michael VanLoon")
Re: NIST AES FInalists are.... (Robert Harley)
Re: NIST AES FInalists are.... (Volker Hetzer)
Re: NIST AES FInalists are.... (Volker Hetzer)
Digital simulation (Christy Fulcher)
Digital simulation (Christy Fulcher)
Digital simulation (Christy Fulcher)
Re: CFB mode with same initialization vector ([EMAIL PROTECTED])
Smart card generating RSA keys (Cuykens Anthony)
Re: Journal of huffman coding (Jim Felling)
Re: Depth of Two ("Douglas A. Gwyn")
Re: NIST AES FInalists are.... ("Douglas A. Gwyn")
Re: NIST AES FInalists are.... ("Douglas A. Gwyn")
Re: Future Cryptology ("Douglas A. Gwyn")
Re: Newbie Question - Do you need to have the message when you have a (Jim Felling)
Re: Future Cryptology ([EMAIL PROTECTED])
Re: NIST AES FInalists are.... (Rochus Wessels)
Re: Aris/Solana audio watermarking ("Fabien A. P. Petitcolas")
Re: Digital simulation (David Kessner)
----------------------------------------------------------------------------
From: "Jeff Moser" <[EMAIL PROTECTED]>
Subject: Please help a HS student with an independent study in crypto
Date: Fri, 13 Aug 1999 00:18:41 -0500
Dear sci.crypt,
I'm entering my senior year of high school. I had a hole in my schedule and
I choose to fill it with an independent study in abstract algebra with
emphasis on cryptography. I have read (and own) Applied Cryptography and I
have Handbook to Applied Cryptography (downloaded from their site). Right
now, I have a good understanding of "how" things work in crypto. (How [RSA,
ElGammal, DH, etc] works, How [DES, RCx, AES submissions, etc] works, How
signatures work, MAC/Hash, etc). What I want to focus on in the course is
"Why" it works. I'd like to be able to write out proofs for why the methods
work. I'd like to be able to, for example, show the mathematics of why the
public key systems work [in depth of Euler Totient/Phi, Galois fields, other
fields, etc]. I became really interested in cryptography over a year ago and
after studying it as a hobby, I'm incredibly amazed by the subject and love
it. I know there are people who've been in the field longer than I've been
alive and that amazes me. I know there are many thing to learn about the
subject. My main question to the group is this: are there any professors,
students of crypto classes, other enthusiasts, etc, who could help me in
forming an itinerary of important things that I should focus on in the time
I have during the year? The class time will be (45 mins/day) for 180 school
days. The main reason that I'm asking the group is that the teachers here at
my school were not aware of what cryptography was. I was able to get two
teachers to help me because they took abstract algebra courses in college.
They'd be familiar with the fields, groups, rings, ham. cycles, etc. If
anyone in sci.crypt can help me out, I'd be extremely grateful and in debt
to them.
Many thanks in advance,
Jeff Moser
PS. My heart goes out to the people of
http://www.cacr.math.uwaterloo.ca/hac/.
They have helped out this HS student immensely in obtaining important
things when I
otherwise couldn't obtain them. Hopefully, I'll be able to buy the
book soon.
to reply, remove 'nospamplease' from my address
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: language confusion, would it work?
Date: Thu, 12 Aug 1999 22:30:36 -0600
In article <[EMAIL PROTECTED]>, Mike Orceyre <[EMAIL PROTECTED]> wrote:
> I'm sure the concept is extensible along many lines.
> No key(s) needed if you're polyglot :-)
>
While some of my pursuits may not appear relevant, it is exactly in this
area that my base translation practices are applicable, particularily if
one language uses a different sized alphabet than the other.
Let's say that you have plaintext in Swedish, which according to a recent
thread uses 29 characters, ciphertext in English, with 26 characters, at
least three less characters per set. You probably would include some or
many other characters common to both sets, so you probably would not be
going straight from 29 to 26, perhaps something easy like 38 to 34 via
trits or, the other way, 35 to 39, also via trits. There are many
alternatives to any particular situation. I quickly see also 27 to 32 via
doits, and 41 to 33, also via doits.
This is a powerful but concise technology which can be incorporated into
more extensive cryptosystems with the result of making omnipotent
polyglots become quickly speechless.
--
Sometimes you have to punt, and hope for the best.
------------------------------
From: [EMAIL PROTECTED] (Jerry Coffin)
Subject: Re: About Algorithm M
Date: Thu, 12 Aug 1999 23:47:03 -0600
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] says...
> [EMAIL PROTECTED] wrote:
> > 1) I know Algorithm M is simple to describe but ...
>
> Maybe you should describe it, then. Are we supposed to know what
> you mean by "Algorithm M"? It's not a standard term.
I can only guess, but my guess would be that it's the Algorithm M from
Knuth, V2 (page 32).
------------------------------
From: Jim Gillogly <[EMAIL PROTECTED]>
Subject: Re: About Algorithm M
Date: Thu, 12 Aug 1999 21:29:13 -0700
[EMAIL PROTECTED] wrote:
> A few hints, even, about what Algorithm M is like, an example of a book or
> other place where the term is used, would have been immesurably helpful.
I imagine he's referring to Knuth, vol. 2, in which case Jim Reeds' paper
in the first issue of Cryptologia (vol 1 #1) should be applicable.
--
Jim Gillogly
21 Wedmath S.R. 1999, 04:28
12.19.6.7.19, 11 Cauac 7 Yaxkin, Sixth Lord of Night
------------------------------
From: [EMAIL PROTECTED] (Andras Erdei)
Crossposted-To: comp.compression
Subject: Re: Journal of huffman coding
Date: Fri, 13 Aug 1999 06:39:08 GMT
[I'm crossposting it to sci.crypt as i don't know much
about cryptography -- hope the guys there can correct me
(and you).]
[EMAIL PROTECTED] wrote:
> [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY) wrote:
>> I have several examples at my site. But the big advantage
>> of adaptive huffman compression over stataic is that the
>> static is not as useful for encryption and for small files
>> the file is longer with static due to the fact the static
>> compression table has to be sent with the file. For example
>> my method will compress some files as short as 3 bytes to a
>> 2 byte replacement. Try that with static huffman.
> Compression itself does not increase security.
AFAIK it increases security by hiding the statistical
properties of the plaintext -- the compressed plaintext
usually has much higher entropy so it is much harder
to guess on parts of it (and check if the guess was right).
> Adaptive methods also are bad since the 'dictionary'
> is based on the plaintext.
AFAIK on the contrary; when using adaptive compression
for encryption purposes one usually starts with an initial
dictionary derived from an encryption key which is
impossible (?) with a static method without seriously
degrading the compression ratio and thus reducing the
benefits of compression. Also, with a static method it
is much easier to check whether guesses on parts of the
plaintext are right.
> The only benefit of compression is to make the messages
> shorter.
Which is a great benefit: the less the data the harder to
break it; you can use more time consuming methods (larger
keys) because you have to en/decrypt less text, or on the
contrary (smaller keys in your OTP -- AFAIK that was the
cause of the initial interest in data compression).
> That's all.
Is that all?
TIA
Andras Erdei
[EMAIL PROTECTED]
------------------------------
From: "Andrew Rutherford" <[EMAIL PROTECTED]>
Subject: Newbie Question - Do you need to have the message when you have a digest?
Date: Thu, 12 Aug 1999 08:49:21 -0400
I want to be able to create a fixed length key or digest for a particualr
document of any size, and send this created digest to a recipient who will
be able to recreate EXACTLY the same message from this digest alone. I've
put this question on the compression groups, but no answer, so I thought I'd
try here.
There's a free virtual beer in it for anyone who helps!!
Cheers
Andy
[EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (Jerry Coffin)
Subject: Re: Infallible authentication scheme
Date: Sat, 7 Aug 1999 15:29:59 -0600
In article
<[EMAIL PROTECTED]>,
[EMAIL PROTECTED] says...
[ ... ]
> I'm assuming that SHA1 has similar characteristics, except maybe being
> faster than MD5 (?).
SHA-1 has roughly similar characteristics as MD5 -- both were
consciously based on MD4. Which is faster appears to depend on the
hardware involved.
------------------------------
From: "Michael VanLoon" <[EMAIL PROTECTED]>
Crossposted-To: comp.lang.c++
Subject: Re: Why does MS-Visual C++ ABSOLUTELY REQUIRE . . .
Date: Thu, 12 Aug 1999 13:10:30 -0700
Pete Becker <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Paul Lutus wrote:
> >
> > Non sequitur.
>
> Not at all. See below.
>
> > Only MSIE can reside within MSDev as a component. I discovered
> > the same thing in my program Arachnophilia, to my dismay. :)
> >
>
> That's a completely different statement from "They are in HTML. This
> requires MSIE." The latter is false: many other tools can handle HTML.
> By adding a requirement that such tools also must run as components
> within MSDev you've changed the foundation of the argument. Don't
claim
> that anyone else's logic is faulty when you've omitted important
> details.
DevStudio is not written to use those other tools. This should be
obvious. If you want to argue semantics, you are correct. If you want
to actually answer the question, you have to consider the context.
------------------------------
From: Robert Harley <[EMAIL PROTECTED]>
Subject: Re: NIST AES FInalists are....
Date: 13 Aug 1999 13:06:11 +0200
[EMAIL PROTECTED] writes:
> [...] the most
> simple AES finalist is probably RC6, followed by Rijndael. In fact, my
> guess is that unless some theoretical flaw is discovered in them during
> the next 12 months or so, these two will be the AES winners.
What? And have Joan Daemen and Vincent Rijmen set up a company in
Belgium whose arm the NSA can't twist? I would be surprised.
Bye,
Rob.
------------------------------
From: Volker Hetzer <[EMAIL PROTECTED]>
Subject: Re: NIST AES FInalists are....
Date: Fri, 13 Aug 1999 13:25:17 +0200
SCOTT19U.ZIP_GUY wrote:
>
> In article <[EMAIL PROTECTED]>, "Douglas A. Gwyn" <[EMAIL PROTECTED]> wrote:
> >"SCOTT19U.ZIP_GUY" wrote:
> >> Rest assured that if there was an entry that the NSA felt to strong
> >> for it to attack it would never be allowed to see the light of day
> >> in the AES game.
> >
> >What mechanism could possible accomplish that? The AES candidates
> >are very public.
>
> First of all no real secure system would get past the AES entries.
Why not? At the time the 15 contenders were announced, nobody (especially no author)
complained. Therefore, everybody who submitted an algorithm was happy with the choice.
> IF it is
> not written in there special format.
Are you still going on about this esoteric and seldom used new fangled postscript
thingy
the NSA choose especially to annoy you?
> The NSA would most likely toss those out
> before public review.
How would they have accomplished this?
> However if one slipped in they still would infulence the
> outcome to convience people that it is weak.
Again, how? Remember, everybody is listening. So, as long as the people you trust
understand and accept the criticism, its okay.
> If the contest was for real I
> think various contests should have been held. Like how hard is it to break
> reduced forms. These contest should be open and public.
Go on, break a reduced form and announce it. That IS public. No problem here.
> Not just some BS
> from a phony crypto god.
Compare the papers and NIST's paper and you will find that NIST followed those papers
closely.
> When things are not done with real world tests the
> good ole boys will pat them selves on there backs and only they will win.
> There should be real world contests.
Could you please define "real world contest"? Is it about offering some hundred bucks
to break next centuries encryption when the guy who did it could cash in billions
later?
> And since the idea is for security any
> idiot should be able to see that different methods are required for file
> protection and smart card stuff.
Then again tere are those idions who equal method an algorithm and who don't know
that ano almost every smartcard there IS a file system.
> The only possible reason to use the same
> method for everyting is to limit the size of the program.
And to concentrate analysis on one algorithm.
> All else aside it is
> highly unlikely that a low memory fast encryption program is good for all
> aplications.
Could you please give us examples where a high memory slow encryption program
would be advantageus?
> We don't use Nuclear fuel in are cars but there is place for
> all types of fuel.
I don't understand what this sentence has to do with this article.
> The only possible reason to go to a high speed low memory
> method for all methods is so that it will be easy to break.
What is the connection?
You can put a lot of complexity into a fast and low memory cipher.
What should count more is simplicity. The simper the cipher the easier to
analyze. therefore less chance of beeing fooled by someone.
> But if the
> government is able to con the Europeans into beliving the NSA is there
> friend I guess they deserve to have there mail read and maybe we can
> steal there business secrets for our own use.
Remember, IDEA is swiss.
Greetings!
Volker
--
Hi! I'm a signature virus! Copy me into your signature file to help me spread!
------------------------------
From: Volker Hetzer <[EMAIL PROTECTED]>
Subject: Re: NIST AES FInalists are....
Date: Fri, 13 Aug 1999 13:29:43 +0200
SCOTT19U.ZIP_GUY wrote:
>
> In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Bruce
>Schneier) wrote:
> >On Tue, 10 Aug 1999 01:30:21 GMT, "Douglas A. Gwyn" <[EMAIL PROTECTED]>
> >wrote:
> >I believe the NSA is already analyzing the AES submissions, but I
> >don't believe that "we" will ever get the results of that analysis.
> >
> >Bruce
>
> This alone is one reason overseas companys would be foolish to
> use any of the AES candidates. The NSA will not doubt design special
> hardware just for the decoding of messages that overseas companies
> are dumb enough to use one of the AES methods.
You have done better postings.
Tell me about the special hardware that can crack a 128 bit block cipher.
Btw, I don't know how your government does this, but in east germany we simply
bought out the cleaning lady of the company we would spy on. Much cheaper
than your beloved "special hardware".
Greetings!
Volker
--
Hi! I'm a signature virus! Copy me into your signature file to help me spread!
------------------------------
From: Christy Fulcher <[EMAIL PROTECTED]>
Subject: Digital simulation
Date: Fri, 13 Aug 1999 13:07:03 +1000
Im am looking for a way to simulate an encrytption algorithm in
electronic workbench
(or similar), for a project in electronics. My knowledge so far consists
of simple
circuits like and, not, xor etc. Could anyone help me in suggesting an
algorithm that can
be implemented using these tools.
Any help would be much appreciated.
------------------------------
From: Christy Fulcher <[EMAIL PROTECTED]>
Subject: Digital simulation
Date: Fri, 13 Aug 1999 13:13:10 +1000
Im am looking for a way to simulate an encryption algorithm in
electronic workbench
(or similar), for a project in electronics. My knowledge so far consists
of simple
circuits like and, not, xor etc. Could anyone help me in suggesting an
algorithm that can
be implemented using these tools.
Any help would be much appreciated.
------------------------------
From: Christy Fulcher <[EMAIL PROTECTED]>
Subject: Digital simulation
Date: Fri, 13 Aug 1999 13:16:43 +1000
Im am looking for a way to simulate an encryption algorithm in
Electronic Workbench
(or similar), for a project in electronics. My knowledge so far consists
of simple
circuits like and, not, xor etc. Could anyone help me in suggesting an
algorithm that can
be implemented using these tools.
Any help would be much appreciated.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: CFB mode with same initialization vector
Date: Fri, 06 Aug 1999 10:45:17 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (John Savard) wrote:
> [EMAIL PROTECTED] (Daniel Vogelheim) wrote, in
> part:
>
> >why is encryption in CFB mode insecure, if you use the same
> >initialization vector multiple times?
>
> Well, CFB mode takes the IV, encrypts it, and XORs it with the first
> block of your message.
>
> So, if you use the same initialization vector multiple times, you are
> sending multiple messages - which may have different beginnings - with
> the same thing XORed to their first blocks. This is like using a
> one-time pad twice, and can be solved by the same method, without
> having to break the DES (or other block cipher) encryption at all.
>
> John Savard ( teneerf<- )
> http://www.ecn.ab.ca/~jsavard/crypto.htm
>
In my TINY series of programs (TINYRC, TINYRIJN,
TINYSAFR and (soon) TINYSERP I have addressed this
problem by moving the filename from the DTA and putting
in (in caps) into the IV. So unless the file names are
the same, the IVs will be different.
--
Robert G. Durnal
Web pages at www.afn.org/~afn21533
and members.tripod.com/~afn21533
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: Cuykens Anthony <[EMAIL PROTECTED]>
Subject: Smart card generating RSA keys
Date: Fri, 13 Aug 1999 14:15:05 +0000
Hi there,
Does anybody have an idea on how long could need a smart card to
generate an RSA key pair ? (if it is possible)
Thanks for reading,
@nthony.
------------------------------
From: Jim Felling <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Crossposted-To: comp.compression
Subject: Re: Journal of huffman coding
Date: Fri, 13 Aug 1999 09:22:51 -0500
Andras Erdei wrote:
> [I'm crossposting it to sci.crypt as i don't know much
> about cryptography -- hope the guys there can correct me
> (and you).]
>
> [EMAIL PROTECTED] wrote:
>
> > [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY) wrote:
>
> >> I have several examples at my site. But the big advantage
> >> of adaptive huffman compression over stataic is that the
> >> static is not as useful for encryption and for small files
> >> the file is longer with static due to the fact the static
> >> compression table has to be sent with the file. For example
> >> my method will compress some files as short as 3 bytes to a
> >> 2 byte replacement. Try that with static huffman.
>
> > Compression itself does not increase security.
>
> AFAIK it increases security by hiding the statistical
> properties of the plaintext -- the compressed plaintext
> usually has much higher entropy so it is much harder
> to guess on parts of it (and check if the guess was right).
Agreed, assuming that it does not have some form of overhead
data/headers/characteristic pattern usable as a crib. Also in the case
of known plaintext attacks, unless the compression is keyed in some way,
the compression will change nothing.
All compression really does for security is (on average) reduce the
amount of data sent, thereby giving the Opponent less material to
analyze -- a deffinite good thing, but not inherently security
enhancing.
>
>
> > Adaptive methods also are bad since the 'dictionary'
> > is based on the plaintext.
>
> AFAIK on the contrary; when using adaptive compression
> for encryption purposes one usually starts with an initial
> dictionary derived from an encryption key which is
> impossible (?) with a static method without seriously
> degrading the compression ratio and thus reducing the
> benefits of compression. Also, with a static method it
> is much easier to check whether guesses on parts of the
> plaintext are right.
>
Such a keyed dynamic method will be less efficient on average, and will
for longer files eventually converge to a dictionary close to that which
would have been used in the case of an unkeyed dictionary. Agreed this
CAN add security to the data, but an unkeyed method may actually yeild
better results as less data will be sent. I would be inclined more to
rely upon the encypherment algorithim to provide security, than the
compression. I do however agree a dynamic compression, will yeild
better results than a static algorithim, and therefore is better to use.
>
> > The only benefit of compression is to make the messages
> > shorter.
>
> Which is a great benefit: the less the data the harder to
> break it; you can use more time consuming methods (larger
> keys) because you have to en/decrypt less text, or on the
> contrary (smaller keys in your OTP -- AFAIK that was the
> cause of the initial interest in data compression).
>
> > That's all.
>
> Is that all?
>
> TIA
>
> Andras Erdei
> [EMAIL PROTECTED]
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Depth of Two
Date: Fri, 13 Aug 1999 13:39:59 GMT
The example messages use reciprocal alphabets and have a period of 4,
as can be determined from the patent repeats. Solution involves
chaining and an observation about chaining of reciprocal alphabets.
In case it isn't well known, Enigma and Hagelin alphabets are both
reciprocal.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: NIST AES FInalists are....
Date: Fri, 13 Aug 1999 13:49:32 GMT
[EMAIL PROTECTED] wrote:
> Then what you expect is false, since a number of the
> candidates were excluded for security flaws.
I didn't say that they might not also "rate" similar systems
with a low score. That is irrelevant to the point I was
making, which is that their high "rating" is commensurate
with their stage of knowledge, and not indicative of the
actual security of the systems.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: NIST AES FInalists are....
Date: Fri, 13 Aug 1999 13:57:23 GMT
[EMAIL PROTECTED] wrote:
> How convenient for you that the rules allow you
> to flaunt how much you know on Usenet and to
> belittle the skill of respected cryptologists ...
I'm not flaunting anything, just trying to be helpful
in advancing the public state of cryptology compatibly
with my obligation to protect legitimate national
interests. My personal agenda is to ensure as soon as
possible that everybody can have adequate protection
for the privacy of their communications. It's not my
fault if you think the state of the art is defined by
academics rather than by actual practitioners. Other
posters have shown a better understanding of this issue.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Future Cryptology
Date: Fri, 13 Aug 1999 13:42:01 GMT
"SCOTT19U.ZIP_GUY" wrote:
> There actuall charter is classifed
No, it isn't.
> The total amount of there resources is classifed
Not long ago I posted a very close estimate,
but that's not my only source of information on the resources.
------------------------------
From: Jim Felling <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Newbie Question - Do you need to have the message when you have a
Date: Fri, 13 Aug 1999 09:36:32 -0500
Cannot be done. The reason is as follows
Assume your digest is F bits in length.
Then you can send 2^F possible digests.
If your message is N bits in length, and N>F you run into trouble because there
are 2^N possible messages of length N that could be sent, and 2^N>>2^F.
As an example I will set up a simple example let F=1, and N=2
We can send 2 possible digests 0, or 1
We have 4 possible messages 0,1,2,or 3.
Assume we recieve a digest D
and we can recreate our message M unabmiguously. in otherwords Digest(M)=D, and
for all N != M
Digest(N) != D.
assume now that we recieve the digest C=(1-D) by the above we do not have a
unique interpretation of C as for all N !=M digest(N)=C.
Andrew Rutherford wrote:
> I want to be able to create a fixed length key or digest for a particualr
> document of any size, and send this created digest to a recipient who will
> be able to recreate EXACTLY the same message from this digest alone. I've
> put this question on the compression groups, but no answer, so I thought I'd
> try here.
>
> There's a free virtual beer in it for anyone who helps!!
>
> Cheers
>
> Andy
> [EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Future Cryptology
Date: Fri, 13 Aug 1999 10:35:18 -0400
David A Molnar wrote:
> With all due respect, the reports on Echelon suggest that "they" are out
> to get all of us, with some minimal level of effort. I'd want to know more
> about just what you're handing in your white hat hacking before
> speculating fruitlessly on just how much more effort the NSA is expending
> on you. :->
...
> Seen any strange vans on your kerb lately ?
Funny you should ask that...there was a Bellsouth van sitting across my street a
few weeks ago. It sat their for 2 days. I was freaking out...but then I found
out there was no one in it, it just broke down. (Too bad I didn't raid it. =)
------------------------------
From: Rochus Wessels <[EMAIL PROTECTED]>
Subject: Re: NIST AES FInalists are....
Date: 13 Aug 1999 16:37:09 +0200
[EMAIL PROTECTED] writes:
> presentation at the conference. A cipher will fail to
> rate for even a hint of weakness, like the impractical
> weak-key attack on Frog.
The Attack on Frog may be practical for some protocols.
Imagine a protocol which uses SESSION-Keys in a similar way like SKIP
uses packet-keys:
{Kp}Kijn,{M}Kp ({M}K is M encyrpted with key K)
Kijn ist the Master-Key, which is used for 1 hour and valid for 2 hours,
Kp is the packet-key (or, in the hypothetical protocol, the session key)
On a fast (100 MBit) network 2^30 packets could be send in 1 hour,
so there is a high probability to use a weak key
(the adversary starts a new session, until a weak key is used).
Now, IF it is possible to distinguish fast, whether a
weak key is used, the adversary could continue to send more
chosen plaintexts in this session (SKIP would use other keys for the
next packets, so this attack doesn't work on SKIP), if integrity
isn't checked (or checked badly) even chosen ciphertexts
(for example, the adversary could start a session which doesn't
recquire authentication, just encryption (*I know* that this is no good
idea for legitimate uses :-)).
To do the 2^56.7 work and acquire the 2^36 chosen ciphertexts in one hour
isn't very far out of reach, a faster (8 GBit) network would be enough
for the latter and 2^56 work can be done in 24 hours already.
Result: The adversary gets a valid pair ({Kp}Kijn, Kp).
If Kp is used for encryption AND authentication, you are in trouble.
------------------------------
From: "Fabien A. P. Petitcolas" <[EMAIL PROTECTED]>
Subject: Re: Aris/Solana audio watermarking
Date: Fri, 13 Aug 1999 14:29:41 +0100
Reply-To: "Fabien A. P. Petitcolas" <[EMAIL PROTECTED]>
> Musicode, an audio watermarking technique by Aris Technology, has
been
> selected by SDMI. According to the company, it is also considered
for
No demo software. Obscure patents. Yet another "security through
obscurity". How long before the system is broken? Actually, I wonder
whether their system will survive some attacks we have already
proposed on audio watermarking ;-)
See:
http://www.cl.cam.ac.uk/~fapp2/papers/ieeemm99-evaluation/
http://www.cl.cam.ac.uk/~fapp2/papers/ih98-attacks/
Fabien.
------------------------------
From: David Kessner <[EMAIL PROTECTED]>
Subject: Re: Digital simulation
Date: Fri, 13 Aug 1999 08:50:42 -0600
Reply-To: [EMAIL PROTECTED]
Christy Fulcher wrote:
> Im am looking for a way to simulate an encrytption algorithm in
> electronic workbench
> (or similar), for a project in electronics. My knowledge so far consists
> of simple
> circuits like and, not, xor etc. Could anyone help me in suggesting an
> algorithm that can
> be implemented using these tools.
>
> Any help would be much appreciated.
Simulating something like an encryption algorithm in electronics
workbench would be a difficult and trying experience. It's my opinion
that you shouldn't try.
What you should try is to do your design in VHDL and simulate
it using a VHDL simulator like ModelSIM from Model Technology.
Beware, however, that this is an expensive piece of software but
your school should have a copy available for student use.
Look at my web site at http://www.free-ip.com. There is a
DES encryption engine there in VHDL. Sadly, you live "down under"
and I live in the US where our government is, um, well, um, stupid.
This means that you can't download the VHDL source code from
the web site. But there is still some potentially useful information
on the web site.
David Kessner
[EMAIL PROTECTED]
http://www.free-ip.com
------------------------------
** 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
******************************
