Cryptography-Digest Digest #782
Cryptography-Digest Digest #782, Volume #12 Tue, 26 Sep 00 23:13:01 EDT
Contents:
RSA T-shirt ("Jeff Moser")
Re: IBM analysis secret. ("Brian Gladman")
Re: RSA T-shirt ("Rich Ankney")
Re: RSA T-shirt (Mean R. K. Oily)
Re: IBM analysis secret. (SCOTT19U.ZIP_GUY)
Re: RSA T-shirt ("Jeff Moser")
Re: differnetials... (John Savard)
Re: A Different Kind of Quantum Computer (John Savard)
Re: Question on biases in random-numbers & decompression (David Hopwood)
Re: Question on biases in random-numbers & decompression (Bruno Wolff III)
Re: RSA T-shirt (David A Molnar)
Re: Steganography and secret sorting (Matthew Skala)
Re: On block encrpytion processing with intermediate permutations (Bryan Olson)
From: "Jeff Moser" <[EMAIL PROTECTED]>
Subject: RSA T-shirt
Date: Tue, 26 Sep 2000 18:04:42 -0500
Has anyone actually received their RSA t-shirt from the early patent release
promo?
I was told it was sent, but have yet to receive it.
Jeff
--
From: "Brian Gladman" <[EMAIL PROTECTED]>
Subject: Re: IBM analysis secret.
Date: Wed, 27 Sep 2000 00:42:01 +0100
"SCOTT19U.ZIP_GUY" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> [EMAIL PROTECTED] (DJohn37050) wrote in
> <[EMAIL PROTECTED]>:
>
> >Don Coppersmith wrote an article on DES published in the IBM Journal of
> >Research and Development when he says that IBM knew of the potential for
> >differential analysis (they had another name for it) and designed DES to
> >resist it. And that this info was kept secret, as they saw no reason to
> >help an adversary, as it was a powerful attack. He also listed all the
> >security criteria of the S- boxes.
> >Don Johnson
> >
> Having worked in the government for 26 years. I would take anything
> a corporation says with a grain of salt. Numberous times govenment
> employess did all the work and then later the BIG CORPARATIONS with
> money acted like they did something. My view is that the boys at IBM
> never where given the reasons for DES and just went along with the NSA
> just as they most likely were never given an honest reason why it was
> 56 bytes instead of 64.
bits, not bytes, if you are referring to the DES key length.
And the earlier statement is about what Don Coppersmith has said, not about
what IBM has said.
Brian Gladman
--
From: "Rich Ankney" <[EMAIL PROTECTED]>
Subject: Re: RSA T-shirt
Date: Tue, 26 Sep 2000 19:45:04 -0400
Not yet. I won't get upset till next week:-)
/ Rich
Jeff Moser wrote in message <8qra2a$efa$[EMAIL PROTECTED]>...
>Has anyone actually received their RSA t-shirt from the early patent
release
>promo?
>
>I was told it was sent, but have yet to receive it.
>
>Jeff
>
>
--
From: [EMAIL PROTECTED] (Mean R. K. Oily)
Subject: Re: RSA T-shirt
Date: Tue, 26 Sep 2000 23:45:27 GMT
"Jeff Moser" <[EMAIL PROTECTED]> wrote:
>Has anyone actually received their RSA t-shirt from the early patent release
>promo?
>
>I was told it was sent, but have yet to receive it.
Until you receive it, I guess you'll just have to be content to pull your
pants up to your armpits, wear a plastic pouch full of pens and a laser
pointer in your shirt pocket, a calculator on your belt with functions like
"hyperbolic cotangent", and plastic rimmed glasses that have been repaired
with band-aids. The shirt will round that out nicely when it finally comes.
--
"Mean R. K. Oily" is actually 0751 329864 <[EMAIL PROTECTED]>.
0123 4 5 6789 <- Use this key to decode my email address and name.
Play Five by Five Poker at http://www.5x5poker.com.
--
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: IBM analysis secret.
Date: 26 Sep 2000 23:48:43 GMT
[EMAIL PROTECTED] (Brian Gladman) wrote in
<4raA5.15985$Cl1.394240@stones>:
>"SCOTT19U.ZIP_GUY" <[EMAIL PROTECTED]> wrote in message
>news:[EMAIL PROTECTED]...
>> [EMAIL PROTECTED] (DJohn37050) wrote in
>> <[EMAIL PROTECTED]>:
>>
>> >Don Coppersmith wrote an article on DES published in the IBM Journal
>> >of Research and Development when he says that IBM knew of the
>> >potential for differential analysis (they had another name for it)
>> >and designed DES to resist it. And that this info was kept secret,
>> >as they saw no reason to help an adversary, as it was a powerful
>> >attack. He also listed all the security criteria of the S- boxes.
>> >Don Johnson
>> >
>> Having worked in the government for 26 years. I would take anything
>> a corporation says with a grain of salt. Numberous times govenment
>> employess did all the work and then later the BIG CORPARATIONS with
>> money acted like they did something. My view is that the boys at IBM
>> never where given the reasons for DES and just went along with the NSA
>> just as they most likely were never given an honest reason why it was
>> 56 bytes instead
Cryptography-Digest Digest #781
Cryptography-Digest Digest #781, Volume #12 Tue, 26 Sep 00 19:13:00 EDT
Contents:
Re: On block encrpytion processing with intermediate permutations (Mok-Kong Shen)
Re: On block encrpytion processing with intermediate permutations (Mok-Kong Shen)
Re: On block encrpytion processing with intermediate permutations (Mok-Kong Shen)
PRNG improvment?? ([EMAIL PROTECTED])
Re: continuous functions and differential cryptanalysis (Doug Kuhlman)
Re: continuous functions and differential cryptanalysis (Doug Kuhlman)
Re: continuous functions and differential cryptanalysis (Tom St Denis)
Re: differnetials... (Tom St Denis)
Re: PRNG improvment?? ("Paul Pires")
Re: On block encrpytion processing with intermediate permutations (Mok-Kong Shen)
Re: What am I missing? (Scott Craver)
Re: Steganography and secret sorting ([EMAIL PROTECTED])
Re: PRNG improvment?? (Eric Lee Green)
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: On block encrpytion processing with intermediate permutations
Date: Tue, 26 Sep 2000 22:36:36 +0200
Tom St Denis wrote:
>
> Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
> > Let's first agree that we are arguing about what I call
> > the full version of my scheme. You compute the differences.
> > but do you know which differences correspond to which
> > word/block of the original plaintext? Note that, due to
> > the word (or groups of words) permutation, everything
> > has got mixed up in a way that the opponent can't find
> > out. Please kindly re-read my original post and forget
> > for the time being the last two paragraph and do a
> > sketch with pencil of how you would go about with your
> > differential analysis with, say, DES as block encryption
> > algorithm and a message of 20 blocks. I think that my
> > idea would then be clear to you. Note in particular that
> > you have no knowledge of the permutations that are being
> > done. There could be poor permutations. Let's assume
> > that 2 are poor but 14 are good.
>
> That's just it, you can't have 2 good perms and 14 bad ones. it's the
> composition of them all... so either the entire perm is balanced (each
> word combines into DES with equally once...) or they don't. Realize
> that in 16 rounds of this protocal you need 17 blocks to get equal
> mixing (I think)... otherwise the mixing cannot be balanced...
Suppose you have a reasonably good PRNG, please tell
me what is the chance of having 2 good perms and 14
bad ones in comparison to having 14 good perms and
2 bad ones?
M. K. Shen
--
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: On block encrpytion processing with intermediate permutations
Date: Tue, 26 Sep 2000 22:39:57 +0200
Bryan Olson schrieb:
>
> Mok-Kong Shen wrote:
>
> > Suppose each half is a word (e.g. DES), the permutation
> > is rendering each one of them to go to a different
> > location that is unknown to the opponent. I don't yet
> > see how he can 'follow' the individual halves as they
> > get processed in the different cycles in order to be
> > able to exploit differentials etc.
>
> No need to follow the path. Just recognize that when
> all other input blocks are held constant, the input
> differential on block i always becomes the final output
> differential on block j.
Then you have at least a work factor equal to the
number of blocks of the message. And you have to
manage that all messages for your investigation
have the same length.
M. K. Shen
--
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: On block encrpytion processing with intermediate permutations
Date: Tue, 26 Sep 2000 22:46:40 +0200
Mok-Kong Shen wrote:
>
> Then you have at least a work factor equal to the
> number of blocks of the message. And you have to
> manage that all messages for your investigation
> have the same length.
I was not quite right. Even if the all input blocks
are constant, in case a block has, say, 4 words,
then permutation still has an effect. In that case
one would have to prescribe that all words are
the same in the input.
M. K. Shen
--
From: [EMAIL PROTECTED]
Subject: PRNG improvment??
Date: Tue, 26 Sep 2000 20:50:40 GMT
I have a question to the group. Will the idea below work or is it
deeply flawed, and if so, where and how.
If I fill an array of 2560 elements with 10 consecutive instantces of
0..255, then I have a uniform distribution of keys that have such an
obvious pattern that they are usless for cryptography. However, if I
take a readily available pseudo random number generator and use the
PRNG to generate INDEX values in the range of 0-2559, then I could
'randomly' pick elements from my first array and populate a second
array, in order picked, with the values in the first array the PRNG
points to. This is a simple shuffling exercise.
Now if I seed the PRNG with true random numbers, license plates,
s
Cryptography-Digest Digest #780
Cryptography-Digest Digest #780, Volume #12 Tue, 26 Sep 00 17:13:00 EDT
Contents:
Re: On block encrpytion processing with intermediate permutations (Tom St Denis)
Re: continuous functions and differential cryptanalysis (Tom St Denis)
Re: continuous functions and differential cryptanalysis (Dido Sevilla)
test values for HMAC-Tiger (Dido Sevilla)
Re: differnetials... (Doug Kuhlman)
Re: continuous functions and differential cryptanalysis (Mok-Kong Shen)
Re: On block encrpytion processing with intermediate permutations (Mok-Kong Shen)
Re: Software patents are evil. ("Paul Pires")
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: On block encrpytion processing with intermediate permutations
Date: Tue, 26 Sep 2000 18:05:28 GMT
In article <[EMAIL PROTECTED]>,
Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
> Let's first agree that we are arguing about what I call
> the full version of my scheme. You compute the differences.
> but do you know which differences correspond to which
> word/block of the original plaintext? Note that, due to
> the word (or groups of words) permutation, everything
> has got mixed up in a way that the opponent can't find
> out. Please kindly re-read my original post and forget
> for the time being the last two paragraph and do a
> sketch with pencil of how you would go about with your
> differential analysis with, say, DES as block encryption
> algorithm and a message of 20 blocks. I think that my
> idea would then be clear to you. Note in particular that
> you have no knowledge of the permutations that are being
> done. There could be poor permutations. Let's assume
> that 2 are poor but 14 are good.
That's just it, you can't have 2 good perms and 14 bad ones. it's the
composition of them all... so either the entire perm is balanced (each
word combines into DES with equally once...) or they don't. Realize
that in 16 rounds of this protocal you need 17 blocks to get equal
mixing (I think)... otherwise the mixing cannot be balanced...
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
--
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: continuous functions and differential cryptanalysis
Date: Tue, 26 Sep 2000 18:42:31 GMT
In article <[EMAIL PROTECTED]>,
Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
>
>
> Mika R S Kojo wrote:
> >
> > Derivative is well-defined for any field, but its usually called
> > "formal derivative". It is even possible to talk about continuous
> > functions, but for for this you need p-adic numbers.
>
> Dumb question: Are p-adic numbers inside the theory of
> GF or else at least compatible with it? If yes, could
> you please provide references? Thanks.
I can top that, what are p-adic numbers?
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
--
From: Dido Sevilla <[EMAIL PROTECTED]>
Subject: Re: continuous functions and differential cryptanalysis
Date: Wed, 27 Sep 2000 03:23:52 +0800
Paul Rubin wrote:
>
> Tom St Denis <[EMAIL PROTECTED]> writes:
>
> > Woohoo I used calc for something.
> >
> > Theorem. No continuous [finite] function can ever have a minimum
> > Probability associated with a differential (over all possible
> > differentials).
> >
> > Lemma. Examine the derivative of function 1/x in GF(2)^n, given as -
>
> Um, what's wrong with this sentence? Hint: do you know what a
> derivative is?
Has he properly defined a derivative in GF(2^n)? To define a
derivative, we have to begin with a definition of a metric in GF(2^n),
then work our way to a definition of a limit, then the definition of a
derivative. Let's say we do come up with a valid metric, coming up with
a metric function d(x, y) for x and y in GF(2^n) that satisfies all the
metric axioms (I suppose it would be possible). Now we try to define a
limit for infinite sequences in GF(2^n). Say we have
limz_n = l
n->inf
this means that l element of GF(2^n) exists such that for *every*
positive real number epsilon, no matter how small, an integer n_0 can be
found such that d(z_n, l) < epsilon, for all values of n greater than
n_0. Now, clearly, the metric cannot be expected to produce *all* real
values of epsilon, seeing as the metric is only defined for the 2^n
elements in GF(2^n), and so the range of the metric function has only
2^2n elements. Now, obviously there's no way we can generate a
one-to-one mapping for a finite set onto an uncountably infinite set
like the real numbers, so we can't define a limit in GF(2^n), or in any
finite field for that matter, so a derivative, at least as defined by
modern analysis, can't be constructed either. If you can't come up with
a proper definition at the beginning, then natch, your whole argument
must be worthless too. But hey, a proper definition for a derivative in
finite fields *may* exist that doesn't use the notions of metrics or
limits, but if so, I haven't
Cryptography-Digest Digest #779
Cryptography-Digest Digest #779, Volume #12 Tue, 26 Sep 00 16:13:01 EDT
Contents:
quantum cryptography over optical fibres ("David C. Barber")
Re: differnetials... (Mike Rosing)
Re: On block encrpytion processing with intermediate permutations (Mok-Kong Shen)
Re: On block encrpytion processing with intermediate permutations (Mok-Kong Shen)
Re: DES (Mok-Kong Shen)
Re: continuous functions and differential cryptanalysis (Mok-Kong Shen)
Re: A Different Kind of Quantum Computer (Bill Unruh)
Re: What make a cipher resistent to Differential Cryptanalysis? (Mok-Kong Shen)
Re: continuous functions and differential cryptanalysis (Tom St Denis)
Re: continuous functions and differential cryptanalysis (Tom St Denis)
Re: What am I missing? (Lon Willett)
Re: On block encrpytion processing with intermediate permutations (Bryan Olson)
Re: differnetials... (Tom St Denis)
Re: continuous functions and differential cryptanalysis (Tom St Denis)
Re: Why is TwoFish better than Blowfish? (Tom St Denis)
Re: On block encrpytion processing with intermediate permutations (Tom St Denis)
From: "David C. Barber" <[EMAIL PROTECTED]>
Subject: quantum cryptography over optical fibres
Date: Tue, 26 Sep 2000 10:14:12 -0700
An interesting news article about secure transmission using quantum
cryptography over optical fibres
http://www.theregister.co.uk/content/1/13536.html
--
From: Mike Rosing <[EMAIL PROTECTED]>
Subject: Re: differnetials...
Date: Tue, 26 Sep 2000 12:32:52 -0500
Tom St Denis wrote:
> Arrg... calculus is all new to me... please help!
You're mixing finite fields and continuous analytic numbers.
As my kids would say "that does not include". The idea behind
calculus is that you can "infinitly" divide things down very
smoothly. The idea behind finite fields is that every element
is distinct. A better way to combine these is thru p-adic
numbers. I'd suggest you keep finite field ideas completely
separate from calculus ideas, at least for a few months :-)
Follow the proof carefully for why d/dx ( 1/x) = 1/x^2. You
use limits. Can't do that with a finite field!!
Patience, persistence, truth,
Dr. mike
--
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: On block encrpytion processing with intermediate permutations
Date: Tue, 26 Sep 2000 19:48:42 +0200
Tom St Denis wrote:
> Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
> > Bryan Olson wrote:
> >
> > > Tom is right; the diffusion is obviously terrible.
> > > Here's a first-cut at an attack strategy:
> > >
> > > In a typical Fiestel cipher one might have 16 rounds
> > > or 8 round-pairs. Let's use chosen messages of about a
> > > thousand blocks. We introduce differential pairs in
> > > which only one block input differs. There probably
> > > exists a left half-block for which any input
> > > differential survives to become an output differential.
> > > That happens if at each of the seven between-round
> > > permutations the differential goes into a left block
> > > and the right blocks are still constant.
> > >
> > > We can easilly detect the case when it happens; the
> > > differential put into the left half of input block
> > > 'i', appears as the differential comming out of the
> > > left half of ouput block 'j'. Now we can put
> > > differntial pairs into the right half of i, holding
> > > everything else constant, and the differential that
> > > comes out in the left half of j is exactly the
> > > differential from the right half of i going through
> > > the f function in the first round. For most Feistel
> > > ciphers that will expose the first round-key, and
> > > allow us to push to the next round.
> > >
> > > There are other opportunities to extract information
> > > based on the poor diffusion. As a rule of thumb,
> > > letting information out from intermediate rounds is
> > > extremely dangerous.
> >
> > Suppose each half is a word (e.g. DES), the permutation
> > is rendering each one of them to go to a different
> > location that is unknown to the opponent. I don't yet
> > see how he can 'follow' the individual halves as they
> > get processed in the different cycles in order to be
> > able to exploit differentials etc. He has a moving
> > target, so to say, and the motion is invisible.
>
> That's just it. If the blocks diffuse poorly things like differential
> cryptanalysis will work. I can send a huge msg in with specific
> differences. Then I watch to see which output halves have the required
> difference. Then I can guess which are involved...While this is not a
> concrete attack if you only use say 2-round DES in each step the
> differences will propagate for sure.
Let's first agree that we are arguing about what I call
the full version of my scheme. You compute the differences.
but do you know which differences correspond to which
word/block of the original plain
Cryptography-Digest Digest #778
Cryptography-Digest Digest #778, Volume #12 Tue, 26 Sep 00 13:13:01 EDT
Contents:
Re: On block encrpytion processing with intermediate permutations (Tom St Denis)
Re: What make a cipher resistent to Differential Cryptanalysis? (Tom St Denis)
Re: continuous functions and differential cryptanalysis (Tom St Denis)
Re: Encryption Project (pink aka Chr. Boesgaard)
Re: Tying Up Loose Ends - Correction (Tim Tyler)
Re: Test for weak keys in 3DES (Paul Schlyter)
Re: continuous functions and differential cryptanalysis (Tim Tyler)
Re: Question on biases in random numbers & decompression (Tim Tyler)
Re: Question on biases in random-numbers & decompression (Tim Tyler)
Re: Question on biases in random-numbers & decompression ("D.A.Kopf")
Re: A New (?) Use for Chi (John Savard)
DES ([EMAIL PROTECTED])
Re: Test for weak keys in 3DES ("kihdip")
Re: continuous functions and differential cryptanalysis (Mika R S Kojo)
Re: Why is TwoFish better than Blowfish? (Eric Lee Green)
Re: DES ("Martin Wolters")
Re: continuous functions and differential cryptanalysis ("Scott Fluhrer")
Re: Again a topic of disappearing e-mail? ("David C. Barber")
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: On block encrpytion processing with intermediate permutations
Date: Tue, 26 Sep 2000 10:56:05 GMT
In article <[EMAIL PROTECTED]>,
Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
>
>
> Bryan Olson wrote:
> >
>
> > Tom is right; the diffusion is obviously terrible.
> > Here's a first-cut at an attack strategy:
> >
> > In a typical Fiestel cipher one might have 16 rounds
> > or 8 round-pairs. Let's use chosen messages of about a
> > thousand blocks. We introduce differential pairs in
> > which only one block input differs. There probably
> > exists a left half-block for which any input
> > differential survives to become an output differential.
> > That happens if at each of the seven between-round
> > permutations the differential goes into a left block
> > and the right blocks are still constant.
> >
> > We can easilly detect the case when it happens; the
> > differential put into the left half of input block
> > 'i', appears as the differential comming out of the
> > left half of ouput block 'j'. Now we can put
> > differntial pairs into the right half of i, holding
> > everything else constant, and the differential that
> > comes out in the left half of j is exactly the
> > differential from the right half of i going through
> > the f function in the first round. For most Feistel
> > ciphers that will expose the first round-key, and
> > allow us to push to the next round.
> >
> > There are other opportunities to extract information
> > based on the poor diffusion. As a rule of thumb,
> > letting information out from intermediate rounds is
> > extremely dangerous.
>
> Suppose each half is a word (e.g. DES), the permutation
> is rendering each one of them to go to a different
> location that is unknown to the opponent. I don't yet
> see how he can 'follow' the individual halves as they
> get processed in the different cycles in order to be
> able to exploit differentials etc. He has a moving
> target, so to say, and the motion is invisible.
That's just it. If the blocks diffuse poorly things like differential
cryptanalysis will work. I can send a huge msg in with specific
differences. Then I watch to see which output halves have the required
difference. Then I can guess which are involved...While this is not a
concrete attack if you only use say 2-round DES in each step the
differences will propagate for sure.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
--
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: What make a cipher resistent to Differential Cryptanalysis?
Date: Tue, 26 Sep 2000 10:59:47 GMT
In article <[EMAIL PROTECTED]>,
Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
>
>
> Tom St Denis wrote:
> >
>
> > Ah, but something can be pratically random. Take the output of say
RC4
> > that is hashed (gather 30 bytes then hash it via SHA-1, etc...) I
would
> > bet 10 bucks that without knowing the RC4 seed you couldn't guess
the
> > output better then 1/2.
> >
> > Make the RC4 seed 256 bits long ... and voila.
> >
> > Of course how do you make a random RC4 seed? recursive problem...
>
> I am really confused. Aren't we discussing the 'ideal'
> OTP that requires (theoretical) perfect randomness
> all the time? Why here 'practical' randomness at all??
That's just it. If you can't practically guess the output, isn't it
effectively random?
Random is not a point in uncertainty, it's a state of it. If something
is random to you, that means you can study it to guess the next output
with any success better then the standard distribution. (1/p ...).
Universal randomness as people want to see it CANNOT EXIST. It's
impossible for something to be totally random. But it's possi
Cryptography-Digest Digest #777
Cryptography-Digest Digest #777, Volume #12 Tue, 26 Sep 00 07:13:00 EDT Contents: Re: Encryption Project (Bryan Olson) Re: Tying Up Loose Ends - Correction (Tim Tyler) Re: Tying Up Loose Ends - Correction (Tim Tyler) Re: On block encrpytion processing with intermediate permutations (Mok-Kong Shen) Re: On block encrpytion processing with intermediate permutations (Mok-Kong Shen) Re: On block encrpytion processing with intermediate permutations (Mok-Kong Shen) Re: Test for weak keys in 3DES (Tom St Denis) Re: continuous functions and differential cryptanalysis (Tom St Denis) Re: What make a cipher resistent to Differential Cryptanalysis? (Mok-Kong Shen) Re: What make a cipher resistent to Differential Cryptanalysis? (Mok-Kong Shen) Re: continuous functions and differential cryptanalysis (Mok-Kong Shen) Re: On block encrpytion processing with intermediate permutations (Tom St Denis) Re: "Secrets and Lies" at 50% off (Arturo) From: Bryan Olson <[EMAIL PROTECTED]> Subject: Re: Encryption Project Date: Tue, 26 Sep 2000 08:44:22 GMT Robert Hulme wrote: > to be really sure the system is safe even if the NT box got > cracked I want to encrypt the records in the database... [...] > In particular I wonder if people could help me with if this: > > a) makes any sense :0) > b) has any glaring security holes > c) what encryption I should use ? If there are just a couple, mostly static fields to protect it might be reasonable. If you want to let users look up their recent transactions and such, then you'll run into problems. For example, the database isn't going be able to join a vendor record and a customer transaction record if the vendor ID in the transaction record is encrypted with the customer's key. Though the damage from a cracked system would be reduced, it doesn't really go away. The cracker could cause the system to collect passwords as users provide them. Also, keeping the database current seems to imply keeping the passwords around, unless you go to an even more complicated public-key system. You are not the first to have this problem, and I wish I could offer a good solution. We certainly need better security built into the foundation of our systems. I think adding a custom encryption layer on top would set you up for a maintenance nightmare. --Bryan -- email: bolson at certicom dot com Sent via Deja.com http://www.deja.com/ Before you buy. -- From: Tim Tyler <[EMAIL PROTECTED]> Subject: Re: Tying Up Loose Ends - Correction Reply-To: [EMAIL PROTECTED] Date: Tue, 26 Sep 2000 08:56:54 GMT Bryan Olson <[EMAIL PROTECTED]> wrote: : Tim Tyler wrote: :> Bryan Olson wrote: :> : Yes, you can work on reducing that constant. The mistake is :> : pretending it does something to the keyspace. :> :> It doesn't do anything to the keyspace. This was the point :> of my attempts to distinguish the "effective keyspace" :> from the actual keyspace. :> :> The "effective keyspace" contains the keys that can't be dismissed out :> of hand on a priori grounds - and may need further consideration. : The only attack you considered was exhaustive search. [...] I was discussing rejecting keys. This is rarely useful if the only attack available is brute force, due to the size of the keyspace. You need something more than this for rejecting keys to be useful. : Not one single key can be dismissed a priori. [...] That may - or may not - be true, depending on how much known plaintext is involved. :> I've said if this is likely to rub people up the wrong :> way then they are invited to present an alternative :> concise way of saying operation X "reduces the effective :> keyspace by five bits". : The problem is the meaning, not the wording. I'd suggest : "Makes testing each key faster most of the time." Good - but still not very quantitive. It would have to be "makes testing 31/32 keys faster, most of the time", in order to play the same role as my sentence is intended for. We /seem/ to be agreed on the meaning, the only question to my eyes is that of the wording. : [...] :> : If I give you a thousand bits of Blowfish (448-bit key) :> ciphertext and corresponding plaintext, what's the :> "effective keyspace"? :> :> Probably very small, to the point of being practically non-existent. :> The work required to reject each key is about as small as it can :> ever be expected to be, and - in all liklihood - enough information is :> supplied to be able to reject all but the correct key. : So try your search. If you cannot search a "practically : non-existent" "effective keyspace", then we have a good : indication that your effective keyspace concept is : misguided. I don't see why a failed search would lead to such a conclusion. "Effective" and "not-as-effective" are intended as relative terms. The "ineffective keyspace" contains keys that are ineffective relative to other keys.
Cryptography-Digest Digest #776
Cryptography-Digest Digest #776, Volume #12 Tue, 26 Sep 00 04:13:00 EDT
Contents:
Re: A Different Kind of Quantum Computer (SCOTT19U.ZIP_GUY)
Re: Tying Up Loose Ends - Correction (SCOTT19U.ZIP_GUY)
Re: Question on biases in random numbers & decompression (SCOTT19U.ZIP_GUY)
Re: NTRU question (actually truncated modular polynomial question) (Scott Contini)
Re: Tying Up Loose Ends - Correction (Guy Macon)
Re: Encryption Project ("kihdip")
Test for weak keys in 3DES ("kihdip")
Re: On block encrpytion processing with intermediate permutations (Bryan Olson)
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: A Different Kind of Quantum Computer
Date: 26 Sep 2000 03:46:00 GMT
[EMAIL PROTECTED] (John Savard) wrote in
<[EMAIL PROTECTED]>:
>On Mon, 25 Sep 2000 15:37:42 -0700, "A. Melon"
><[EMAIL PROTECTED]> almost wrote, in part:
>
>>Quantum computers can only solve problems in BQP, which is not thought
>>to include NP-complete problems. Now there is a new type of quantum
>>computer being proposed:
>
>>http://xxx.lanl.gov/abs/quant-ph/9910073
>
>>The paper claims this could solve NP-complete and sharp-P-complete
>>problems.
>
>>No, this isnt the End Of Cryptography As We Know It (EOCAWKI). Even if
>>the claims are true, it may be impossible to actually build. Even if
>>it is possible to build, it will be easy to make ciphers that defeat
>>it.
>
>>For example, make a random, public, invertible, 27x27 sbox, and
>>distribute it on CD-ROM. Encrypt a block by applying AES, then passing
>>it through the sbox (in groups of 27 bits), then applying AES again.
>>The sbox is only 432MB, so it is easy to distribute.
>
>Oh, dear. I have visions Scott27u now.
>
Well actually I know I did 4 8 16 and then 19.
I am quite happy with prime numbers for the future
ones so lets wait a few years till floppies
commonly hold several gigs and leap to scott29u
>>The quantum computer
>>would need millions of qbits to crack it.
>
>I wonder. There might be a meet-in-the-middle attack. Because the
>quantum computer's copy of the CD-ROM would *not* have to be in qbits,
>since the CD-ROM is fixed and public; the number of qbits only has to
>be the length of the secret key. But the non-qbit size of the problem
>might still create problems in avoiding decoherence or something.
>
Your correct John you have been reading more than Enigma
that is what I haver read also. Most systems to be modeled you
need only enough qbits to match the key length. But since most
still don't believe quantum computers exist. You may be wasting
your time telling those in this group.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website **now all allowed**
http://members.xoom.com/ecil/index.htm
Scott LATEST UPDATED source for scott*u.zip
http://radiusnet.net/crypto/ then look for
sub directory scott after pressing CRYPTO
Scott famous Compression Page
http://members.xoom.com/ecil/compress.htm
**NOTE EMAIL address is for SPAMERS***
I leave you with this final thought from President Bill Clinton:
--
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Tying Up Loose Ends - Correction
Date: 26 Sep 2000 04:00:43 GMT
[EMAIL PROTECTED] (Tim Tyler) wrote in <[EMAIL PROTECTED]>:
>Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
>
>
>: BTW, could you answer my question of whether Scott's
>: 1-1 scheme can deal with arbitrary boundaries, since
>: you are apparently fairly familiar with that?
>
>I believe David found that Matt Timmerman's scheme could be simply
>adapted to allow for abritrary block boundaries. IIRC David advised
>Matt of this, and Matt implemented it. I might be making all this up,
>though ;-|
>
>Anyway, on http://members.nbci.com/ecil/compres5.htm David has code that
>bijectively goes to and from Matt's finitely odd files - i.e. binary
>strings that end with a 1 followed by an infinite zero tail.
>
>The code...
>Converts to/from files made of any number of bytes;
>Converts to/from even byte length files;
>Converts to/from odd byte length files;
>Converts to/from 8 bytes multiple file.
>
>I don't know if David's used other types of granularity. I figure he
>knows how to do it if he wants to.
>
>His original compression programs only worked with byte-oriented files.
>I don't know if this has changed since I last looked at them.
>
>You could probably chain their output through the "finitely odd"
>convertors, if you wanted other types of granularity.
Your correct Tim. Thanks for anwsering Mok. I guess he is not the
kind of person I can communicate with so I think its best I stop answering
his posts. We never get anywhere I am left with the feeling that he never
gets any closer to understanding what I have done. I think Matt got his
idea of file endings from my huffman endings. But his is different
