Cryptography-Digest Digest #772, Volume #11 Sun, 14 May 00 18:13:01 EDT
Contents:
Re: S-BOX Construction Tutorial? (Mok-Kong Shen)
Analysis of the F function in Pikachu (Tom St Denis)
Re: About Hardware RNG (Tom St Denis)
Re: UK issue; How to determine if a file contains encrypted data? (zapzing)
Re: How does one test an encryption algorithm? (Terry Ritter)
Re: On higher level Feistel schemes (zapzing)
Re: S-BOX Construction Tutorial? (Terry Ritter)
Re: Notes on the "Vortex" block cipher (Terry Ritter)
Re: Question regarding authentication implementation (Anne & Lynn Wheeler)
Re: S-BOX Construction Tutorial? (Tom St Denis)
Re: S-BOX Construction Tutorial? (Tom St Denis)
Re: Notes on the "Vortex" block cipher (Tom St Denis)
Re: Question regarding authentication implementation (Anne & Lynn Wheeler)
----------------------------------------------------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: S-BOX Construction Tutorial?
Date: Sun, 14 May 2000 22:13:22 +0200
Tom St Denis wrote:
>
> Random sboxes are only secure if they are large (aka Blowfish style
> 8x32). Random 4x4 sboxes are often closer to linear then ideal...
I suppose it is much better to use the 6x4 S-boxes of the kind of
DES rather than 4x4 ones. If all 16 rounds have different S-boxes,
I am not sure that using random ones is not a quite good idea.
M. K. Shen
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Analysis of the F function in Pikachu
Date: Sun, 14 May 2000 19:59:26 GMT
Here are some more thoughts.
My F function is basically...
Input: X, key1, key2 (all 32 bits)
1. X = X xor key1
2. (A, B, C, D) = X
3. 2PHT(A, B), 2PHT(C, D), 2PHT(D,A) 2PHT(B, C)
4. A = SB1[A], B = SB2[B], C = SB3[C], D = SB4[D]
5. X = (A, B, C, D)
6. return (X <<< 1) xor key2
(Each round uses unique key1/key2 32-bit keys)
Some questions...
1. What will the initial xor'ing prevent? I put it there to make
controlling the inputs to the PHT hard todo. Is this accomplished? I
think so...
2. The PHT promotes avalanche, but has wickedly bad differential
properties. Are there betters ways that promote just as good avalanche?
3. The sboxes are designed with sboxgen to be non-linear, yadadada.
Has this been accomplished? Is there any noteworthy tidbits about the
sboxes?
4. The final rotate is to destroy byte alignment so the same 'bytes'
don't go thru the same sboxes. It was also designed to mess up linear
cryptanalysis abit (but I admit that was not a major reason for putting
it there when I wrote the cipher). Is it required? Apparently so
according to David. How much 'security' is gained in the eyes of
linear cryptanalysis by using it?
5. The final key xor is to hinder working backwards through the F
function. Is this accomplished? Is it required from a cryptographic
standpoint? Would the F function be easier to attack without it?
Hopefully this can spark some attacks on Pikachu (I wanna see this
thing fall big time!!!).
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: About Hardware RNG
Date: Sun, 14 May 2000 20:05:42 GMT
In article <8fmt2k$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Guy Macon) wrote:
> In article <8fmhqq$kib$[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Tom
St Denis) wrote:
> >
> >In article <kezT4.357$[EMAIL PROTECTED]>,
> > "Steve and Darla Wells" <[EMAIL PROTECTED]> wrote:
> >> Although such circuits generate entropy, they typically generate
> >detectable
> >> weaknesses through either interference coupling and/or bias with
the
> >> environment. Be sure to post process the result well.
> >
> >The device I am building will feed the output to a data pin on a AVR
> >2313, which will hash it (using MD2). I currently have it set to
hash
> >256 bytes downto 16 bytes before outputting.
> >
> >The device will be the size of a wallet and have a simple RS-232
> >interface. A tiny TTY host in the AVR will allow the users to
> >request 'x' amount of bytes, afterwhich the device will go to sleep
> >mode.
> >
> >I hope to build a prototype this week (I want to make an AVR eval
> >board, and just stick the RNG device on it).
>
> Your use of a hash implies that you expect the output to a data pin on
> the AVR 2313 to be less than perfectly random. Would you care to list
> what kind of biases you expect and how severe you expect them to be?
>
The CPU I use is irrevelant to the bias of the RNG (they are separate
devices... I just mentioned the CPU to be interesting)... Anyyways.
It's not entirely uncommon to get less then perfect entropy from a
hardware RNG. I would epect to see a bias of about 0.01 at the most
towards any bit. This means there is something like 0.98 bits of
entropy per bit of RNG output. Ideally I want to avoid this at all
cost.
So let's assume there is 0.7 bits per bit of RNG output. If I hash
1000 bits (700 bits of entropy) downto 128 bits. I should reasonably
expect the 128 bits to have closer to 1.0 bits per bit of entropy.
Therefore, the output from the hash will be less predictable.
Although I don't think my 256 to 16 ratio is appropriate, more like 64
to 16 (4:1), or 512 to 128. Which means with the 0.7 quoted above
(which is not a real value, I just made it up) I would have 358.4 bits
of entropy going into the hash, and 128 comming out.... Still in good
order.
As long as the bits per bit doesn't go under 0.25 I am set. Of course
at a 4:1 ratio (and sampling every 1ms or so) it will take over half a
second (about 513 ms) to get 128 bits out. This means making a 1024
bit RSA key would take about 47.3 minutes. Obviously you have to seed
a strong prng with about 256 bits and use that instead...
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: zapzing <[EMAIL PROTECTED]>
Subject: Re: UK issue; How to determine if a file contains encrypted data?
Date: Sun, 14 May 2000 20:21:00 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> On Sun, 14 May 2000 02:26:24 GMT, zapzing <[EMAIL PROTECTED]> wrote:
>
> <snip>
>
> >>
> >> The critical challenge to the UK law will not be using stenography
to
> >> hide the cipher text, but rather devising encryption apps that give
no
> >> appearance of being an encryption app.
> >>
> >> So who is going to be the first person to devise an encryption app
> >> that is itself completely hidden and undetectable?
> >>
> >>
> >But you could have a perfectly good reason
> >for having that encryption app around
> >Perhaps you actually do use encryption to
> >send email to friends. Some files might just
> >use a different key that you deny the
> >existence of, that's all.
> >You would give the police the key to your
> >emails that you send to your "cover" friends.
> >the other files, you say 'Gosh, I don't
> >really know what that is".
>
> Yes, I was supposing that most apps have a keyring which would give
> away the existence of the other keys. So perhaps one doesn't need to
> hide the app, but one does need the capacity to hide the existence of
> keys.
>
> Beyond the UK, in countries where the simple possession of an
> encryption app might result in incarceration or even torture without
> trial, I suspect an app that is itself hidden would be a decided
> advantage. Especially since with the growing complexity of OSs, use
> of caches, registry keys, etc etc, it is getting beyond the capacity
> of all but the most sophisticated users to hide or remove all traces
> of an app. and its use.
>
> In such a situation, I suspect I'd use PGP loaded to a virtual drive
> from a floppy on a DOS only machine, making sure the disk was removed
> and physically hidden and secure when not in use.
Yes. I suppose that some people may live in countries
where they have no access to keyring-less
encryption apps. So your question about hiding
apps is an important one.
I suppose that it would depend havig access to
a compiler.And certainly you would not fall
under suspicion for having some arbitrary
precision libraries around. Then you would just
have to enter a simple ciher every time you booted
up. After all the mathematcal structure of PGP
is really very simple and would be no trouble
to enter in. This simple cipher would be used
to decrypt the actual app.
Or perhaps you could go a different route
by just deleting the keyring and reentering it
every time.
--
Do as thou thinkest best.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: How does one test an encryption algorithm?
Date: Sun, 14 May 2000 20:32:08 GMT
On Sun, 14 May 2000 15:39:25 GMT, in <[EMAIL PROTECTED]>,
in sci.crypt [EMAIL PROTECTED] (Bruce Schneier) wrote:
>On Thu, 11 May 2000 00:37:29 GMT, [EMAIL PROTECTED] wrote:
>
>>I have an dynamic encryption algorithm and it needs to be tested. Is
>>there a newgroup or a group of freelance hackers :-) or some place
>>where I could test by hiring services.
>>
>>All I want to know is that if my algorithm is tough to crack.
>>
>>How does one estimate the confidence factor of an encryption algorithm?
>>Are there any metrics defined?
>
>See:
>
> http://www.counterpane.com/crypto-gram-9810.html#cipherdesign
...where we see the same old pablum about getting experts to "analyze"
the cipher, and then -- somehow -- leaping to a belief in its
strength.
Absent a mathematical proof of strength in practice, there is no
scientific basis for a belief in cipher strength. Indeed, the entire
history of cryptography has been about the unexpected weakness of
commonly-accepted ciphers.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
From: zapzing <[EMAIL PROTECTED]>
Subject: Re: On higher level Feistel schemes
Date: Sun, 14 May 2000 20:29:09 GMT
In article <[EMAIL PROTECTED]>,
Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
>
>
> David Blackman wrote:
>
> > I think speed is the problem. A Feistal scheme needs at least
> > 3 rounds to be secure, even if the F is "perfect". So to double
> > your block size you will take at least 3 times as long to encrypt
> > a block. That means you are slower per byte than the original
> > smaller cypher (but probably more secure if you don't do anything
> > silly).
> >
> > The "DEAL" cypher that was a AES candidate used your approach.
> > There were 6 or 8 rounds. The small encryption algorithm used
> > was DES. DEAL was dropped because it was very slow. Some minor
> > security problems were found as well, so obviously this approach
> > still requires some care, like anything else in cryptography.
> >
> > Several of the AES candidates show you can do 128 bit cyphers
> > by other methods that look extremely secure and actually run
> > faster per byte than good 64 bit cyphers.
>
> Thanks for the informations. There can be no question that an 128
> bit cipher designed as such should be much faster than one obtained
> from a comparable 64 bit cipher using the Feistel scheme. However,
> in case (for some reasons) one doesn't yet have an appropriate 128
> bit cipher ready, then using the Feistel scheme appears to be one of
> the viable ways out in my humble view.
>
I definitely agree, and if anyone knows about
a 128 or larger chip that is available, pls
let us know.
--
Do as thou thinkest best.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: S-BOX Construction Tutorial?
Date: Sun, 14 May 2000 20:43:51 GMT
On Sun, 14 May 2000 15:53:28 GMT, in <8fmi5k$kl1$[EMAIL PROTECTED]>, in
sci.crypt Tom St Denis <[EMAIL PROTECTED]> wrote:
>In article <[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] (Terry Ritter) wrote:
>>
>> On Sat, 13 May 2000 14:49:10 -0700, in
>> <8fjm8v$nqr$[EMAIL PROTECTED]>, in sci.crypt "Simon Johnson"
>> <[EMAIL PROTECTED]> wrote:
>>
>> >Does any one have a PDF or HTML S-BOX construction tutorial?
>> >If So please, leave a post with the URL as a reply to this message
>thanxs.
>>
>> "S-boxes" are used in different ways in different ciphers, making
>> different things more or less important. Any particular construction
>> approach probably will be oriented toward a particular design, and the
>> approach you need should be oriented toward your particular needs.
>
>Some overall characteristics such as linearness and differential xor-
>pair tables are universally important. If your sbox is a linear
>mapping of Fn -> Fm then it's kinda useless isn't it?
That depends upon what one wants to do. Now, an "identity
transformation" *would* be useless . . . unless of course that happens
to be the extremely-improbable side-effect of choosing tables at
random. There is *always* a possibility of weakness in ciphering: An
opponent just might happen to choose the right key at random.
>> Typically, a modern S-box has an even binary power number of elements
>> (e.g., 2**4 or 16, 2**8 or 256, etc.). There is one element of each
>> possible value and these are permuted or shuffled. Up to this point,
>> all we need to know is how to count and how to shuffle.
>>
>> Some designs use "small" (e.g., "4-bit") S-boxes, but such small boxes
>> are often weak, and so should be tested before being used. There are
>> various tests including diffusion, Boolean function nonlinearity,
>> etc., with at least one new test found for every new attack on S-box
>> structure. An alternative is to use "large" ("8-bit" or larger)
>> S-boxes, but that is a cipher design decision.
>
>Yeah I agree with the less-non-linearness of small sboxes, but can you
>point me to an attack on Serpent that relies on the sboxes?
That is a fundamentally wrong question: If we must actually break a
cipher to consider it weak, we will never have time to show just how
weak our many ciphers may be. It is unreasonable to simply assume
that a cipher strong unless explicitly proven weak. Just because you
don't see a way to exploit the problem is no reason to allow the
problem to exist to somehow be exploited.
My approach is to try to eliminate every ghost of weakness I can see.
I suppose others have different approaches.
>> DES-style ciphers often have a fixed set of boxes; that means
>> opponents will know the complete structure, thus making their attacks
>> that much easier. An alternative is to key-select each box "at
>> random" from among all possible permutations, but that is another
>> cipher design decision.
>
>Random sboxes are only secure if they are large (aka Blowfish style
>8x32).
A simple "8-bit" S-box is "large enough," as long as we don't depend
upon just one.
>Random 4x4 sboxes are often closer to linear then ideal...
Far, FAR closer.
>Question: has anyone tried a 128-bit blowfish by using eight 8x32
>sboxes? Seems to me it would require only 8kb of ram which isn't
>prohibitive on desktop computers...
What are you talking about? Modern computers almost always have at
least 64MB nowadays. 8kB is nothing.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: Notes on the "Vortex" block cipher
Date: Sun, 14 May 2000 20:46:31 GMT
On Sun, 14 May 2000 15:45:04 GMT, in <8fmhlt$k30$[EMAIL PROTECTED]>, in
sci.crypt Tom St Denis <[EMAIL PROTECTED]> wrote:
>[...]
>Yeah but in blowfish all of the input goes thru the sboxes. So you
>can't just say "Blowfish is similar so my cipher must be secure too".
...especially since there is no way to know that Blowfish is secure in
the first place.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
Subject: Re: Question regarding authentication implementation
Reply-To: Anne & Lynn Wheeler <[EMAIL PROTECTED]>
From: Anne & Lynn Wheeler <[EMAIL PROTECTED]>
Date: Sun, 14 May 2000 21:11:03 GMT
Abid Farooqui <[EMAIL PROTECTED]> writes:
> My colleague is certainly not doing this because when the certificate queue is
>loaded,
> he strips off everything from the certificate and only the public key is loaded and
> hence there is little chance that he is verifying the validity of the digital
>signature
> by referring to the contents of the accompanying certificate as he does not actually
> have the whole certificate loaded into the queue, only the public keys.
> Also keep in mind that we are selling this product and claiming that it uses CADS
>model
> (Certificate Authority Digital Signature model) and not AADS (Account Authority
>Digital
> Signature model) whose draft I believe is submitted to IEEE by First Data Corp and I
>am
> not sure of the status of the draft at this point. Anyway my question remains, is my
> colleagues practices and logic in accordance with the traditional PKI practices and
> procedures (CADS model). If not then I have to raise a red flag.
> Any input in this regard is appreciated.
> Sincerely,
> Abid Farooqui
The CADS model has been considered to have grown out of offline email
requirement in the early to mid 80s where an end-user connected to the
network, downloaded their email, and disconnected. They then was left
with the opportunity of validating the email in a standalone, end-user
environment with little or no business and supporting infrastructure.
There was also high possibility that the incoming email was from
source that the receiver had no little or prior business knowledge.
The AADS model somewhat grew out of situation involving existing
business and supporting infrastructures that are already in place for
authentication ... but may have been shared-secret based (ISP password
login, radius password , PIN debit financial transaction, web server
password login, call-center asking for mother's maiden name &/or SSN,
datacenter password login, etc). These environments also tended to
have business infrastructures that dealt primarily with other entities
for which they had existing &/or prior business relationships (you
logged into an established userid, signed in as an employee, accessed
existing financial account).
In this scenerio, a certificate attached to every message &
transaction represented stale, redundant, & superfulous copy of
information that was being maintained in the businesses account
records (or business equivalent that represented established
relationship between the parties).
Some of the situations also had other business requirements, like
existing message traffic was in 60-80 byte range in a network
operating at near capacity. Appending a 1000+byte certicate to a large
number of such messages not only represented stale, redundant and
superfulous information transfer ... but also a heavy infrastructure
traffic burden.
An certificate analogy is letters of credit/introduction in the days
of sailing ships prior to telephones, faxes, and online environments
(i.e. the stale, redundant information in a certificate can enable
distributed, offline authentication for environments that don't have
online realtime access to the original copy of the information).
X9.59 is an ANSI financial industry draft standard for all
account-based electronic retail payments that can be deployed using an
AADS model ... i.e. existing business relationships, online realtime
access to the database processing factilities that instantiate the
business relationships, existing relatively small messages sizes with
high capacity existing networks than periodically operate near
saturation where certificate represents stale, redundant and
superfulous information transmission as well as several hundred
percent message size bloat.
--
Anne & Lynn Wheeler | [EMAIL PROTECTED], [EMAIL PROTECTED]
http://www.garlic.com/~lynn/ http://www.adcomsys.net/lynn/
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: S-BOX Construction Tutorial?
Date: Sun, 14 May 2000 21:06:03 GMT
In article <[EMAIL PROTECTED]>,
Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
>
>
> Tom St Denis wrote:
>
> >
> > Random sboxes are only secure if they are large (aka Blowfish style
> > 8x32). Random 4x4 sboxes are often closer to linear then ideal...
>
> I suppose it is much better to use the 6x4 S-boxes of the kind of
> DES rather than 4x4 ones. If all 16 rounds have different S-boxes,
> I am not sure that using random ones is not a quite good idea.
>
> M. K. Shen
While it's true that 6x4 sboxes 'can' be better then a single 4x4
sbox. Random 6x4 sboxes are hardly perfect all the time.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: S-BOX Construction Tutorial?
Date: Sun, 14 May 2000 21:12:56 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Terry Ritter) wrote:
>
> On Sun, 14 May 2000 15:53:28 GMT, in <8fmi5k$kl1$[EMAIL PROTECTED]>, in
> sci.crypt Tom St Denis <[EMAIL PROTECTED]> wrote:
>
> >In article <[EMAIL PROTECTED]>,
> > [EMAIL PROTECTED] (Terry Ritter) wrote:
> >>
> >> On Sat, 13 May 2000 14:49:10 -0700, in
> >> <8fjm8v$nqr$[EMAIL PROTECTED]>, in sci.crypt "Simon
Johnson"
> >> <[EMAIL PROTECTED]> wrote:
> >>
> >> >Does any one have a PDF or HTML S-BOX construction tutorial?
> >> >If So please, leave a post with the URL as a reply to this message
> >thanxs.
> >>
> >> "S-boxes" are used in different ways in different ciphers, making
> >> different things more or less important. Any particular
construction
> >> approach probably will be oriented toward a particular design, and
the
> >> approach you need should be oriented toward your particular needs.
> >
> >Some overall characteristics such as linearness and differential xor-
> >pair tables are universally important. If your sbox is a linear
> >mapping of Fn -> Fm then it's kinda useless isn't it?
>
> That depends upon what one wants to do. Now, an "identity
> transformation" *would* be useless . . . unless of course that happens
> to be the extremely-improbable side-effect of choosing tables at
> random. There is *always* a possibility of weakness in ciphering: An
> opponent just might happen to choose the right key at random.
Which means the keyspace isn't flat. That's a bad thing.
>> Typically, a modern S-box has an even binary power number of elements
> >> (e.g., 2**4 or 16, 2**8 or 256, etc.). There is one element of
each
> >> possible value and these are permuted or shuffled. Up to this
point,
> >> all we need to know is how to count and how to shuffle.
> >>
> >> Some designs use "small" (e.g., "4-bit") S-boxes, but such small
boxes
> >> are often weak, and so should be tested before being used. There
are
> >> various tests including diffusion, Boolean function nonlinearity,
> >> etc., with at least one new test found for every new attack on S-
box
> >> structure. An alternative is to use "large" ("8-bit" or larger)
> >> S-boxes, but that is a cipher design decision.
> >
> >Yeah I agree with the less-non-linearness of small sboxes, but can
you
> >point me to an attack on Serpent that relies on the sboxes?
>
> That is a fundamentally wrong question: If we must actually break a
> cipher to consider it weak, we will never have time to show just how
> weak our many ciphers may be. It is unreasonable to simply assume
> that a cipher strong unless explicitly proven weak. Just because you
> don't see a way to exploit the problem is no reason to allow the
> problem to exist to somehow be exploited.
>
> My approach is to try to eliminate every ghost of weakness I can see.
> I suppose others have different approaches.
Conversely why is it a problem if it cannot be exploited? Using finite
sized keys is a problem of *all* symmetric ciphers, but is that cause
for alarm?
> >> DES-style ciphers often have a fixed set of boxes; that means
> >> opponents will know the complete structure, thus making their
attacks
> >> that much easier. An alternative is to key-select each box "at
> >> random" from among all possible permutations, but that is another
> >> cipher design decision.
> >
> >Random sboxes are only secure if they are large (aka Blowfish style
> >8x32).
>
> A simple "8-bit" S-box is "large enough," as long as we don't depend
> upon just one.
Hmm thanks for the idea. But I think random 8-bit permutations are
required otherwise the output can be very degenerative...
Then again you get upto 2^16 variants of a static sbox by simply doing
x' = S[x xor k1] xor k2
or
x' = S[S[x xor k1] xor k2]
or
x' = S1[S2[x xor k1] xor k2]
The latter uses two 8x8 sboxes... but you get the point...
Then again doesn't twofish use something like the latter?
> >Random 4x4 sboxes are often closer to linear then ideal...
>
> Far, FAR closer.
>
> >Question: has anyone tried a 128-bit blowfish by using eight 8x32
> >sboxes? Seems to me it would require only 8kb of ram which isn't
> >prohibitive on desktop computers...
>
> What are you talking about? Modern computers almost always have at
> least 64MB nowadays. 8kB is nothing.
Hehehe, I made a 128-bit blowfish using 8 8x32 sboxes... it works well
but I doubt it's very usefull...
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Notes on the "Vortex" block cipher
Date: Sun, 14 May 2000 21:14:48 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Terry Ritter) wrote:
>
> On Sun, 14 May 2000 15:45:04 GMT, in <8fmhlt$k30$[EMAIL PROTECTED]>, in
> sci.crypt Tom St Denis <[EMAIL PROTECTED]> wrote:
>
> >[...]
> >Yeah but in blowfish all of the input goes thru the sboxes. So you
> >can't just say "Blowfish is similar so my cipher must be secure too".
>
> ...especially since there is no way to know that Blowfish is secure in
> the first place.
There has been some scrutiny of blowfish. I would trust it.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
Subject: Re: Question regarding authentication implementation
Reply-To: Anne & Lynn Wheeler <[EMAIL PROTECTED]>
From: Anne & Lynn Wheeler <[EMAIL PROTECTED]>
Date: Sun, 14 May 2000 21:52:32 GMT
as an aside, NIST in the past has written standards from scratch like
FIPS-186 for authentication, digital signatures standards. NIST has a
statement someplace that says that it will be considering the direct
adoption of industry standards for FIPS. FIPS-186-2 and X9.62 had a
lot of work done in common.
in any case the other way of looking at it is basd on X9F1 work on
x9.68 certificate compression, i.e. if the receiving/relying party
already has the information, the field can be compressed out of the
certificate. AADS with knowledge analysis of the business process
shows 100% field compression resulting in zero byte certificates
(i.e. certificates aren't eliminated, they are reduced to zero bytes).
The other scenerio is the certificate chain attachment. Certificates
that the receiving/relying party can reasonably be expected to
have/obtain, can be eliminated from the certificate chain (say in SSL
protocol where the browser already has database of self-signed root
certificates). If various AADS scenerios, where the receiving/relying
party can be shown to already have all the certicates ... then the
certificate chain can be compressed to zero certificates.
misc. refs
http://www.garlic.com/~lynn/ansiepay.htm#aadsnwi2
http://www.garlic.com/~lynn/2000.html#36
http://www.garlic.com/~lynn/2000.html#37
http://www.garlic.com/~lynn/2000.html#39
http://www.garlic.com/~lynn/2000.html#40
http://www.garlic.com/~lynn/2000.html#41
http://www.garlic.com/~lynn/2000.html#42
http://www.garlic.com/~lynn/2000.html#45
http://www.garlic.com/~lynn/2000.html#46
http://www.garlic.com/~lynn/2000.html#47
http://www.garlic.com/~lynn/2000.html#48
http://www.garlic.com/~lynn/2000b.html#40
--
Anne & Lynn Wheeler | [EMAIL PROTECTED], [EMAIL PROTECTED]
http://www.garlic.com/~lynn/ http://www.adcomsys.net/lynn/
------------------------------
** 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
******************************
