Cryptography-Digest Digest #436, Volume #9 Wed, 21 Apr 99 11:13:09 EDT
Contents:
Re: Thought question: why do public ciphers use only simple ops like shift and XOR?
(SCOTT19U.ZIP_GUY)
Re: True Randomness & The Law Of Large Numbers (Mok-Kong Shen)
Re: BEST ADAPTIVE HUFFMAN COMPRESSION FOR CRYPTO (Mok-Kong Shen)
Re: Rijndael (Paul Gover)
Re: Export restrictions (Mok-Kong Shen)
Re: Thought question: why do public ciphers use only simple ops like shift and XOR?
(Jerry Coffin)
TREYFER cipher ([EMAIL PROTECTED])
Re: ANN: Next Beta-release of Kwik-Crypt (Anonymous)
ciphersaber-2 implementation help? ("Arthur N. Klassen")
----------------------------------------------------------------------------
From: SCOTT19U.ZIP_GUY <[EMAIL PROTECTED]>
Subject: Re: Thought question: why do public ciphers use only simple ops like shift
and XOR?
Date: Wed, 21 Apr 1999 11:46:08 GMT
In article <[EMAIL PROTECTED]>,
"Douglas A. Gwyn" <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] wrote:
> > ... Most people complain that my S-tables are too large. Since the
> > size of s-tables in scott18u.zip is effectively larger than a one
> > million byte key.
>
> I think the question in their minds is, whether such a large S-table
> is *essential* to attain the desired level of security, or whether
> other approaches might be comparably secure.
>
> > My feeling is that the method that computers use should involve much
> > more operations than what the public is use to. My code treats the
> > whole file as a block. Which is something else the current blessed
> > methods do not do.
>
> The immediate thought one has is that treating the whole message
> would be a problem in many applications where data is generated
> in a stream, for example a TELNET session. However, a whole-file
> method can be applied to small blocks simply by treating each
> block in the sequence as a separate file. That would lose any
> benefit from the large-file property, however. Have you any
> estimate of the security of your method when used with small
> "files" (say, 512 bytes or less)?
>
Well from reading Ritters stuff one can not really estimate
the security. However it would treat the 512 bytes as a single
block. I think if one used a fixed block size of any size say
512 bytes. Then it would be easyer to study the cipher for its
weak points. But it is not the fastest method out there. Many
seem concerned with speed. I feel in my gut that the faster a
method is then there is likely an easy method to break it.
My methods reqire a lot of time compared to others. But I feel
if one wants real security then my methods are the way to go.
David A. Scott
--
http://cryptography.org/cgi-bin/crypto.cgi/Misc/scott19u.zip
http://members.xoom.com/ecil/index.htm
NOTE EMAIL address is for SPAMERS
to email me use address on WEB PAGE
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: True Randomness & The Law Of Large Numbers
Date: Wed, 21 Apr 1999 14:35:25 +0200
R. Knauer wrote:
>
> How he acts on that decision to reject the TRNG is something that was
> not discussed, and is probably why you commented as you did. I would
> assume that there was some kind of further involvement with the TRNG
> maker. If the TRGN was designed carefully, the maker could have then
> run internal tests on the subsystems to prove out the device. The
> actual decision to buy the TRNG would then be based on those internal
> tests and an audit of the design.
I would be rather careful in blindly accepting test reports of the
manufacturers and audits done by their staffs for applications
as critical as cryptology.
> One of the requirements for a TRNG (used in crypto) is that it must
> not be biased in any way. Therefore the null hypothesis is:
>
> H0: p = 1/2.
>
> H1: p <> 1/2.
>
> I see no reason why comprehensive experimental tests cannot be
> constructed to test that hypothesis to within an arbitrarily small
> error. For example, those tests would certainly look not only at 1-bit
> bias, but at 2-bit bias, 3-bit bias, etc. They would look at very
> large multiple samples and compare/contrast them to one another.
The FIPS 140-1 Monobit test that you so be-littled is meant to
test one aspect of 1-bit bias. You may argue about the details
of that test as specified in the document, e.g. whether one shouldn't
take a larger sample. But the usefulness of that test is certainly
beyond question. And if you want to argue about the sample size of
that test, please suggest a concrete sample size that is adequate
in your judgement and say something to justify that.
> If it is a quantum physics process, it is random. Classical chaotic
> processes are not truly random in the strictest sense of the term.
> Even a fair coin toss is not truly random, although it might be close
> enough to be useful in some applications.
>
> Only quantum processes can be truly random.
This is not meant to argue for or against what you said above: Since
you are very interested in quantum phenomena, I like to call you
attention to an URL I just got elsewhere related to that:
http://www.eet.com/story/OEG19990419S0043
>
> It would be good protocol to dismantle a TRNG and reassemble it
> periodically to destroy any charafteristics that could leak
> information - for example, removing and reinstalling the radioisotope
> in a radioactive TRNG. Perhaps changing detectors would be advisable
> too.
>
> For shot noise TRNGs, replacing the diode would be advisable. If the
> TRNG was a fair coin toss, changing coins periodically would be
> advised. Even strongly mixing of the outputs of several different
> TRNGs in different ways would help. Have one strong mixing scheme one
> day, another another day.
Do you think it is practical/economical for users to do constant
dismantling and assembling of equipments, even if you can assume
some technical competency on their part?
>
> That is where the "arbitrarily small error" comes into play. For
> example, if I test a TRNG experimentally and decide that it has a
> probability p = 0.50 +- 0.05, is that good enough for purposes of
> crypto? Since those are the odds at roulette and since Las Vegas gets
> by quite handsomely with them, I would be suspect in using a TRNG with
> that much bias.
>
> If on the other hand, I determined that the TRNG had p = 0.5013 +-
> 0.0002, I might be inclined to use it.
What you can do is to know from the sampled data that p has the
expression above at a certain confidence level that is acceptable to
you. You can never be absolutely sure that p IS within that range
for the random process under your examination. And you do that with
statistical tests which you, however, have constantly claimed to be
useless for testing arbitrarily given sequences!!! (What tests other
than statistical tests can give you the knowledge above??)
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: BEST ADAPTIVE HUFFMAN COMPRESSION FOR CRYPTO
Date: Wed, 21 Apr 1999 14:54:31 +0200
SCOTT19U.ZIP_GUY wrote:
> But since compression does not in general have a secret key
> one is free to write and give away compression programs. Since
> part of the security of encrypted text relies on the entropy
> of the file being encrypted. If one is sending ascii data it
> would be nice to compress the data first. The problem is that
> most compression methods invovle headers or other tell tell
> signs that give information to an attacker. So it is best to
> use a method that leaves no traces in the compressed file.
I like but haven't yet tried to code any compression algorithms. So
I have some naive questions:
(1) If one uses a normal Huffman, i.e. with a fixed known ('standard'
or agreed upon by the partners) distribution of the symbols, does one
still need some header? If yes, what does the header contain?
(2) An adaptive Huffman must presumably start with some initial assumed
distribution of the symbols, doesn't it? If so, how can one avoid
the transmission of that initial distribution to the partner via a
header, if it is not 'standard' or otherwise agreed upon by the
partners?
Thanks in advance.
M. K. Shen
------------------------------
From: Paul Gover <[EMAIL PROTECTED]>
Subject: Re: Rijndael
Date: Wed, 21 Apr 1999 14:01:54 +0100
Paul Koning wrote:
> It's two syllables. The first one requires a sound not found in
> most languages. For a reasonable approximation, try "rhine-dahl".
Am I right in vaguely recalling that "ij" actually came about as a
typesetter's approximation to "y" with a dieresis (") over it, so
the sound is a modified "y"?
Paul Gover
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Export restrictions
Date: Wed, 21 Apr 1999 15:25:42 +0200
JCA wrote:
>
> How do export restrictions work? I only hear about key lengths, but
> I guess that algorithms must be taken into account as well; after all,
To my knowledge, Wassenaar limits the key length to 56 bits, without
considering the nature of algorithms. That doesn't appear to be
rational. But burocrats are often not rational. And that can be
a vice OR virtue.
M. K. Shen
======================================================
M. K. Shen, Postfach 340238, D-80099 Muenchen, Germany (permanent)
http://www.stud.uni-muenchen.de/~mok-kong.shen/ (Updated: 12 Apr 99)
(Origin site of WEAK2-EX, WEAK3-EX and WEAK4-EX, three Wassenaar-conform
algorithms based on the new paradigm Security through Inefficiency.
Containing 2 mathematical problems with rewards totalling US$500.)
------------------------------
From: [EMAIL PROTECTED] (Jerry Coffin)
Subject: Re: Thought question: why do public ciphers use only simple ops like shift
and XOR?
Date: Tue, 20 Apr 1999 11:42:53 -0600
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
says...
> Jerry Coffin wrote:
> > ...or they might not be. 2^32-1 happens to be a prime number. In
> > many cases, the smallest factor of your modulus has a large effect on
> > the security of encryption using that modulus.
> ---------------------
> Sorry, 2^32-1 = 3*5*17*257*65537, but I have found nice ways to set up
> key-derived multipliers in this field. The maximum length of the
> multiplicative cycle is 65536, so you can select an appropriate SEED
> and raise it to any power < 2^16. In fact, both the modular multiplier
> and its inverse are computed in the same subroutine.
Oops -- my bad. It's 2^31-1 which is a prime. Of course, if you work
in 32-bit integers, it's also 2^31-1 that you end up using as a
modulus unless you take steps to ensure against it.
However, even though I wasn't thinking very straight when posting, the
fact remains that the largest 32-bit number is a prime, and the
largest 64-bit number isn't. Interestingly enough, 2^63+1 also has a
much larger factor than 2^63-1, though it's a lot smaller than the
largest factor of 2^64+1 (only 11 digits instead of 14).
> I do not intend to keep it secret. If you are interested (just for fun),
> I am ready to discuss with you the method of file transfer
> (unfortunately, I don't have a Web page).
If it's written in Forth, I'll pass, thanks anyway. It's been many
years since the last time I tried to work in Forth at all, and from
what I remember, it's probably something that you have to either use a
lot, or you might as well forget it completely.
Then again, I suppose many people would say the same about C, C++ and
Scheme, all of which I use fairly regularly. Scheme (or almost any
LISP-like language) supports working with large integers, which tends
to be handy when you're dealing with factoring and such.
> Thanks for your courtesy Best wishes BNK
Likewise, especially when I posted something as boneheaded as I did...
------------------------------
From: [EMAIL PROTECTED]
Subject: TREYFER cipher
Date: Wed, 21 Apr 1999 13:46:38 GMT
Does anybody know where I can find the TREYFER paper? Or it's apparent new
version (to counter the slide attack?).
I would like to examine it and possibly make additions to it.
Tom
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: Anonymous <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp,comp.security.pgp.discuss
Subject: Re: ANN: Next Beta-release of Kwik-Crypt
Date: Wed, 21 Apr 1999 16:02:32 +0200 (CEST)
On Tue, 20 Apr 1999 13:45:51 +0100 [EMAIL PROTECTED] (Andy
Jeffries) wrote:
>
>Release Candidate 2 of Kwik-Crypt is released. This release fixes a minor
>memory leak and contains a smaller Windows GUI mode self restoring
>capability.
I just tried downloading the latest version of Kwik-Crypt. The D/L page
indicates that the latest build is 83 however the current release identifies
itself as build 54.
Is this the most current file?
Is the About screen incorrect?
------------------------------
From: "Arthur N. Klassen" <[EMAIL PROTECTED]>
Subject: ciphersaber-2 implementation help?
Date: Wed, 21 Apr 1999 13:29:39 GMT
=====BEGIN PGP SIGNED MESSAGE=====
Hash: SHA1
If this would be better posted in some other group, please send me a
clue. I looked but found no other no-brainer location. I'm trying to
implement CipherSaber-2 and I'm running into problem:
Excerpt from http:
"What is CipherSaber-2?
"CipherSaber-2 is a modification to Ciphersaber-1 that addresses
concerns raised about possible statistical weaknesses in RC4. In
CipherSaber-2 the entire state array mixing loop is repeated N times,
where N is n number that the sender and receiver agree upon. When N=1,
CipherSaber-2 is the same as CipherSaber-1.
"Used as suggested, there are no known problems with RC4 as it is
employed in CipherSaber-1, but CipherSaber-2 adds an additional margin
of safety. See A Cryptanalysis of CipherSaber for more details.
"Here is a sample file encoded with CipherSaber-2 using N = 10 and a
key of "asdfg":
"0e e3 f9 b2 40 11 fc 3e 2e 00 69 36 45 21 ab 72
5a 8f 36 fe 32 89 ac 4f 42 c7 35 1d b5 7a 26 71
4b fe ae 66 da e8 f7 49 04 dd"
but I get nothing but french-fries:
C9 36 68 0C 3F 2C F8 C2 0F 14 6B CE 87 BC 78 77
55 6C 85 B8 5B 97 17 BD 7B 91 19 95 8A C7 80 AF
I assume the problem is in my setup loop. Here's what mine looks like
(with some explanatory comments first)
// bMultiScramble is a global meaning use CipherSaber-2
// nTableScramble is a global for N in CipherSaber-2
// key is a global where the key+IV is stored
// kArraySize is a constant for the size of the state array: 256
// state is a global - the state array
// keyLength is a global giving strlen(the user's key) + 10
void Setup()
{
if (!bMultiScramble)
nTableScramble = 1;
const char* pKeyX = key;
int i, j = 0;
for (i = 0; i < kArraySize; state[i] = i,++i)
;
for (int k = 0; k < nTableScramble; ++k)
for (i = 0; i < kArraySize; ++i)
{
j = (j + state[i] + *pKeyX) & (kArraySize - 1);
if ((++pKeyX) - key == keyLength)
pKeyX = key;
Swap(state[i], state[j]);
}
i = j = k = 0;
}
I have tried some minor variations, but nothing seems to make the test
file yield anything meaningful (like a catchy phrase or a gif :). Can
anyone see what am I doing wrong?
tia...ank
=====BEGIN PGP SIGNATURE=====
Version: PGP for Personal Privacy 5.5.3
iQA/AwUBNx3SmxkuNxFeUgK/EQIelwCfUebHPpo8HoqKcGsBVssoP7Uwg3oAn0jV
FUiuKHgqh7NARP+/NcPnSEZY
=Sf87
=====END PGP SIGNATURE=====
[EMAIL PROTECTED] | The word "mercy"'s gonna have a new meaning
<*> | +t+ -> | |0 !! | when we are judged by the children of our slaves
PGP: **** 2047/DCDF9341:E273 AD0E F99A 8869 050B 5E92 0E47 C151 **** two
finger- *** 30DF 376C 43D0 DA74 F33F 752C 192E 3711 5E52 02BF *** prints
------------------------------
** 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
******************************
