Cryptography-Digest Digest #611, Volume #14 Thu, 14 Jun 01 16:13:01 EDT
Contents:
Re: Help with Comparison Of Complexity of Discrete Logs, Knapsack, and ("Douglas
A. Gwyn")
Re: One last bijection question ("Douglas A. Gwyn")
1st CipherText Application prototyped ("Prichard, Chuck")
AD: CipherText E-mail encryption ("Prichard, Chuck")
Re: Problem in Twofish (Graham Coles)
Re: Uniciyt distance and compression for AES (Tim Tyler)
Re: help non-elephant encryption ("Joseph Ashwood")
Re: CipherText E-mail encryption ("Joseph Ashwood")
Substitution Humor!
Re: FIPS 140-1 test ("Dobs")
Re: CipherText E-mail encryption ("Prichard, Chuck")
----------------------------------------------------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Help with Comparison Of Complexity of Discrete Logs, Knapsack, and
Date: Thu, 14 Jun 2001 16:09:07 GMT
Mok-Kong Shen wrote:
> > > "Douglas A. Gwyn" wrote:
> > > > Sure we can. In this particular case, we now know that
> > > > the program could not be completed, not even in principle.
> > > So please suggest such a goal for the future scientists.
> > ? Why would I want to suggest an impossible goal?
> To support your emphatic claim 'Sure we can'. ...
Please do not remove the context then misrepresent what I was
saying. What was it to which I said "sure we can"? It matters!
> If it was consistent, it was not wrong.
The programme required completeness. Therefore it was wrong.
> knowledge. But the theorem is really significant in my
> humble view, for antinomies have been sort of thorns in
> the eyes of logicians. If I were you in the present context,
> I would have taken the trouble to go to the library and
> locate the stuff that I had read about the theorem and
> posted something useful for the readers of this thread
Sorry, I don't have the time, and as I said it's rather
obvious once you know it. (The basic idea is you can
iterate the system and it has to converge to a unique
fixed point due to convexity.)
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: One last bijection question
Date: Thu, 14 Jun 2001 16:11:03 GMT
[EMAIL PROTECTED] wrote:
> By the way, ``range'' is defined wrong in (some/most/all) American
> Middle and High Schools; I always heard it defined as the codomain,
> while the word ``codomain'' was not used at all.
And it gets worse. I assist a high-school math teacher,
and quite often I have found the official textbooks using
established mathematical terms in ways that conflict with
their standard meaning.
------------------------------
From: "Prichard, Chuck" <[EMAIL PROTECTED]>
Subject: 1st CipherText Application prototyped
Date: Thu, 14 Jun 2001 17:31:35 GMT
The free download posted on 5-27 has been removed forever Tom.
Information about the coming product is available at:
www.greentv.com/CipherText/ciphertext_email_application.htm
You can still download the latest version and its CipherTextRX component,
but use requires authentication.
Attachment file encryption is supported for ANSII encoded ASCII formats.
These include RTF, HTML, various forms of TXT and common source code
files.
Contact me for authentication if interested.
Features:
NEW CipherTextRC component accesses contact information and lets you open
the file with its associated application. Requires password if CipherText
is not loaded.
Encrypts settings and contact information on your HDD.
Maximum 32 element key domain field of 32 possible values each yeilds
2.63 E +35 possible key combinations for reasonable message security
using the CipherText ASCII encryption algorithm.
Requires owner authentication and a password.
All contacts and settings information is encrypted.
No records are kept of messages sent from your computer.
Automatically dummies the key sent when attachments are encrypted. This
feature prevents accidentally sending a contact's key in the clear.
Intuitively easy to configure and use.
Compatible with Java-enabled email clients. Send a HTML CipherText to
anyone.
Send/receive CXT encrypted attachments that can be decrypted from within
Outlook Express.
Bug in R key generator has been resolved.
C. Prichard
www.greentv.com
Ciphertext encryption
------------------------------
From: "Prichard, Chuck" <[EMAIL PROTECTED]>
Subject: AD: CipherText E-mail encryption
Date: Thu, 14 Jun 2001 18:14:48 GMT
Encrypt messages while using Outlook Express or Communicator to receive
all email.
CipherTextRX opens when you click a CXT attachment. Encrypt RTF, HTML,
TXT and various ANSI encoded files.
Protects your privacy allowing you to communicate using your existing
email client.
www.greentv.com/CipherText/ciphertext_email_application.htm
BETA test requires authentication.
------------------------------
From: Graham Coles <[EMAIL PROTECTED]>
Subject: Re: Problem in Twofish
Date: Thu, 14 Jun 2001 19:39:32 +0000
In article <004401c0f2fc$1ac25e40$053f5a0a@ats1>,
[EMAIL PROTECTED] (Saurabh Pal) wrote:
> Can anyone help me in on problem related to a Function in Twofish Encryption
> Algorithm ?
>
> In the Function ' ParseHexDWord' , after getting the decimal value of
> parsed Hex character in b, the last line in for loop is
>
> d[i/b] |= b<<(4*((i^1)&7));
>
> I am unable to understand what is happening with DWORD b in this line,
> before writing it to array d.
>
> Thanks and waiting in anticipation.
>
> Saurabh Pal
> Allahabad, India.
>
Looks like you have a slight typo, which doesn't help.
The line should be
d[i/8] |= b<<(4*((i^1)&7));
In the function, i is indexing each character of an ascii
string representing a hex number, hence i/8 fills up the
dword, d, (32 bit word = 8 * hex digits) with the binary hex
digit values, albeit in a clever manner which endian swaps.
Given 16 bits of data in a string, say "4A6C", i will loop through
0, 1, 2, 3 giving the variable b successive values '4', 'A',
'6', 'C' which are then converted to their 4 bit binary values:
4, 10, 6, 12.
The 32 bit word d is initialized to 0.
The i^1 is i XOR 1 and for the range of i given, this maps to
the values 1, 0, 3, 2 (the &7 just restricts this to 3 bits and
is effectively a MOD 8)
The * 4 turns the value of i into a shifting value which will be
used to position where the 4 bit value in b will be placed into
d ; in this instance i*4 gives the values 4, 0, 12, 8 and so the
value of d will be modified (by the bitwise OR assignment, |=)
in succession as follows:
Source = "4A6C"
00000000 Initial value
00000040 i=0, d |= 4 << 4
0000004A i=1, d |= A << 0
0000604A i=2, d |= 6 << 12
00006C4A i=3, d |= C << 8
--
Graham Coles
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Uniciyt distance and compression for AES
Reply-To: [EMAIL PROTECTED]
Date: Thu, 14 Jun 2001 18:51:49 GMT
[EMAIL PROTECTED] wrote:
: Tim Tyler wrote:
:> [EMAIL PROTECTED] wrote:
:> : Tim Tyler wrote:
:> :> [EMAIL PROTECTED] wrote:
:> :> : Tim Tyler wrote:
:> :> :> Here is the model I think you should have adopted:
:> :> :>
:> :> :> Alice -> [encrypt] -> ...eve... -> [decrypt] -> Bob
:> :> :>
:> :> :> Unicity distance is as measured by Eve.
:> :> :>
:> : The decoder would reverse the mapping so that 000 would decode into
:> : 0000, etc. So, all values that compress would decompress into exactly
:> : the same value.
:>
:> Yes - but compress "1111" - and then decompress - and what do you get?
: Any values that don't compress, like "1111" are expanded.
Not in your example. You already used up all the probabilities available.
:> : Anyway, I'm not trying to understand specific compressor algorithms at
:> : this point.
:>
:> A good job.
: Likewise on your assertions instead of explanations.
I thought I already explained exactly what was wrong with your model,
and why it was irrelevant to the situation at hand.
Indeed, I feel as though I've explained several points more than once now.
:> :> :> Your system after the compressor is added can't even transmit some
:> :> :> messages that were transmitted before - and *all* the probabilities of
:> :> :> the messages occurring are changed!
:> :>
:> :> : This isn't surprising. [...]
:> :>
:> :> It was suprising to me. How you could think comparing the resulting
:> :> systems had any meaning was most puzzling.
:> :>
:> :> : Can *any* compressor compress *all* possible messages in the original
:> :> : message space?
:> :>
:> :> Of course not - but that is not how compressors operate either. They
:> :> compress some files, and expand others.
:>
:> : My example allows for the expansion of the values that don't compress.
:>
:> No - you did *not* include these files or their probabilities. If you
:> add in any more files, your probabilities will need reworking so that they
:> still add up to one.
: So you want me to include the probability of a value that expanded in
: the compressed message space?
All messages must have the same probabilities as before compression - or
comparing the two systems is of no use.
: Sorry bud, if it expands from n=4 then it doesn't
: belong in the n=3 message space.
You refuse to even consider the cases that is of interest - instead you
stick with your message distorter.
If you distort the messages, goodness knows what happens to the entropy in
the resulting system. Goodness knows what happens to the unicity distance.
Had any bets been made, they would definitely be off.
: BTW, if a value expands instead of compresses, don't you think I'd just
: transmit the original value?
Not in the model you presented - you had already used up all your
message probabilities.
:> : In fact, they don't affect the results in any way because I only
:> : considered the compressed message space.
:>
:> Nonsense. Add those files in, leave all the probabilities alone and your
:> thesis collapses. Remember what H(m) = -log2(0) is?
: Why bother specifying the base? ;>
It's there in the definition of entropy of a message.
: Show me how to add a n=4 value that expands into an n=3 message space
: and I'll be glad to start thinking about how to deal with the probabilities.
I'd think about it before I do that.
:> :> :> Why should putting in a compressor affect the frequency of the
:> :> :> messages being sent? It should not.
:> :> :>
:> :> :> If you /must/ use a lossy compressor at least set the probability of
:> :> :> messages it can't handle to be 0 initially, or you are comparing different
:> :> :> systems with different message spaces.
:> :>
:> :> : Again, doesn't one *have* to compare different message spaces since the
:> :> : value of n is different after compression??
:> :>
:> :> No, you should be comparing the same message spaces, otherwise the
:> :> comparison is completely nonsensical.
:>
:> : How can the message spaces be the same when there are 2^m values in the
:> : original message space and 2^n values in the compressed message space?
:>
:> The last time you asked this question I replied:
:>
:> ``That is not how compression programs function.''
: Do you think that's a good reply?
It should have given you a clue that your model was up the creek - in
conjunction with all my other explanations.
: A good reply would be to explain how they (compressors in general, not
: specific algos) function.
I don't see my function here as being teaching you - I'm mainly trying to
prevent misinformation being spread around on the subject - because
there's enough of it out there already, without people spreading it
further.
If you don't know how compressors function, why are you participating in
this thread about how compression affects the unicity distance?
:> :> :> Also, do not change the probabilities of the messages occurring, or else
:> :> :> you are comparing entropies in very different systems - and it is no
:> :> :> suprise that your unicity distances are all over the map.
:> :>
:> :> : The probabilities in the original message space are what they are. If
:> :> : they are non-zero then assigning them zero probability isn't an option;
:> :> : *that* would be altering the message space.
:> :>
:> :> Of course. But *don't* apply a compressor that can't accept these
:> :> messages as inputs and pretend that nothing has changed.
:>
:> : How can a compressor accept all inputs if it is mapping values from
:> : a larger message space into a smaller message space?
:>
:> It can't - but your premise is wrong.
: Maybe, but you don't seem to be able to explain why. [...]
Mapping messages from a larger space into a smaller space is not what
compressors generally do. Lossless compressors generally map between
equal size sets - e.g. the set of all files, and itself.
*Every* message has a compressed representation. This is true of ZIP,
it's true of ARJ, it's true of almost every general-purpose file
compressor.
:> :> : All the probabilities in my compressed message spaces sum to one [...]
:> :>
:> :> No they don't. Add up the probabilities in your second column, and you
:> :> will find they exceed one. A minor arithmetic error on your part.
:> :> I ignored it until now because there were other far more important errors
:> :> to address.
:>
:> : The point is that they are supposed to sum to one, and since the
:> : compressed message space is smaller than the original message space the
:> : original message probabilities can't be used because then they don't
:> : sum to one.
:>
:> The compressed message space should not be smaller than the original
:> message space.
:>
:> Think about what you are saying. Why should introducing a compressor into
:> the system affect the frequency with which Alice wants to send messages to
:> Bob? A compressor should not make any difference to them. It should
:> be transparent in operation. The only person affected is Eve - who
:> has a harder time of it.
: Thing about what *you* are saying. A message compresses, i.e. fewer
: bits, but the message space still remains the same even though fewer
: bits means fewer possible values???
No - that's NOT what I'm saying! You are one of the most frustrating
individuals I've discussed matters with recently :-|
: Again, the compressor doesn't restrict the choice of messages that I can
: send. It restricts the number of *compressed* messages that I can send.
You could not send "1111" in your example. You had used up all your
probabilities on other messages.
: If whatever compressor I'm using doesn't compress the message, I'll send
: it uncompressed - it's not like I'm unable to send that message at all.
Well, include that in your probabilities (and entropy estimates) then!
:> :> : Propose other probabilities.
:> :>
:> :> Leave the probabilities completely alone, you you are not comparing
:> :> equivalent systems.
:>
:> : The message spaces can't be equivalent since n < m.
:>
:> You are barking up completely the wrong tree. You don't seem to
:> grasp that your model has nothing to do with what compression programs
:> actually do.
:>
:> If you deal with "compression" programs that distort messages as they are
:> sent, don't allow the original messages to be reconstructed, and you
:> change all the probabilities of the messages in your system after adding
:> compression you are not comparing like with like.
: 1.) My compression example doesn't distort any messages. It just doesn't
: compress some, which isn't that unusual.
What happens to the "1111" message?
: 2.) My example allows any compressed message to be completely
: reconstructed.
Yes...
: 3.) If you have a compressor that can encode only two messages, and
: those two messages have arbitrary but equal probabilities in the
: uncompressed message space, and only compressed messages can be
: transmitted, what is the probability that the transmitted message is 1
: and what is the probability that the transmitted message is 0 ? You are
: saying that the probabilties won't change?
The probabilities of message transmission should be independent of
whether the messages are compressed or not.
Adding compression should /not/ change the probabilities of messages Alice
sends to Bob - or you have changed the properties of the system into one
which is not comparable to the original one - and then comparing entropies
is useless.
--
__________
|im |yler [EMAIL PROTECTED] Home page: http://alife.co.uk/tim/
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: help non-elephant encryption
Date: Thu, 14 Jun 2001 11:55:59 -0700
Actually the results were leaked fairly well.
What happens is that a trusted source generates a continually changing
randomness pool that is very large.
To build a communication pad between two people, the two people synchronise
a pRNG
The output of the pRNG is used to determine which bit(s) to select and at
what times.
The proof that I see for this being provably secure requires two things,
that the pRNG not offer the attacker perfect knowledge (i.e. the attacker
can't be able to compute and store all the possible results from each key
value)
The randomness pool undates at infinite speeds
The randomness pool is perfectly random
The first we can manage, it's just a small variation of the brute-force
resistance requirement for a cipher. It's worth noting though that the
requirement is different in that the attacker may have the compute power to
brute-force the algorithm, but cannot have enough space to store the
results, or even a significant portion of them.
The second and the fact that this will happen over wires of differing
lengths is what makes this impossible. I will establish this using 2 models
of the internet, the first I will model the internet as a collection of
varying length wires. And the second will be a model of the internet as a
clocked machine where wirelength doesn't matter.
In the first instance, the varying delays between the two lengths of wires
necessitates that two individuals recieve 2 very different results (the pool
is continually updating). This makes the system unusable.
The second, the consistent delay based on a clock makes the entire system
discrete. For those of you with an electrical engineering background this is
very similar to a Flip-Flop, the input will change a massive number of times
between sampling, the output will be sampled. This creates a discrete
system, one with an effective update period of well below infinite. This
violates rule 2 (the pool updates at infinite speed).
There are compromises that can be made, as long as we are willing to accept
that it does not offer perfect OTP generation. It will be very difficult to
attack a variant system with a finite clock, and a significant pool size,
but it will not be perfect.
Of course this very lack of perfection also invalidates the original claim
that we were dealing with.
Joe
"Nicholas Sheppard" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> On 13 Jun 2001 [EMAIL PROTECTED] wrote:
>
> > Nicholas Sheppard <[EMAIL PROTECTED]> writes:
> > >
> > > Perhaps it works by having the communicating devices measuring some
common
> > > source of randomness available on the network...
> >
> > In that case, it can't work. Passive observers on the network can
observe
> > the same random source, and can deduce the key.
>
> That would certainly be true in the most straightforward implementation of
> the system, that is, to just use the common random source as a one-time
> pad. I don't know the details of Rabin's system (it is unpublished, so
> far as I know), but it apparently used the random source in some more
> sophisticated way and was reported to be "provably secure". It seemed
> impractical (to me, at least) because the amount of random information
> mentioned in the article was absurd.
>
> There is an earlier system of this type by Cachin and Maurer in Crypto 97
> that is apparently perfectly secure against an enemy with limited memory
> capacity, though if memory serves me it is also impractical.
>
> --
> Nicholas Sheppard | Ph: +61 2 4221 5290
> Research Fellow | Fax: +61 2 4221 4170
> School of Information Technology & Computer Science | E-mail:
[EMAIL PROTECTED]
> The University of Wollongong, Australia | WWW:
www.uow.edu.au/~nps
>
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: CipherText E-mail encryption
Date: Thu, 14 Jun 2001 12:03:12 -0700
Let's examine this in detail.
I should have to go no further than:
"Currently the key used is fixed"
(www.greentv.com/CipherText/ciphertext_email_application.htm)
Pure snake-oil
Joe
"Prichard, Chuck" <[EMAIL PROTECTED]> wrote in message
news:sa7W6.1140$[EMAIL PROTECTED]...
> Encrypt messages while using Outlook Express or Communicator to receive
> all email.
>
> CipherTextRX opens when you click a CXT attachment. Encrypt RTF, HTML,
> TXT and various ANSI encoded files.
>
> Protects your privacy allowing you to communicate using your existing
> email client.
>
> www.greentv.com/CipherText/ciphertext_email_application.htm
>
> BETA test requires authentication.
>
>
>
------------------------------
From: <[EMAIL PROTECTED]>
Subject: Substitution Humor!
Date: Thu, 14 Jun 2001 14:57:14 -0400
Substitution Humor!
The European Commission has just announced an agreement
whereby English will be the official language of the EU rather
than German which was the other possibility. As part of the
negotiations, Her Majesty's Government conceded that English
spelling had some room for improvement and has accepted a 5
year phase-in plan that would be known as "Euro-English".
In the first year, "s" will replace the soft "c". Sertainly, this will
make the sivil servants jump with joy. The hard "c" will be
dropped in favour of the"k". This should klear up konfusion and
keyboards kan have 1 less letter.
There will be growing publik enthusiasm in the sekond
year, when the troublesome "ph" will be replaced with "f". This
will make words like "fotograf" 20% shorter.
In the 3rd year, publik akseptanse of the new spelling kan be
ekspekted to reach the stage where more komplikated changes
are possible. Governments will enkorage the removal of double
letters, which have always ben a deterent to akurate speling.
Also, al wil agre that the horible mes of the silent "e"s in the
language is disgraseful, and they should go away.
By the fourth year, peopl wil be reseptiv to steps such as
replasing "th" with "z" and "w" with "v". During ze fifz year, ze
unesesary "o" kan be dropd from vords kontaining "ou" and
similar changes vud of kors be aplid to ozer kombinations of
leters.
After zis fifz yer, ve vil hav a reli sensibl riten styl. Zer vil be no
mor trubl or difikultis and evrivun vil find it ezi to understand ech
ozer. Ze drem vil finali kum tru! And zen ve vil tak over ze
world!
------------------------------
From: "Dobs" <[EMAIL PROTECTED]>
Subject: Re: FIPS 140-1 test
Date: Thu, 14 Jun 2001 21:22:34 +0200
Thanks a lot for this links, however I am looking for source code of FIPS
140-1 statistical test in C (but working one)
or any other tests but please in C :))))
Thanks
Użytkownik Tim Tyler <[EMAIL PROTECTED]> w wiadomości do grup dyskusyjnych
napisał:[EMAIL PROTECTED]
> Dobs <[EMAIL PROTECTED]> wrote:
>
> : I am looking for source code of FIPS 140-1 statistical test for
randomness
> : which is used for high security application (that's what was written in
> : Handbook of Applied Cryptography:)
>
> It's at: http://quartus.net/files/Misc/
>
> Docs at: http://www.cerberussystems.com/INFOSEC/stds/fip140-1.htm
> --
> __________
> |im |yler [EMAIL PROTECTED] Home page: http://alife.co.uk/tim/
------------------------------
From: "Prichard, Chuck" <[EMAIL PROTECTED]>
Subject: Re: CipherText E-mail encryption
Date: Thu, 14 Jun 2001 19:33:09 GMT
Its a demonstration.
The feature is planned for implementation in a commercial release.
The fixed data encryption key will be available only to one who has
successfully decompiled the VB6 application. Because no such decompilers
are
presently available to the general public, its thought that making the
key
fixed in the demonstration copy was advantageous. A greater degree of
simplicity is assured for the first time experience of the product.
-C. Prichard
------------------------------
** 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
******************************
