Cryptography-Digest Digest #23, Volume #11 Mon, 31 Jan 00 12:13:01 EST
Contents:
Re: NIST, AES at RSA conference (Terry Ritter)
Re: DVD: CSS comments?? (Terje Mathisen)
Re: Court cases on DVD hacking is a problem for all of us (Troed)
Re: How to password protect files on distribution CD (Johnny Bravo)
Re: Wireless PKI now or later ("Lassi Hippel�inen")
Re: How to annoy the NSA & break almost any code (Tom St Denis)
Re: How much does it cost to share knowledge? ("Lassi Hippel�inen")
is key escrow still current topic? (Bastian Hecht)
Re: KEA gains something with RSA instead of D-H (John Savard)
Re: How to Annoy the NSA (John Savard)
Re: IDEA (Marc Koch)
Re: A question about odd grilles (Mok-Kong Shen)
Re: A question about odd grilles (Mok-Kong Shen)
Voynich manuscript (JCA)
Re: Pencil & paper cipher question ("Tony T. Warnock")
Re: Intel 810 chipset Random Number Generator ("Trevor Jackson, III")
Re: Intel 810 chipset Random Number Generator ("Trevor Jackson, III")
Re: Java's RSA implimentation (Shawn Willden)
Re: Blowfish Question (Shawn Willden)
Re: Simple Equivalent keys in Serpent (Shawn Willden)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: NIST, AES at RSA conference
Date: Mon, 31 Jan 2000 11:01:22 GMT
On 30 Jan 2000 19:49:05 -0800, in
<8730nh$m4a$[EMAIL PROTECTED]>, in sci.crypt
[EMAIL PROTECTED] (David Wagner) wrote:
>Your post still doesn't address Brian Olson's elegant one-line refutation:
> ``If all unprovable ciphers must be tripled, then we
> must triple our triples of triples with no end.''
The statement is neither elegant nor refutation: Since I have never
claimed that "all unprovable ciphers must be tripled," the apparent
response is no response at all; it is instead the introduction of a
"red herring." It is a deliberate attempt to mislead the reader about
my position and somehow "win" the argument. It is but one example of
why I no longer participate in discussions with that author.
>The only way out of this conundrum (as far as I can tell) is to admit
>that not all unprovable ciphers must be tripled -- and thus to admit
>that we have some other implicit figure of merit in mind.
There *is* no conundrum, unless *you* have decided to get provable
security by tripling ciphers. If that is your position, that may be
why you address it here, but if not, one wonders why it is being
directed toward me. I certainly do not agree with it.
>IMHO, this makes it abundantly clear that provable security cannot
>serve as sole justification for multiple ciphering.
I suppose that depends on exactly what you mean by "provable
security."
It is correct that there is no proof of strength. Multiple ciphering
does not provide such a proof. Indeed I expect that no such proof is
possible.
But it is also correct that multiple ciphering is provably strong*er*
in the sense of not allowing known-plaintext and defined-plaintext
attacks on individual ciphers. Partitioning plaintext so that it can
be protected by different ciphers is also provably *less* risky in the
sense that breaking one cipher exposes only that partition and not all
plaintext. These are provable advantages which disappear only when we
assume that breaking multiple ciphers has exactly the same cost as
breaking one.
>It seems that
>the lack of provable security is a red herring that really says nothing
>about whether multiple ciphering is preferred over single ciphering.
Correct, but it was not *my* red herring; that would be the invention
of the other author. Quoting from my previous message:
>>I claim that we have *no* *choice* but to accept a system with
>>unquantifiable security. We have *no* *choice* but to use systems
>>which we cannot trust, and upon which we cannot rely.
>>
>>We are in an unsavory position, and the only thing we *can* do
>>is to try to improve our odds:
Note the word "try" in that last sentence, and contrast that with
(your phrase) "provable security."
>A more moderate stance would be to argue that `diversity increases the
>odds of security, but is no guarantee' -- but that doesn't seem to be
>the argument you are making.
Then you haven't been reading. Again quoting from my previous
message:
>>We can try to improve our odds by requiring opponents to do
>>more than one thing. Breaking a cipher is one thing. Breaking
>>three ciphers is most likely three things -- unless of course
>>we return to the "cryptographer's stone" myth again, in which
>>case all of this is pointless.
>>
>>We can reduce the consequences of single-point failure by sending
>>part of our data under one cipher, part under another, and so on,
>>and especially not allowing most of society to use the same cipher.
Note the words "improve our odds," as opposed to, say, "create
unbreakable systems." Note the words "reduce the consequences" as
opposed to, say, "absolutely prevent."
And this is hardly "a more moderate stance." Instead, it is reality,
which means that I do not have the luxury of adjusting it to your
particular vision of acceptability.
>Anyway, one would still need to support
>this position with evidence that diversity is more cost-effective than
>other means at our disposal.
Hardly. What is needed is to show that the currently-accepted
approach -- having some sort of "contest" and then claiming some small
number of ciphers are secure enough to use -- is more risky in various
ways than using multiple ciphers.
It is clear, for example, that in the contest between cryptographer
and opponent, it is far more cost-effective to make and use new
ciphers than it is for opposing cryptanalysts to keep up and break
those ciphers. Indeed, this is probably the only tool we have that
can strike at the resources of our unknown opponents.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
From: Terje Mathisen <[EMAIL PROTECTED]>
Subject: Re: DVD: CSS comments??
Date: Mon, 31 Jan 2000 12:14:33 +0100
Sandy Harris wrote:
>
> [EMAIL PROTECTED] (Terje Mathisen) spake thus:
>
> >A games programmer (Frank Stephenson???) from Funcom here in Oslo,
> >Norway have published a cryptanalysis of CSS, which I've read.
>
> Is that available on the web or for FTP? I'd like to look at it.
>
> More important, do the defense in the DeCSS case have it?
Almost certainly, I found it just a few clicks away from one of the
original DeCSS posts to Slashdot.
Sorry, I didn't bookmark it.
Terje
--
- <[EMAIL PROTECTED]>
Using self-discipline, see http://www.eiffel.com/discipline
"almost all programming can be viewed as an exercise in caching"
------------------------------
From: [EMAIL PROTECTED] (Troed)
Subject: Re: Court cases on DVD hacking is a problem for all of us
Reply-To: [EMAIL PROTECTED]
Date: Mon, 31 Jan 2000 11:28:45 GMT
[EMAIL PROTECTED] (Terje Elde) wrote:
>V pbhyq fhttrfg gung crbcyr fubhyq qhcyvpngr uvf jbex, naq cbfg vg
>nabalzbhfyl gb gel gb qenj fbzr urng njnl, gub fhttrfgvat gung jbhyq
>cebonoyl or vyyrtny nf jryy.
Unf nyernql orra qbar, gubhfnaqf bs gvzrf, naq gur ZCNN unf tbar gb
pbheg va gur HF gb znxr ubfgvat gur QrPFF fbheprpbqr, be rira yvaxvat
(!) gb vg, vyyrtny.
Cyrnfr envfr lbhe ibvpr va nal jnl lbh pna - gur ZCNN ner ba gur iretr
gb qb fbzrguvat irel onq gb n ybg bs crbcyr.
___/
_/
------------------------------
From: Johnny Bravo <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp,comp.security.unix,comp.security
Subject: Re: How to password protect files on distribution CD
Date: Mon, 31 Jan 2000 06:30:15 +0000
On Sun, 30 Jan 2000 23:37:14 -0700, "Bill \"Houdini\" Weiss"
<[EMAIL PROTECTED]> wrote:
>I've wondered recently, what is the cost of some decent-speed DES
>hardware? Because, one would make a hell of a dongle. Have the
>program call the hardware to do vital parts of the code, and make the
>hardware fast enough that the calls can be big enough to make the
>program really fucking cumbersome to use without it.
Unless your software does DES encryption, what would DES chips have to
do with the software?
Best Wishes,
Johnny Bravo
------------------------------
From: "Lassi Hippel�inen" <"lahippel$does-not-eat-canned-food"@ieee.org>
Subject: Re: Wireless PKI now or later
Date: Mon, 31 Jan 2000 12:07:25 GMT
AFAIK, the WAP developers are thinking seriously about PKI. They are not
reinventing the wheel. There just are so many possibilities in the
market that a recommendation about the working "WAP-PKI" configuration
is necessary.
The WAP Forum has also operators as members. They are not happy with
just specifications, they want systems that run.
-- Lassi
Lyal Collins wrote:
>
> Same issues
> - wap uses wireless transmission means
> - PKI is PKI
>
> Lyal
>
> Drew Cutter wrote in message <[EMAIL PROTECTED]>...
> >What about PKI with WAP ?
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: How to annoy the NSA & break almost any code
Date: Mon, 31 Jan 2000 12:13:11 GMT
In article <8738rg$unb$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> You can probably annoy the NSA by spreading
> this news. Soon, if not already, it will be
> possible to build a quantum computer that can
> solve NP- Complete and #P Complete
> problems. Thus, such a device could decipher
> any code except for those encrypted via a one-
> time pad key cipher or possibly certain types
> of quantum cryptography (both of which are
> very rarely used). To begin seeing how this
> might work check out this physics paper:
> //xxx.lanl.gov/abs/quant-ph/9910073
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
I already have one made of spare parts from my timer. It's the quantum
computer that keeps on ticking.
Look, this story has been 'reported' twenty if not more times already
before. NOBODY GIVES A FUCK!!!
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "Lassi Hippel�inen" <"lahippel$does-not-eat-canned-food"@ieee.org>
Subject: Re: How much does it cost to share knowledge?
Date: Mon, 31 Jan 2000 12:19:57 GMT
Rick Braddam wrote:
>
> Ken Polsson has a history page (with references) at:
> http://www.islandnet.com/~kpolsson/comphist.htm
> Portions within double-quotes (") are:
> Copyright (C) 1994-99 Ken Polsson
> internet e-mail: [EMAIL PROTECTED]
> URL: http://www.islandnet.com/~kpolsson/comphist.htm
Interesting read, but I was disappointed that the history doesn't
mention things that happened outside the USA. Here in Finland, to give
an example, the first computer based on i8008 was built in 1972. The
guys had only data sheets, and then had to wait till the first chip
arrived. They plugged it in, and it worked :-)
<...>
> The PDP-8 should have been a fine machine, but it was basically a
> minicomputer. At circa $28,000 it was hardly a personal or home
> computer, even if some (well to do) people had one.
Later the Intersil IM6100 was a CMOS chip with PDP-8/E instruction set.
I don't know if anybody built a home computer using it, but it would
certainly have cost much less than $28k.
-- Lassi
------------------------------
Date: Mon, 31 Jan 2000 14:19:04 +0100
From: Bastian Hecht <[EMAIL PROTECTED]>
Subject: is key escrow still current topic?
Hi there!
I�m afraid I�m absolutely not up-to-date. I need an intro for a certain
document I must write for school about cryptograhy. Do you know where I
can find related news to the clipper system?? Thanx for any kind of
help!!
cu
basti
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: KEA gains something with RSA instead of D-H
Date: Mon, 31 Jan 2000 13:29:46 GMT
On Mon, 31 Jan 2000 07:08:28 GMT, [EMAIL PROTECTED]
(John Savard) wrote, in part:
>Hence, as with the RSA example, one has to compromise the persistent
>private keys of both parties to the communication, *unless* one has
>instead compromised one of the nonces.
Given that nonces are so superior to persistent private keys, but
persistent private keys are needed for certification, the thought
occured to me: why not use the KEA session key to authenticate two
more public keys, A^z1 and A^z2, where z1 and z2 are both nonces, and
use A^(z1*z2) as the actual session key? Then, an attacker knowing
both x1 and x2 would still be unable to read the messages.
That is, a *passive* attacker. Someone knowing either x1 or x2 could
use user 1's or user 2's key certificate to impersonate that user, and
someone knowing both could mount a man-in-the-middle attack (the
certificates would be obtained from intercepting a previous
communication).
So, my "improved" protocol gives more of an illusion of security than
real security: and from that line of reasoning, the nonces are present
in KEA so that each session key is different, even though the session
key is guaranteed by the certificates of both users, rather than for
the other security advantage of nonces - which exists, but is harder
to benefit from than I thought.
Now, if the key certificates weren't sent in the clear, can one
overcome this limitation? If I just send my key certificate to the
other fellow encrypted using another of his persistent public keys,
compromise of a persistent private key still lets it be read. To avoid
the certificates being available, the CA, instead of providing a
public list of them, would have to give a yes/no response to the
authenticity of a certificate submitted to it - but a certificate
encrypted in the CA's public key is just as usable as one in the
clear.
Of course!
User 1 and User 2 wish to communicate.
First, they announce their attention to the CA, which issues them both
random encryption keys.
Then, each user encrypts his A^x public key with their random
encryption key, followed by the public key of the CA. The CA then
verifies the two public keys, and lets each user know the other user
is authentic.
(So the certificates are transmitted in challenge-response mode, and
nothing usable for impersonation can be intercepted.)
Now the two users generate their y private keys, and A^y private keys,
and carry out KEA.
Then each user generates a second nonce, z1 and z2 respectively, and
A^(z1*z2), known to both users, is added modulo A to the KEA session
key (or XORed or something) and _that_ is used as the session key.
Isn't this a wonderful protocol? Compromise of both persistent private
keys doesn't allow a passive attack, and no certificates can be
intercepted.
Ah, but if you have access to one of the user's computers to steal a
persistent private key from it, you can probably also swipe the
certificate while you're there...and then you can fool the CA quite
nicely. Trying to design a protocol that remains secure when all
secret data of both participants is compromised is, in fact, a chimera
- it should have been obvious to me that such a thing is impossible.
John Savard (teneerf <-)
http://www.ecn.ab.ca/~jsavard/index.html
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: How to Annoy the NSA
Date: Mon, 31 Jan 2000 13:33:08 GMT
On Mon, 31 Jan 2000 00:51:36 -0700, Jerry Coffin <[EMAIL PROTECTED]>
wrote, in part:
>Also note that nobody's figured out ANY way to use a quantum computer
>to attack MANY (if not most) of the ciphers in use today.
True, although some descriptions of possible quantum computers
envisage the possibility of versions that are easier to use than the
usual type of quantum computer that is foreseen.
John Savard (teneerf <-)
http://www.ecn.ab.ca/~jsavard/index.html
------------------------------
From: Marc Koch <[EMAIL PROTECTED]>
Subject: Re: IDEA
Date: Mon, 31 Jan 2000 14:47:54 +0100
Hello Arie,
go to http://www.ascom.ch/infosec/idea.html
That�s the main place to look and download.
Good luck,
Marc
Arie Gerszt wrote:
>
> Hi
>
> I am a student from Switzerland. I was
> searching for a good resource concerning
> the IDEA encryptio algorithm. I was looking
> for a C/C++ source for compiling under Linux.
> Does anybody have some good links, hints or
> other resources concering IDEA and linux?
>
> Thanks for your help,
>
> regards arie
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: A question about odd grilles
Date: Mon, 31 Jan 2000 16:22:01 +0100
John Savard schrieb:
>
> On Sun, 30 Jan 2000 21:24:18 +0100, Mok-Kong Shen
> <[EMAIL PROTECTED]> wrote, in part:
> >Boris Kazak wrote:
>
> >> One workable solution can be to use this central hole right during the
> >> first quadrant positioning, and ignore it during the 3 remaining
> >> quadrants. This is easy to do while encrypting and while decrypting.
>
> >But this means that the plaintext character put in at that location
> >is fixed, i.e. does not move as do the other characters taking part
> >in the whole transpositon effected by the grille. Hence, it seems
> >better to either ignore it or to put in a null there.
>
> Huh? It "moves" or not just as much as all the other letters written
> down in the holes of the grille in its first position.
If one has, for example, a turning grille of 7*7 that accepts the
same amount of plaintext, than the 25th character of the plaintext
IS (always) the 25th character of the ciphertext. By this I meant
that that character is fixed (with respect to input/output), while
the other plaintext characters may or may not move (changed positions)
as a result of the encryption, depending on the design of the grille.
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: A question about odd grilles
Date: Mon, 31 Jan 2000 16:52:31 +0100
Mok-Kong Shen wrote:
>
> If one has, for example, a turning grille of 7*7 that accepts the
[snip]
Sorry, I was wrong. My apology for having posted some nonsense.
M. K. Shen
------------------------------
From: JCA <[EMAIL PROTECTED]>
Subject: Voynich manuscript
Date: Mon, 31 Jan 2000 07:42:52 -0800
I have not heard any news about this for quite some time. Anybody
know if
there has been any progress within the last few years? Or, more to the
point,
is anybody actually looking into this, or has it been brushed aside as a
medieval
practical joke?
------------------------------
From: "Tony T. Warnock" <[EMAIL PROTECTED]>
Subject: Re: Pencil & paper cipher question
Date: Mon, 31 Jan 2000 08:56:28 -0700
Reply-To: [EMAIL PROTECTED]
What would be wrong with extending the cypher that Terry Ritter
described using a double Playfair. First do a simple transposition: for
example, write the plaintext in order: p1, pn, p2, pn-1,...etc, that is,
first, last, second, penultimate, third, antepenultimate, fourth, etc.
Then do a playfair on the first key. Append nulls at the beginning and
end, the Playfair again on a second key. Append nulls and Playfair on
the third key. A simple transpositon could be done between Playfairs.
The idea is to be simple for pencil and paper.
------------------------------
Date: Mon, 31 Jan 2000 11:32:32 -0500
From: "Trevor Jackson, III" <[EMAIL PROTECTED]>
Crossposted-To: sci.physics
Subject: Re: Intel 810 chipset Random Number Generator
Jerry Coffin wrote:
> At least as far as I can tell, if crystal
> oscillators acted like he claims, we could plan on the average
> oscillator drifting by tens of percent over a matter of a few days of
> use, but then by being turned off and back on, they'd magically start
> back up at rated frequency again.
If you are measuring phase drift rather than frequency drift I think you'll
see this kind of behavior. But the effect is meaningless because the reset
event resets the reference as well as the phenomena!
------------------------------
Date: Mon, 31 Jan 2000 11:40:12 -0500
From: "Trevor Jackson, III" <[EMAIL PROTECTED]>
Crossposted-To: sci.physics
Subject: Re: Intel 810 chipset Random Number Generator
Michael Kagalenko wrote:
> Guy Macon ([EMAIL PROTECTED]) wrote
> ]>God NO! That was what I'd intended to object to. It seems to me that
> ]>he's spouting complete nonsense about something of which he hasn't the
> ]>least grasp at all. At least as far as I can tell, if crystal
> ]>oscillators acted like he claims, we could plan on the average
> ]>oscillator drifting by tens of percent over a matter of a few days of
> ]>use, but then by being turned off and back on, they'd magically start
> ]>back up at rated frequency again.
>
> I have said several times that this is not what I mean. Are you capable of
> reading ?
>
> ] I'll grant anybody that turning one
> ]>off for a while will usually result in a small change in frequency
> ]>simply because most oscillators generate at least a little heat, so
> ]>the crystal will normally cool off a little when it's not in use, but
> ]>the effect here is usually quite minor, and at any rate jitter and
> ]>thermal drift are fundamentally unrelated in any case.
> ]
> ]I think you got his claim backwards (not suprising given that he
> ]really doesn't make any sense at all 99% of the time!) He is saying
> ]that the "thermal drift" (which he says happens when the temperature
> ]of the crystal is kept constant, so it's not what you are thinking
> ]it is) of (frequency?)
>
> I have said twice that average frequency does not drift. You must
> have severe reading difficulty.
>
> ] diverges from the starting point in the same
> ]manner that a particle does under brownian motion
>
> I have told you that analogy of the position of Brwonian particle is
> not frequency. What's wrong with your reading skills ?
They keep concluding that because you spend all of your bandwidth describing
what you haven't said rather than clarifying/amplifying what you were trying to
say. Above you state that the analogy of the position of Brownian particle is
not frequency. Waste of bandwidth. Rather than amplifying the dispute why not
resolve the issue by stating what the analogy _is_ rather than what it
_is_not_.
>
>
> ] AND THAT THIS
> ]DIVERGENCE STAYS THE SAME EVEN WHEN YOU TURN OFF THE POWER
> ]OVERNIGHT!!! Have you ever seen the output of a player behave
> ]like that? Neither have I. Only aging of the quartz acts
> ]like that, and he specifically excluded that as a possibility.
> ]
> ]He is right about one thing, though. Nobody understands his theory.
>
> It is fairly entertaining thread, as far as I am concerned. All
> the electrical engineers and programmers from sci.crypt keep
> attributing to me things that I sepocifically, repeatedly and
> clearly disclaimed.
And you keep attributing this phenomena to everyone else's deficiencies in
reading, thinking, understanding, etc.
By Occam, if not by rationality, you are the source of the communication
problem. Thus it is up to you to communicate with your audience. It is not up
to the audience to mind-read past your lack of communication skills.
> As they say, no one is more deaf than the one
> unwilling to listen.
And insults do not add weight to your arguments. Rather the reverse.
------------------------------
Date: Fri, 28 Jan 2000 09:48:00 -0700
From: Shawn Willden <[EMAIL PROTECTED]>
Subject: Re: Java's RSA implimentation
Bill Unruh wrote:
> In <862upd$vr$[EMAIL PROTECTED]> [EMAIL PROTECTED] writes:
>
> >Is anyone aware of any effort to analyse the RSA implementation in Java;
> >specifically focusing on key generation.
>
> ??? Java is a language, much like C in many essentials. It is up to you
> to code what you want it to do.
True and false. In many cases Java provides much of what you might want to
code in the standard and extended libraries. Java does not currently provide
RSA (the Java Cryptography Extension provides DH).
> >Does Java use a table of primes? If so, how big is the table?
>
> No, Java does not. But you can enter a table of primes if you wish. And
> you can encode a prime testing routine in Java just as you can in C.
Except that the common way of writing a primality testing routine in java is:
java.math.BigInteger i = new java.math.BigInteger(number);
return i.isProbablePrime();
> >Otherwise how good is it's prime number generation routines ie. what is
> >the probability of a generated number not being prime.
>
> I do not know that Java has a "prime number generating routine". but you
> can code one up in Java.
Again, the easy way to write a prime number generating routine in Java is:
java.security.SecureRandom sr = new java.security.SecureRandom();
return java.math.BigInteger(numberOfBits, 100, sr);
The original poster's question does actually make some sense in the context
of a language that provides extensive libraries.
Shawn.
------------------------------
Date: Fri, 28 Jan 2000 15:40:30 -0700
From: Shawn Willden <[EMAIL PROTECTED]>
Subject: Re: Blowfish Question
Eric Lee Green wrote:
> Shawn Willden wrote:
> > Chung W Leong wrote:
> >
> > > Even if you have control over the original text, analyzing the resulting
> > > encrypted text would still yield no information (even or odd, divisibility,
> > > the number of 1s and 0s, tendency, attitude, psychological state) about the
> > > secret key? What if you have multiple (say 1000) original-encrypted text
> > > pairs?
> > > My firm is currently working on a e-commerce site, where we're planning to
> > > encrypt the credit card numbers of customers with Blowfish before storing
> > > them into the database, in case the security of the database is compromised.
> >
> > A good way to characterize the assumptions used in cryptanalytic attacks on
> > algorithms is as follows:
> >
> > Assume that the attacker has full details of the design and implementation of
> > the algorithm. Further, assume that the attacker has access to an "oracle", a
> > device that will encrypt and decrypt anything the attacker wants, using a key
> > that is *not* known to the attacker. Assume that the attacker has the time,
> > interest and ability to perform a very large number of computations, up to, but
> > not including, 2^n, where n is the key size in bits (i.e. assume that the
> > attacker can't mount a brute force attack, but can get close).
> >
> > Under those assumptions, the algorithm is weak if:
> You forgot one other thing: the algorithm is weak if the SYSTEM is weak. I.e.,
> if the key can be obtained without the need to "crack" the algorithm.
I'm rather impressed with myself if that's all I forgot :-)
I agree completely. The original poster was only asking about the algorithm, so my
response only dealt with the algorithm, but it would have been good to mention that
the algorithm is only one small (though important) piece of a system.
> In the previous example of encrypting credit card numbers prior to
> placing them into the database, this is only reasonable if you assume that the
> machine doing the encrypting/decrpyting is not compromised.
Yep. To counter this effectively requires physical and network security at the
least. I'd recommend a host security module (HSM) for key storage and encryption
operations -- one that allows multiple levels of functionality to be activated by
different passphrases, plus careful design of the applications that use the HSM and
careful control of the passphrases. On top of that, I'd recommend thorough audit
logging and auditing of the system and the logs. And did I mention physical and
network security?
Shawn.
------------------------------
Date: Fri, 28 Jan 2000 16:33:30 -0700
From: Shawn Willden <[EMAIL PROTECTED]>
Subject: Re: Simple Equivalent keys in Serpent
[EMAIL PROTECTED] wrote:
> First off, I don't think this is a weakness in Serpent. It is an
> oddity however.
>
> From looking at the key schedule for Serpent, I believe each 128 and
> 192 bit key has an equivalent 256 bit key.
It's not a unique oddity, though, and might even be intentional. The
common EDE form of triple DES has the same characteristic (each 56-bit key
has equivalent 112-bit and 168-bit keys, and each 112-bit key has an
equivalent 168-bit key), and was chosen precisely for that reason.
Shawn.
------------------------------
** 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
******************************
