Cryptography-Digest Digest #513, Volume #12 Wed, 23 Aug 00 09:13:01 EDT
Contents:
Re: New algorithm for the cipher contest (Mark Wooding)
Re: Questions about Rijndael (Mark Wooding)
Re: help needed to break KRYPTOS ([EMAIL PROTECTED])
Re: OH NO! (Mark Wooding)
Re: Dissapearing email (Eric Hambuch)
Re: Little help (Eric Hambuch)
Re: Little help (Keijo Ruohonen)
Re: Questions about stream cipher (Mark Wooding)
An interesting cryptographic problem ([EMAIL PROTECTED])
Re: The DeCSS ruling (Gisle =?iso-8859-1?Q?S=E6lensminde?=)
Re: blowfish problem (Richard Bos)
DES weak keys in 3DES (Gisle =?iso-8859-1?Q?S=E6lensminde?=)
Re: My unprovability madness. (Nathan the Great)
Re: The DeCSS ruling (Jim Steuert)
need hlep about "certificate validation" for x509 format (haifeng)
Re: Questions about stream cipher ([EMAIL PROTECTED])
Re: Comment from Hardware Experts Please ([EMAIL PROTECTED])
Re: Questions about stream cipher ([EMAIL PROTECTED])
about certificate validation (haifeng)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: New algorithm for the cipher contest
Date: 23 Aug 2000 09:15:46 GMT
David A. Wagner <[EMAIL PROTECTED]> wrote:
> Fascinating. The round function is
> X_{i+1} := (X xor K_{i,0}) * K_{i,1} mod 2^64,
> and there are four rounds. That's it. Now that's simplicity.
There's some end-for-end bit reversal there too.
Denote mirroring by M(.). I'll order the keys so that K'_{2i} is an XOR
key and K'_{2i+1} is a multiplication key. The round function is then
x'_{i+1} = M(x'_i \xor K'_{2i}) * K'_{2i+1}
= (M(x'_i) \xor M(K'_{2i}) * K'_{2i+1}
Now rewrite K_{2i} = M(K'_{2i}), K_{2i+1} = K'_{2i+1}, x_i = M(x'_i).
Then I believe we have
x_{i+1} = M((x'_i \xor K_{2i}) * K_{2i+1})
as an equivalent description, which at least puts the mirror operation
between the rounds. This rewrite also shows that only three of the
mirror operations contribute to the cipher's strength.
I believe that the 192-bit variant should have an extra round, but I
don't have a concrete attack to justify this feeling yet.
> If the middle xor is changed to addition, then I _think_ there is a
> boomerang attack (unverified). But the xor destroys the boomerang.
>
> If you consider a three-round variant, I _think_ there is a similar
> boomerang (unverified). But four rounds seems to kill the attack.
>
> It's an appealingly-simple cipher. But can it really be secure?
> Very interesting...
Indeed.
Oh, by the way, could someone please stop Tom from being so obnoxious?
-- [mdw]
------------------------------
From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: Questions about Rijndael
Date: 23 Aug 2000 09:25:54 GMT
Mark Wooding <[EMAIL PROTECTED]> wrote:
> If you don't care about low-end software, you might be able to get
> away with having four S-boxes and use one of them in each of the four
> rows of the state. You can then combine the column of four S-boxes
> with the \theta-operation in four tables, which would use the same
> amount of memory as optimized Square and Rijndael implementations use
> anyway. I believe (and maybe David Wagner or someone else clever will
> correct me if this is wrong) that this will offer much improved
> resistance to the Square attack[1].
Nope. Everyone must have been asleep. The above, I now realise, is
twaddle.
Using different S-boxes in different parts of the state, and even a
different S-box for every byte in every round will do nothing whatever
to resist the Square attack.
I think this is a real shame. It points to a major failing in the
(really lovely) Square structure. I think the real problem is the
relatively weak inter-column mixing. I'm not sure how best to fix it.
-- [mdw]
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: help needed to break KRYPTOS
Date: Wed, 23 Aug 2000 09:15:43 GMT
first of all, thank you Douglas for your answer;
...and second:
i've not well understood your last sentence:
> ...could indicate that the method of
> encipherment involved as its last stage finding the
> ciphertext character at some coordinates (determined
> by key and plaintext) within a normal sequence A..Z.
>
may you give me a very brief example of it ??
thanks a lot again
Ferdinando
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: OH NO!
Date: 23 Aug 2000 09:32:16 GMT
[EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> My parents are going to lose their home if I cannot raise $1,000 by
> next week! I would appreciate if everyone could donate money to me by
> sending a donation through paypal to [EMAIL PROTECTED]!
Yeah, right.
What was your cryptography question again?
-- [mdw]
------------------------------
From: Eric Hambuch <[EMAIL PROTECTED]>
Subject: Re: Dissapearing email
Date: Wed, 23 Aug 2000 11:38:05 +0200
pratik khasnabis wrote:
>
> Hi
> I sometimes read this ng and I'm not a mathematician or cryptographer.As
> a communication engg. I know a little about cryptography and is
> interested in practical applications.Today I read the story about
> dissapearing emails. I have included the hyperlinks at the end. I want
> to know how is it possible by this technique to automatically send the
> encrypted message to the Disappearing access server and get it
> decrypted. How to prevent the message on screen to be copied and pasted.
You can't. Many people even print their emails and store them on paper
(an important business letters have to be stored!).
So "disappearing email" doesn't really work. The security of this system
has been discussed some months ago here.
Maybe you will find these article useful:
http://www.telepolis.de/tp/english/inhalt/te/5395/1.html
It describes how "disappearing email" works und comments on it.
Eric
------------------------------
From: Eric Hambuch <[EMAIL PROTECTED]>
Subject: Re: Little help
Date: Wed, 23 Aug 2000 11:46:14 +0200
Sergio Arrojo wrote:
>
> Hi
>
> I am an unexperienced student, so my question might be a bit stupid. I was
> told to make some Software to implement elliptic curves over GF(2^m). I made
> a very simple example with MATLab which was able to operate only with very
> small numbers. Then I was told to translate to C and to simulate with
> realistic values. The idea was to use a Linux compilator that enabled using
> unlimited variables. Soon I saw that I would not be able to end this task. I
> was told that this Software is actually quite difficult to design. Since I
> (as dumb as I am) was able to make a simplified example that worked with
> tiny numbers I assume that the tricky thing is to generate the curves (and
> to simulate ECC) in a reasonable amount of time (less than 10^99 centuries)
> when operating with really big numbers. Am I right, or am I missing
> something here?
Yes,
1. you have to work with big numbers (so you can't use standard types
like "integer" or "long").
2. you have to generate "secure" elliptic curves. I suggest to read the
paper "R.Lercier: Finding Good Random Elliptic Curves for Cryptosystems,
EUROCRYPT'97" (Try:
http://www.counterpane.com/biblio/all-by-author.html)
Maybe the "Handbook of Applied Cryptography" at
http://cacr.math.uwaterloo.ca/hac can be useful, too!
Eric
------------------------------
From: Keijo Ruohonen <[EMAIL PROTECTED]>
Subject: Re: Little help
Date: 23 Aug 2000 10:22:55 GMT
In article <8nvurn$hb3$[EMAIL PROTECTED]>
Sergio Arrojo, [EMAIL PROTECTED] writes:
>Hi
>
>I am an unexperienced student, so my question might be a bit stupid. I was
>told to make some Software to implement elliptic curves over GF(2^m). I made
>a very simple example with MATLab which was able to operate only with very
>small numbers. Then I was told to translate to C and to simulate with
>realistic values. The idea was to use a Linux compilator that enabled using
>unlimited variables. Soon I saw that I would not be able to end this task. I
>was told that this Software is actually quite difficult to design. Since I
>(as dumb as I am) was able to make a simplified example that worked with
>tiny numbers I assume that the tricky thing is to generate the curves (and
>to simulate ECC) in a reasonable amount of time (less than 10^99 centuries)
>when operating with really big numbers. Am I right, or am I missing
>something here?
>
You are quite right there. A good way for the uninitiated to learn
about implementation of ECC in GF(2^m) is to read
Rosing, M.: Implementing Elliptic Curve Cryptography.
Manning Publications (1998).
It contains the crucial points, and lots of C code.
Keijo Ruohonen
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%NULLIUS%IN%VERBA%
Keijo Ruohonen Tampere University of Technology
[EMAIL PROTECTED] Department of Mathematics Voice (+358) (3) 3652420
http://matwww.ee.tut.fi/ Tampere, FINLAND Fax (+358) (3) 3653549
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
------------------------------
From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: Questions about stream cipher
Date: 23 Aug 2000 10:23:37 GMT
Runu Knips <[EMAIL PROTECTED]> wrote:
> This should read 'SEAL is the only stream cipher so far which is able
> to do random seeking'. Well and you, Tom, had a design which tried the
> same recently.
No, SEAL can't do random seeking.
-- [mdw]
------------------------------
From: [EMAIL PROTECTED]
Subject: An interesting cryptographic problem
Date: Wed, 23 Aug 2000 10:29:23 GMT
[this is a fairly lengthy posting, for which I apologise, but the
problem is a complex one to explain]
Modern line-of-business systems typically rely on a relational database
to store information. A user supplies a set of credentials
(login,password) to the system and is then connected to the RDBMS.
A naive implementation of such a system (and unfortunately, this is a
common implementation) simply forwards the user's credentials to the
RDBMS and if the RDBMS validates them, the user is directly connected.
The problem with such an implementation is that the user must often be
given quite broad rights to database tables in order for the line-of-
business application to function correctly. Although most modern RDBMS
products have excellent security systems, enforcing table-level
security is tedious and in many cases causes the application code to
malfunction, because it was written with the assumption that full
permissions to the base tables are available.
Because the user can easily access the database using third-party query
and reporting tools, any application-level security is easily bypassed.
This leads to serious security weaknesses and potential audit
nightmares.
In order to circumvent this problem, some systems map the user's
credentials indirectly to a database logon and password. By doing so,
it is intended that the user cannot guess the actual database
credentials and therefore, although the 'secondary login' has quite
broad rights, the user would not be able to access the database through
third party tools since their primary login credentials do not map to a
database login.
Although this concept is sound in theory, implementation is
problematic. If the transform from user credentials (username,password)
to database login (username-prime,password-prime) is via a fixed
algorithm, i.e security through obfuscation, then a disgruntled
employee or ex-employee of the software company can penetrate any
customer's system, since they know the transform.
The alternative is to encrypt the user credentials {u,p} to create
{u',p'} via a well-known encryption algorithm such as DES. In this
case, an encryption key must be provided.
If the encryption key is site-specific, then an attack by an ex-
employee is more difficult since although the algorithm is known, the
key is not. However, the application software must somehow retrieve the
key in order to perform the transform.
The problem is therefore to secure the key in such a way that the
application software can retrieve it programmatically yet a
knowledgeable outsider could not do so. This means that simply
sprinkling the key around a large file and knowing the bit offsets
won't do, if these offsets are stored in a program, you might as well
have stored the key.
While it is also obvious to think of public-key encryption as somehow
offering an answer, this does not seem apparent. While PK systems solve
the problem of key interchange between cooperating parties, they do not
solve this problem, since encryption and decryption must be essentially
automated.
Does anyone know of any research that has been done in this area?. For
example, might it be possible to use an infrastructure such as Kerberos
in order to grant a ticket which would allow access to an RDBMS?
Since most RDBMS products don't integrate directly with authentication
services such as Kerberos, there has to be some secure way to transform
a ticket into a set of logon credentials.
Essentially any solution, however it is implemented must
1. Work with RDBMS products for which the only authentication mechanism
is to supply a login and password
2. Prevent a user from determining the actual login and password used
to connect to the RDBMS, even though the user knows their own login
credentials.
3. Prevent a knowledgeable outsider from penetrating the system by
avoiding a fixed algorithm.
I should be most interested if anyone can offer any assistance in this
area. Because all good security systems are absolutely open in their
implementation, I would much prefer to discuss these issues openly in
this forum rather than via email.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (Gisle =?iso-8859-1?Q?S=E6lensminde?=)
Subject: Re: The DeCSS ruling
Date: 23 Aug 2000 12:58:31 +0200
In article <[EMAIL PROTECTED]>, Pekka Ala-M�yry wrote:
>lcs Mixmaster Remailer wrote:
> ...
>> A note: In the Europeon Union reverse-engineering is legal.
>> The reverse engineering was not done in the United States.
>
>In Finland reverse engineering of software if illegal. When I checked
>the situation in the EU I found "391L0250 Council Directive 91/250/EEC
>of 14 May 1991 on the legal protection of computer programs" which is
>seeminly identical to that of Finland legistlation. So I dare to say
>that it is illegal also in Europe. If I remember right this was the
>reason for action of the Norvegian Police.
>
>Ref: http://europa.eu.int/eur-lex/en/lif/dat/1991/en_391L0250.html
The intention of this law is to allow revese engineering
if there is sensible reason for doing so. If the reason was to develop a
player for Linux, it's legal, but not if the intention is to
make unatorized copies. The problem is that this becomes a question of
intention of the one doing the reverse engineering. Jon Johansen must
prove for the court that he was not doing this
in order to make illegal copies.
A difference between the European union law and the Norwegian,
that applies for Jon Johansen, is that the Norwegian law says
somthing like: "No agreement can make an exception from this right".
In other words, a licence that forbids any revese engineering will
be illegal according to Norwegian law. I cannot find such a rule in
the EU laws, and I don't know how courts in the European Union will
do in cases where reverse engineering is forbidden by agreement,
like I think is the case for DVD.
I know that the central European court tradition is more restrictive
in how far an agreement can go compared to the American tradition,
so it's possible that such a agreement not would have been legal
anyway, but I'm not a lawyer, and as far as I know, there has been
no supreme court decisions in any European country regarding this
law.
>
>Decompilation
>
>1. The authorization of the rightholder shall not be required where
> reproduction of the code and translation of its form within the
> meaning of Article 4 (a) and (b) are indispensable to obtain the
> information necessary to achieve the interoperability of an
> independently created computer program with other programs, provided
> that the following conditions are met:
> (a) these acts are performed by the licensee or by another person
> having a right to use a copy of a program, or on their behalf by
> a person authorized to to so;
> (b) the information necessary to achieve interoperability has not
> previously been readily available to the persons referred to in
> subparagraph (a); and (c) these acts are confined to the parts of
> the original program which are necessary to achieve
> interoperability.
>
>2. The provisions of paragraph 1 shall not permit the information
> obtained through its application:
> (a) to be used for goals other than to achieve the interoperability
> of the independently created computer program;
> (b) to be given to others, except when necessary for the
> interoperability of the independently created computer program; or
> (c) to be used for the development, production or marketing of a
> computer program substantially similar in its expression, or for
> any other act which infringes copyright.
>
>--
>mailto:[EMAIL PROTECTED] http://www.iki.fi/pam/
>
>k�yhdytetty uraani kyynelkaasu laukaisin Loviisa LSD Luonto-Liitto mafia
>malaria marihuana Matts Dumell MC Finland Mika Marenk Mossad MP5 napalmi
>MVR Mustavihre�t P�iv�t neutroni Neuvostoliitto Olkiluoto Olli Mattila
--
--
Gisle S�lensminde ( [EMAIL PROTECTED] )
With sufficient thrust, pigs fly just fine. However, this is not
necessarily a good idea. It is hard to be sure where they are going
to land, and it could be dangerous sitting under them as they fly
overhead. (from RFC 1925)
------------------------------
From: [EMAIL PROTECTED] (Richard Bos)
Crossposted-To: comp.lang.c
Subject: Re: blowfish problem
Date: Wed, 23 Aug 2000 11:18:34 GMT
Bill Godfrey <[EMAIL PROTECTED]> wrote:
> > > > Of course you have; last millennium there wasn't even any
> > > > electricity to run your computer on.
>
> There has always been electricity, it's just that for a long time, no
> one knew it was there, let along power a computer with it.
I thought of that... I think I can get away with it by claiming that
last millennium, there was electricity, but not in a shape, form, way,
voltage, that you can run a computer on <g>.
Richard
------------------------------
From: [EMAIL PROTECTED] (Gisle =?iso-8859-1?Q?S=E6lensminde?=)
Subject: DES weak keys in 3DES
Date: 23 Aug 2000 13:33:39 +0200
DES have a number of weak and semi-weak keys, but in 3DES
(DES-EDE3) tree independent keys is used. How is the securiy if
one (or two) of these keys are weak. Shoud the key be avoided if
any of the DES-keys are weak, or must as least two of them be
weak before it becomes a problem.
--
Gisle S�lensminde ( [EMAIL PROTECTED] )
With sufficient thrust, pigs fly just fine. However, this is not
necessarily a good idea. It is hard to be sure where they are going
to land, and it could be dangerous sitting under them as they fly
overhead. (from RFC 1925)
------------------------------
From: [EMAIL PROTECTED] (Nathan the Great)
Crossposted-To: sci.math,sci.physics
Subject: Re: My unprovability madness.
Date: Wed, 23 Aug 2000 12:19:45 GMT
On Tue, 22 Aug 2000 16:13:25 GMT, "Douglas A. Gwyn"
<[EMAIL PROTECTED]> wrote:
>Nathan the Great wrote:
>> Principia Mathematica builds on Cantorian Set theory which posits
>> the existence of complete, not just potential, infinite Sets.
>
>It is true that Georg Cantor is to blame for transfinite
>numbers, and that a lot of his work involved set theory.
>However, PM builds up everything itself and (so far as I
>recall) does not posit the existence of infinite sets.
In Principia Mathematica, 2nd edition, Cambridge 1926, Whitehead
and Russell say, "In particular, we also reckon among the axioms
of PM the axiom of infinity"
And, the comment above was a footnote from Godel's own manuscript.
QED.
Please take a look:
ON FORMALLY UNDECIDABLE PROPOSITIONS
OF PRINCIPIA MATHEMATICA AND RELATED
SYSTEMS 11
by Kurt G�del, Vienna
http://www.ddc.net/ygg/etext/godel/godel3.htm
>The main weird thing about PM is its theory of types.
>
>> The concept of a 'complete infinite' Set is obnoxious to an
>> Intuitionists.
>
>That's true.
Nathan the Great
Age 12
====== Posted via Newsfeeds.Com, Uncensored Usenet News ======
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
======= Over 80,000 Newsgroups = 16 Different Servers! ======
------------------------------
From: Jim Steuert <[EMAIL PROTECTED]>
Subject: Re: The DeCSS ruling
Date: Wed, 23 Aug 2000 08:20:54 -0400
Reply-To: Jim, Steuert
Yes, I got a copy some time ago (before it was illegal to post
it). Although
I didn't study it yet, now I am very curious about it.
Can anyone in this group explain the code (with annotations). I
really am
curious as to why it is breakable. Perhaps posting it with
annotations but
without the keys would allow us to understand the algorithm and
steer us
away from making that same mistake again. Is that legal? If not,
then maybe
a legal description of that algorithm or family of algorithms
exists
- Jim Steuert
Anthony Stephen Szopa wrote:
> Jim Steuert wrote:
> >
> > I am horrified to learn about the DeCSS
> > case. The judge has
> > ruled in favor of the MPAA (Motion Picture
> > Arts Association) and
> > enjoined 2600 magazine from publishing the
> > DeCSS code on it's web
> > site.
> >
> > The judge apparently ruled that publishing
> > keys to a bank
> > vault, even if the publisher never intended
> > to rob the bank,
> > would force the bank to re-program it's
> > vault. And that
> > constitues illegal intent.
> >
> > Where I think the judge is mistaken is his
> > lack of distinction
> > between publishing the specific keys to a
> > specific bank vault, versus
> > reverse-engineering a publicly visible vault
> > mechanism (software).
> >
> > Isn't what is discussed on this newsgroup
> > equivalent to
> > "vault mechanisms?". And if so, isn't
> > publishing an attack on
> > a commericially used encryption algorithm
> > (DES certainly)
> > illegal?
> >
> > Is anyone in this newgroup concerned about
> > this ruling?
> >
> > -Jim Steuert
>
> Who cares?
>
> Well, I think the issue is: did you get your copy of DeCSS?
>
> Let's see. Did I or didn't I?
>
> I just can't remember.
>
> Maybe you should get your copy.
>
> I hear it shows up on the internet at random.
>
> Is it true that the DeCSS program is exactly 58,376 bytes?
>
> Oh, well. I don't really know.
>
> What do I know?
------------------------------
From: haifeng <[EMAIL PROTECTED]>
Subject: need hlep about "certificate validation" for x509 format
Date: Wed, 23 Aug 2000 15:27:57 +0300
Hello,
who knows some "certificate validation" for x509 format?
I need some codes(c or c++, java, j++)
Certificate validation just do "digitally singed, integrity, validity
period,revocation".
Thanks.
Haifeng:)
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Questions about stream cipher
Date: Wed, 23 Aug 2000 12:30:06 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Mark Wooding) wrote:
> Runu Knips <[EMAIL PROTECTED]> wrote:
>
> > This should read 'SEAL is the only stream cipher so far which is
able
> > to do random seeking'. Well and you, Tom, had a design which tried
the
> > same recently.
>
> No, SEAL can't do random seeking.
Um yes it can. Why do you think it allows for stretching of 32-
bit 'index' variables? That's fairly close to seeking.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Comment from Hardware Experts Please
Date: Wed, 23 Aug 2000 12:33:37 GMT
In article <8nvotu$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Guy Macon) wrote:
> [EMAIL PROTECTED] wrote:
> >
> >
> >My question is about performming a hardware multiplication in GF(2^n)
> >modulo an appropriate primitive polynomial. Sorry if my questions
> >seems vague, I am not a hardware expert.
> >
> >Generally I have two questions:
> >
> >1. Can it be done with relatively low amounts of hardware. I.e
> >cheaper unit. Low power as well.
> >
> >2. Can it be done with a relatively high output rate. Relative to
> >what I am not sure, i.e can it be done quickly? Say something close
to
> >nlog n steps?
> >
> >I want to design a 128-bit block cipher using decorrelation in eight
> >rounds, this requires a 64-bit GF multiply which is very costly in
> >software. In hardware this cipher would require 1024 bits of SRAM
but
> >this could be fed into the unit any way (i.e fed into latches in the
> >execution pipeline), and if the GF multiply is efficient in hardware
> >then the cipher could be practical for real usage.
>
> My first order estimation is that a good commercial DSP board would
> give you something on the order of a 10X increase in speed. It will
> cost a lot of money and use a lot of power, and would require a large
> software development effort. It would likely be much cheaper to try
> to get your program working on a Buewolf cluster.
>
> I am very concerned aboout your "something close to nlog n steps"
> comment. It shows a deep lack of knowledge of hardware/software
> tradeoffs that I believe will not allow you to implement a hardware
> solution. Going to hardware can only give you a fixed percenage
> speedup. It takes an algorithm change to change 2^n to nlog n.
> Hardware just does the same old thing faster.
Well for starters multiplication in GF(2^n) can be done in n steps
easily since all you're doing is adding multiples of one multiplicand
via XOR when a bit is set in any position.
What I really wanted to know is if it could be done in an FPGA or
something like that with ease. I know it can be done in software ...
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Questions about stream cipher
Date: Wed, 23 Aug 2000 12:30:44 GMT
In article <[EMAIL PROTECTED]>,
Runu Knips <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] wrote:
> >
> > In article <[EMAIL PROTECTED]>,
> > "Miki Watts" <[EMAIL PROTECTED]> wrote:
> > > Hi!
> > > I've got a few questions about stream ciphers:
> > > 1. Are they faster (in general) than block ciphers?
> >
> > Yes, but they can have their own disadvantages.
> >
> > > 2. Where can i find a list of (more or less) secure stream
ciphers?
> >
> > SEAL from IBM and RC4 from RSADSI are the best so far.
>
> If one names RC4 'Arcfour', it can be used freely, because it is only
> a trade secret (even if a secret isn't secret anymore if everyone
knows
> it) and a trademark.
>
> > The prob with stream ciphers is that you can't use the same key
twice,
> > and in the case of RC4 random seeking is not possible in an
encrypted
> > stream.
>
> This should read 'SEAL is the only stream cipher so far which is able
> to do random seeking'. Well and you, Tom, had a design which tried the
> same recently.
I wouldn't consider SC1 either secure or practical.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: haifeng <[EMAIL PROTECTED]>
Subject: about certificate validation
Date: Wed, 23 Aug 2000 15:44:01 +0300
Hello,
It is about
"Certificate Validation Procedure"
******************
Every time an user receives an other user's certificate, he must carries
on the following steps in order to validate the certificate and then be
assured about the sender identity:
1.Applying the CA's public key to decrypt the certificate and getting
the digital signature of the sender.
2.Verifying this digital signature, applying the algorithm specified
in the decrypted certificate.
3.Checking if the certificate is still valid, looking at the validy
period.
4.Checking if the certificate is contained in the revocation list.
Only if the certificate satisfies all these checks the receiver is
secure that the sender is the one claimed and he will go on with the
communication.
**********************
How can I use C or C++ code to finish and do it?
what do you think and what do you idea?
give me little bit more explain and simple source code.Thanks.
Haifeng:)
------------------------------
** 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
******************************
