Cryptography-Digest Digest #613, Volume #14 Thu, 14 Jun 01 19:13:01 EDT
Contents:
Re: Best, Strongest Algorithm (gone from any reasonable topic) - VERY (Mok-Kong Shen)
Re: Substitution Humor! (stanislav shalunov)
Re: CipherText E-mail encryption ("Joseph Ashwood")
Re: Best, Strongest Algorithm (gone from any reasonable topic) - VERY
([EMAIL PROTECTED])
Re: Help with Comparison Of Complexity of Discrete Logs, Knapsack, and Large
Primes ([EMAIL PROTECTED])
Re: survey (Mok-Kong Shen)
Re: Break on Schneiers first proposed "self-study cipher" (Sam Yorko)
Re: Help with Comparison Of Complexity of Discrete Logs, Knapsack, (Mok-Kong Shen)
Re: RNG (Andrew E. Schulman)
Re: BigNum Question ("AY")
Re: Best, Strongest Algorithm (gone from any reasonable topic) - VERY (Mok-Kong Shen)
Re: CipherText E-mail encryption ("Prichard, Chuck")
Re: survey ("Joseph Ashwood")
Re: Break on Schneiers first proposed "self-study cipher" ("Tom St Denis")
Re: CipherText E-mail encryption ("Prichard, Chuck")
Re: CipherText E-mail encryption ("Tom St Denis")
Re: survey ("Joseph Ashwood")
----------------------------------------------------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Best, Strongest Algorithm (gone from any reasonable topic) - VERY
Date: Thu, 14 Jun 2001 23:14:44 +0200
[EMAIL PROTECTED] wrote:
>
> Mok-Kong Shen <[EMAIL PROTECTED]> writes:
> > [EMAIL PROTECTED] wrote:
> >>
> >> ...there's one thing you can't lie about, period: the question
> >> ``Does this private key go with that public key?'' You can't fool me,
> >> because I can verify (i.e., ``absolutely prove'') it for myself.
> >
> > Isn't it that the existence of the so-called trust centers is because
> > of the need of proving whether a public key actually belongs to me?
>
> But you keep changing the subject. Knowing that I'm dealing with *you*
> and not with Dr. Evil is separate from the cryptanalysis of your
> messages. In practical situations I know who I'm dealing with; I've
> spied on the Mokkian diplomats; I've subverted the parlourmaid of Mok,
> the King of all Mokkia; I've located your transmitters deep in the heart
> of Mok-Kongs-burg, the capital city; and I've found copies of your public
> key in radio rooms on captured Mokkian subs.
>
> So denying your identity isn't going to fool me. The only interesting
> question is, ``Do I now have the private key which unlocks the messages
> we've intercepted?'' An absolute proof, one way or the other, is not
> hard.
>
> BTW, establishing identity only connects an individual to a body of
> messages. The body of messages have an ``identity'' of their own; they
> were all produced with one public key. And the private key can be
> verified with certainty. So the only missing puzzle piece is the owner
> of the key. If I can pin any single message on you, then I can pin all
> of them on you--unless you can convince a jury that your private key was
> stolen before the messages were written.
>
> The same applies to guns used in multiple crimes, fingerprints left by
> an unknown suspect, or--in the case of Timothy McVeigh--a prepaid phone
> card.
>
I was not changing the subject, i.e. diverting to something
else. You were talking of the possiblity of 'proving'
I am not lying (or the opposite). I was attempting to
show that a proof in the absolute sense, as far as
that topic goes is in practice not possible. Note that
I understand a proof to be different from merely having
very very high confidence on a matter.
Yes, if someone hands over to you the private key (he
stole it from me or employed a very huge computer),
then you can check that that private key corresponds
to the public key. But you can't yet 'link' that to me
in the absolute sense. I am referring here to your claim
that there is no way I can lie about that ('that' means
'the private key is mine'). My point is that I can deny
that the public key is mine, which renders the question
of whether the private key is mine effectively a
non-issue.
M. K. Shen
------------------------------
From: stanislav shalunov <[EMAIL PROTECTED]>
Subject: Re: Substitution Humor!
Date: 14 Jun 2001 17:17:58 -0400
Here's the original: http://www.netfunny.com/rhf/jokes/87/2094.10.html
--
Stanislav Shalunov http://www.internet2.edu/~shalunov/
All revolutions are bloody. The October Revolution was bloodless,
but it was only the beginning. -- Dmitri Volkogonov
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: CipherText E-mail encryption
Date: Thu, 14 Jun 2001 14:21:40 -0700
"Prichard, Chuck" <[EMAIL PROTECTED]> wrote in message
news:Vj8W6.1145$[EMAIL PROTECTED]...
> Its a demonstration.
So a completely fatal flaw makes a good demonstration? You are clearly not
as intelligent as you would have us think in these matters.
>
> The feature is planned for implementation in a commercial release.
Oh Gee Golly, more useless crypto for sale. You have never properly
documented the algorithm. You have never publically documented attacks on
any algorithms. You have never publically documented an algorithm. Your only
reputation in cryptography is that of a fool.
>
> The fixed data encryption key will be available only to one who has
> successfully decompiled the VB6 application.
If you believe that to be so, you are more of a fool that I would otherwise
have believed. It takes only a disassembler, and someone with knowledge of
assembly language. Since a brief recollection recalls at least 3
disassemblers that are available for free, and a quick search of Amazon
shows more than one book on the subject of x86 assembly, your following
statements:
> Because no such decompilers
> are
> presently available to the general public, its thought that making the
> key
> fixed in the demonstration copy was advantageous.
Are shown in even worse light, and indicate even less knowledge about
reality than your purported (and fatally flawed) program.
> A greater degree of
> simplicity is assured for the first time experience of the product.
So it's better to offer fake security than real security?
Your knowledge of algorithms is demonstrated further on the page by the
simple fact that you cannot seem to find a way to use your encryption to
encrypt generic data. I'll give you a big hint, the process begins with the
word "base" and ends with "64" That should make it entirely suitable. Of
course the simple fact that your algorithm is horribly unsuited to protect
anything will certainly not occur to you.
Joe
------------------------------
Subject: Re: Best, Strongest Algorithm (gone from any reasonable topic) - VERY
From: [EMAIL PROTECTED]
Date: 14 Jun 2001 17:40:06 -0400
Mok-Kong Shen <[EMAIL PROTECTED]> writes:
>
> I was not changing the subject, i.e. diverting to something else. You
> were talking of the possiblity of 'proving' I am not lying (or the
> opposite).
That's not in the slightest what I was talking about. I was contrasting
two situations:
(1) You use a OTP. I have your ciphertexts. Given a binary file purporting
to be the key, can I verify that it *is* the key? Answer: NEVER.
No theoretical means exists for establishing that the key is the key.
No matter how ``sure'' I feel that it is the key: even if I kidnapped you,
and found the key tatooed on your butt.
(2) You us a PK system. I have your ciphertexts. Given a binary file
purporting to be the key, can I verify that it *is* the key? Answer:
yes, always, with 100% certainty.
System #1 is secure IN AN INFORMATION THEORETIC SENSE. System #2 may be
secure, but it is NOT secure in an information-theoretic sense.
> I was attempting to show that a proof in the absolute sense, as far
> as that topic goes is in practice not possible.
Unfortunately, you're full of beans. If I get your private key, I *can*
be 100% certain that it is *the* key to *the* messages in my posession,
period.
Yes, you might try to fool me by living a double life, and hoping I'm
reading only messages which are a ``blind''. That's got nothing to do
with *cryptographic* security, which is what I was talking about.
> My point is that I can deny that the public key is mine...
You're completely ignoring that practical cryptanalysis happens in a
context. In other words, you COULD make that claim...but then you'd
have to explain why gigabytes of data encrypted with that key were
sent to you...any why your secretary thought it was your key...and why
I sent you a message in that key saying ``Wear a big lizard on your
head so I can recognize you. --Mok's #1 spy'' and for some reason you
turned up with a lizard on your head...
Don't confuse cryptographic issues with human engineering, traffic
analysis, psychology, religion, philosophy or anything else. It only
annoys people who are willing to discuss crypto with you.
Len.
--
Did you manage to observe _nothing_ other than that the computer didn't
do what you wanted it to do?
-- Dan Bernstein
------------------------------
Subject: Re: Help with Comparison Of Complexity of Discrete Logs, Knapsack, and
Large Primes
From: [EMAIL PROTECTED]
Date: 14 Jun 2001 17:45:48 -0400
Mok-Kong Shen <[EMAIL PROTECTED]> writes:
>
> Note that I asked whether one could give a 'right' goal... and you
> answered with an emphatic 'sure'.
No he didn't. He was telling you that we certainly can conclude that
R&W failed--because they were pursuing a goal which was provably
impossible.
> As I said, a logical model is wrong, if it is not consistent. The
> stuff did by the two authors is not wrong in the mathematical sense...
But a book is wrong, if it fails to accomplish its goal. R&W wanted a
complete mathematical theory--but such a thing is provably impossible.
Mathematicians generally have decided that working as hard as they did
is stupid, when the end result can't be achieved anyway.
> Every proof in the book must be correct (even though I haven't touch
> that book), since it apparently is a recognized literature.
Are you tetched? Recognized literature is generally riddled with
errors. One should assume that R&W contains many errors--even if they
are all fixable. So what? Once you've gone to the trouble of reading
and understanding it, where has it gotten you?
Len.
--
Frugal Tip #31:
Incrementally reduce your year-to-year operating expenditures while
aggressively recognizing unrealized receivables in the current quarter.
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: survey
Date: Thu, 14 Jun 2001 23:45:31 +0200
Sam Yorko wrote:
>
> "Douglas A. Gwyn" wrote:
> >
> > Joseph Ashwood wrote:
> > > ... Explore the boundaries, we know that the middle of the sandbox
> > > offers some good secure areas, but it's crowded, find something that can
> > > distinguish your designs from the designs of others. ...
> >
> > Joseph made some good points. One class of cryptosystem that has
> > not been thoroughly explored in the open literature is stream
> > ciphers that are *not* of the key-generator class. Some solid
> > theoretical results there would be publishable, and a good system
> > along those lines would have many uses. Not all communications
> > are block-oriented!
>
> I (and everybody in the WLAN 802.11 community) would be >very<
> interested in something like this. With the amazing number of attacks
> against RC4 being published, we would welcome a better solution for
> encryption of the data stream.
The original poster, Mr. Gwyn, would certainly be the
authority to explain what he meant in the above quote.
Before he posts details of his ideas, I would suggest
that one way of improving a stream generation process
for encryption is to somehow employ feedback to influence
the state of the generator. For example, at certain
intervals a certain function of the current plaintext
and/or ciphertext symbol(s) could be employed to modify
the current state of the generator in some manner. I
admit that I am rather vague here and am not suggesting
any thing concrete that is applicable to a given
generator like RC4.
M. K. Shen
======================
http://home.t-online.de/home/mok-kong.shen
------------------------------
From: Sam Yorko <[EMAIL PROTECTED]>
Subject: Re: Break on Schneiers first proposed "self-study cipher"
Date: Thu, 14 Jun 2001 14:54:57 -0800
Sam Simpson wrote:
>
> That's the sad thing about sci.crypt, the first response is always a troll
> from Scooter or Szopa.
>
Or, until recently, a newby slam from Tom.
However, he >has< matured quite quickly from just a few months ago.
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Help with Comparison Of Complexity of Discrete Logs, Knapsack,
Date: Fri, 15 Jun 2001 00:04:52 +0200
[EMAIL PROTECTED] wrote:
>
> Mok-Kong Shen <[EMAIL PROTECTED]> writes:
> >
> > Note that I asked whether one could give a 'right' goal... and you
> > answered with an emphatic 'sure'.
>
> No he didn't. He was telling you that we certainly can conclude that
> R&W failed--because they were pursuing a goal which was provably
> impossible.
Please see my response to his recent post where he
complained that I removed the context and misinterpreted
him.
>
> > As I said, a logical model is wrong, if it is not consistent. The
> > stuff did by the two authors is not wrong in the mathematical sense...
>
> But a book is wrong, if it fails to accomplish its goal. R&W wanted a
> complete mathematical theory--but such a thing is provably impossible.
> Mathematicians generally have decided that working as hard as they did
> is stupid, when the end result can't be achieved anyway.
Well, take an example. FLT has been finally proved. Before
that many books on FLT, giving some interesting (correct)
results, have been published, e.g. one by Ribenboim, though
none of these contain a proof of FLT (excepting 'partial
proofs'). Do you simply call all these books 'wrong'?
>
> > Every proof in the book must be correct (even though I haven't touch
> > that book), since it apparently is a recognized literature.
>
> Are you tetched? Recognized literature is generally riddled with
> errors. One should assume that R&W contains many errors--even if they
> are all fixable. So what? Once you've gone to the trouble of reading
> and understanding it, where has it gotten you?
I was stipulating that Whitehead and Russell were among
the good mathematicians and that the publishers had
done a good job. Yes, every human can err and we know
that typo can be a plague. Certainly you could take the
standpoint that nothing is correct before you yourself
has confirmed it to be correct. But that is not
what is meant by the quote of mine above. I meant
that what the two authors had done could not be
called wrong simply because they were unable to
achieve the goal that they had set for themselves.
This is because they had done the work in the
correct mathematical way which, excepting eventually
present errors due to human failings and matters
done wrong by the publisher, must be considered
to be correct. (See also above.)
M. K. Shen
------------------------------
From: Andrew E. Schulman <[EMAIL PROTECTED]>
Subject: Re: RNG
Date: Thu, 14 Jun 2001 18:13:39 -0400
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] says...
> [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY) wrote in message
>news:<[EMAIL PROTECTED]>...
> > [EMAIL PROTECTED] (Dobs) wrote in <9g8rnd$kvt$[EMAIL PROTECTED]>:
> >
> > >According to the Bruce Schneier book I made such a random number
> > >generator: I took two random sources from the system of the computer- I
> > >menaged to find to such a function : lp.dwAvailPhys from
> > >GlobalMemoryStatus(&lp) and timebuffer.millitm from _ftime( &timebuffer
> > >) which seems to return random values from the system. I took last
> > >significant bit of each, compare them:if it is the same I take to
> > >compare new couple of bits or if it is different I took as my output the
> > > first bit. However my output is like
> > >1111111111111111000001111111111111111111111111111111 which seems not to
> > >be random. Here is my code , could somebody tell me what I am doing
> > >wrong? Thanks. Best Regards.Mike
> > >
> >
> > Since you asked. The first mistake was reading the BS crypto book.
> > At least thats my humble view. I just hope you weren't foolish and
> > spent a lot of bucks for it.
>
> Gimme three good reasons why Schneiers book is a waste of money?
>
> Also you failed to answer his question.
>
> "BS's Book" [as D.S likes to call it]
Actually no, he called it "the BS crypto book" :)
--
To reply by e-mail, change "deadspam.com" to "zzapp.org"
------------------------------
From: "AY" <[EMAIL PROTECTED]>
Subject: Re: BigNum Question
Date: Thu, 14 Jun 2001 23:24:43 +0100
>Not true. Of course garbage collector is there to free the programmer of
>several "boring" lines of cleanup code, but there are always functions to
>actually delete any object on call. Try Runtime.gc() and destroy() and
>delete() methods in various objects.
I don't know about this, but i don't suppose the Java GC will overwrite the
memory with all 0's or random bits, which I think would be more desirable
from a security point of view, or would it?
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Best, Strongest Algorithm (gone from any reasonable topic) - VERY
Date: Fri, 15 Jun 2001 00:30:03 +0200
[EMAIL PROTECTED] wrote:
>
> Mok-Kong Shen <[EMAIL PROTECTED]> writes:
> >
> > I was not changing the subject, i.e. diverting to something else. You
> > were talking of the possiblity of 'proving' I am not lying (or the
> > opposite).
>
> That's not in the slightest what I was talking about. I was contrasting
> two situations:
>
> (1) You use a OTP. I have your ciphertexts. Given a binary file purporting
> to be the key, can I verify that it *is* the key? Answer: NEVER.
> No theoretical means exists for establishing that the key is the key.
> No matter how ``sure'' I feel that it is the key: even if I kidnapped you,
> and found the key tatooed on your butt.
>
> (2) You us a PK system. I have your ciphertexts. Given a binary file
> purporting to be the key, can I verify that it *is* the key? Answer:
> yes, always, with 100% certainty.
>
> System #1 is secure IN AN INFORMATION THEORETIC SENSE. System #2 may be
> secure, but it is NOT secure in an information-theoretic sense.
That's because you 'define' the security that way. But
consider what the difference is. In the first case,
you don't know 'for sure' whether the deciphered result
is actually the plaintext. You have uncertainty. In the
second case, you don't know 'for sure' (I hope I had
clearly explained that, we could discuss in the other
case) whether the key pair is actually mine. Again
you have uncertainty. Yes, the uncertainty is of
different nature, but it is there in both cases.
>
> > I was attempting to show that a proof in the absolute sense, as far
> > as that topic goes is in practice not possible.
>
> Unfortunately, you're full of beans. If I get your private key, I *can*
> be 100% certain that it is *the* key to *the* messages in my posession,
> period.
>
> Yes, you might try to fool me by living a double life, and hoping I'm
> reading only messages which are a ``blind''. That's got nothing to do
> with *cryptographic* security, which is what I was talking about.
>
> > My point is that I can deny that the public key is mine...
>
> You're completely ignoring that practical cryptanalysis happens in a
> context. In other words, you COULD make that claim...but then you'd
> have to explain why gigabytes of data encrypted with that key were
> sent to you...any why your secretary thought it was your key...and why
> I sent you a message in that key saying ``Wear a big lizard on your
> head so I can recognize you. --Mok's #1 spy'' and for some reason you
> turned up with a lizard on your head...
>
> Don't confuse cryptographic issues with human engineering, traffic
> analysis, psychology, religion, philosophy or anything else. It only
> annoys people who are willing to discuss crypto with you.
Yes, the gigabytes extremely highly strenthen your belief,
but it is nonetheless not a proof in the absolute sense (or
a proof in the mathematical sense).
M. K. Shen
------------------------------
From: "Prichard, Chuck" <[EMAIL PROTECTED]>
Subject: Re: CipherText E-mail encryption
Date: Thu, 14 Jun 2001 22:50:52 GMT
Dear Mr. Ashwood:
I contend that your opinion on the message integrity of a CXT file is
based on what you know about encryption and not what you know about the
CipherText algorithm itself.
I am finished making claims about its purported strength and im working
on useful niche applications. Base-64 encoding is not absolutely required
for transmission of CipherText files since the CXT file is already 7-bit
ASCII.
The CipherText application encrypts the message and attachments on the
fly, requiring no more additional manual processing than that already
required in Outlook Express.
Implementing the ability to articulate your own key for encrypting
contact information on the HDD is something that must be done with care.
I am considering giving the user the option to either set his/her own key
or simply use the default that was set at installation. Its a detail that
is better left for a time after the user has grown comfortable with other
more important aspects of the application. The problem with setting a
personal key is that it must be stored on the HDD. This is very awkward
to just throw together.
People dislike being confronted with decisions about things they do not
fully comprehend.
I view this as a very minor program feature at this time.
-C. Prichard
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: survey
Date: Thu, 14 Jun 2001 15:41:58 -0700
As the poster that Gwym replied to I do have some things to say on the
subject. There are several possiblities for the type of enhancement that has
been discussed. The 2 general categories are imbuement, and combinors.
Tom briefly experimented with different combinors, but didn't continue to
explore, he stopped with a purely linear equation. The theory is that you
can replace the key schedule of some block ciphers with the output of a pRNG
to create something that seems mildly like a combination block/stream
cipher. I think there are very significant gains to be made in this
direction.
Imbuement is a rather unexplored area, although further research will show
that it has been partially explored by some designers, and even in modes
like OFB for block ciphers. The idea is to use some amount of the plaintext
and/or ciphertext and/or an external source to continually add entropy to
the pRNG system. One example of this would be to take RC4 and on each output
swap the input byte being encryted, and the resulting encrypted byte. Other
ideas have been feedback modes, for block ciphers. I believe that there is a
large potential to build a pRNG that becomes less predictable given more
input (assuming the input has some amount of entropy), obviously up to a
certain point.
These are the two basic concepts that come to mind for exploration of stream
ciphers. of course with block ciphers there's always the ability to come up
with a strategy or basic design (e.g. Wide Trail or Feistel).
Since there has been an explicit statement that a particular community would
be interested in such a thing I will begin work on one, because of the
limited space available for a 802.11 I will probably avoid changing the
combinor, but will add imbuement to the system. I have an idea I've been
working on slowly for a while, I should be able to make a post on it by the
end of the week.
Joe
"Mok-Kong Shen" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
>
>
> Sam Yorko wrote:
> >
> > "Douglas A. Gwyn" wrote:
> > >
> > > Joseph Ashwood wrote:
> > > > ... Explore the boundaries, we know that the middle of the sandbox
> > > > offers some good secure areas, but it's crowded, find something that
can
> > > > distinguish your designs from the designs of others. ...
> > >
> > > Joseph made some good points. One class of cryptosystem that has
> > > not been thoroughly explored in the open literature is stream
> > > ciphers that are *not* of the key-generator class. Some solid
> > > theoretical results there would be publishable, and a good system
> > > along those lines would have many uses. Not all communications
> > > are block-oriented!
> >
> > I (and everybody in the WLAN 802.11 community) would be >very<
> > interested in something like this. With the amazing number of attacks
> > against RC4 being published, we would welcome a better solution for
> > encryption of the data stream.
>
> The original poster, Mr. Gwyn, would certainly be the
> authority to explain what he meant in the above quote.
> Before he posts details of his ideas, I would suggest
> that one way of improving a stream generation process
> for encryption is to somehow employ feedback to influence
> the state of the generator. For example, at certain
> intervals a certain function of the current plaintext
> and/or ciphertext symbol(s) could be employed to modify
> the current state of the generator in some manner. I
> admit that I am rather vague here and am not suggesting
> any thing concrete that is applicable to a given
> generator like RC4.
>
> M. K. Shen
> ----------------------
> http://home.t-online.de/home/mok-kong.shen
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: Break on Schneiers first proposed "self-study cipher"
Date: Thu, 14 Jun 2001 22:51:44 GMT
"Sam Yorko" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Sam Simpson wrote:
> >
> > That's the sad thing about sci.crypt, the first response is always a
troll
> > from Scooter or Szopa.
> >
>
> Or, until recently, a newby slam from Tom.
> However, he >has< matured quite quickly from just a few months ago.
Hmm neat. I am a newbie myself! Although I appreciate the comments. One
way to learn how people feel about me (i.e get feedback)
Tom
------------------------------
From: "Prichard, Chuck" <[EMAIL PROTECTED]>
Subject: Re: CipherText E-mail encryption
Date: Thu, 14 Jun 2001 22:54:18 GMT
> Your knowledge of algorithms is demonstrated further on the page by the
> simple fact that you cannot seem to find a way to use your encryption
to
> encrypt generic data. I'll give you a big hint, the process begins with
the
> word "base" and ends with "64" That should make it entirely suitable.
Of
> course the simple fact that your algorithm is horribly unsuited to
protect
> anything will certainly not occur to you.
> Joe
Base-64 is an encoding scheme for transmission. It is not encryption.
CipherText content is suitable for transmission without time-consuming
Base-64 encoding.
-C. Prichard
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: CipherText E-mail encryption
Date: Thu, 14 Jun 2001 23:02:06 GMT
"Prichard, Chuck" <[EMAIL PROTECTED]> wrote in message
news:gdbW6.1152$[EMAIL PROTECTED]...
> Dear Mr. Ashwood:
>
> I contend that your opinion on the message integrity of a CXT file is
> based on what you know about encryption and not what you know about the
> CipherText algorithm itself.
>
> I am finished making claims about its purported strength and im working
> on useful niche applications. Base-64 encoding is not absolutely required
> for transmission of CipherText files since the CXT file is already 7-bit
> ASCII.
>
> The CipherText application encrypts the message and attachments on the
> fly, requiring no more additional manual processing than that already
> required in Outlook Express.
>
> Implementing the ability to articulate your own key for encrypting
> contact information on the HDD is something that must be done with care.
> I am considering giving the user the option to either set his/her own key
> or simply use the default that was set at installation. Its a detail that
> is better left for a time after the user has grown comfortable with other
> more important aspects of the application. The problem with setting a
> personal key is that it must be stored on the HDD. This is very awkward
> to just throw together.'
Or use sthe default that was set at installation? I assume that each
install makes a new key?
How does this program work? It's for email so I assume it's based on some
PK algorithm right?
> People dislike being confronted with decisions about things they do not
> fully comprehend.
Which is why you must be smart about how you develop your application.
> I view this as a very minor program feature at this time.
Cough, PGP
Tom
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: survey
Date: Thu, 14 Jun 2001 15:57:19 -0700
"Sam Yorko" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> I (and everybody in the WLAN 802.11 community) would be >very<
> interested in something like this. With the amazing number of attacks
> against RC4 being published, we would welcome a better solution for
> encryption of the data stream.
Any thoughts on what would be good for 802.11? In terms of maximum ROM
space, and maximum RAM space. Since RC4 is considered suitable I presume
that 256 bytes of RAM is available, for 512 bytes of RAM I can make this
conceptually easier to express, but it can be done with a small counter and
256 bytes of RAM. I was hoping to use 2 8bit to 8bit SBoxes, so it would
also take 512 bytes of ROM. It looks to be extremely hardware efficient, but
more costly than RC4 in software. Additionally what output size would be
most appropriate, I can easily express it for 8, 16, 32, 64, 128, 256, 512,
or 1024, although the smaller than 1024 will actually take more RAM (max 512
bytes) and more time per iteration, but be more secure. The per key
initialization is significantly faster than RC4, requiring the time to
repeat the key until the state is filled, and then the time to pull a (as
yet undetermined) number of outputs to diffuse the state. I'll work on
formalizing the concept tonight, planning on 256 bytes and a 128-bit output,
but I should be able to change it easy enough. Feel free to reply privately,
or to the group.
Joe
------------------------------
** 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 by posting to sci.crypt.
End of Cryptography-Digest Digest
******************************
