Cryptography-Digest Digest #802, Volume #11 Wed, 17 May 00 16:13:01 EDT
Contents:
Re: Chosen plaintext attack, isn't it absurd? ("C. Prichard")
Re: NIST releases final AES comments (David Crick)
Re: Theoretical question (Mok-Kong Shen)
Re: Jobs at Cloakware (David A Molnar)
Re: Crypto & UNICODE??? (Mok-Kong Shen)
Re: QUESTIONS About ALGOS !! (Eric Lee Green)
Re: Diffie's Randomized Stream Cipher (Tim Tyler)
Re: AES final comment deadline is May 15 ("Michael Scott")
Re: Key generation (Eric Lee Green)
Re: AES final comment deadline is May 15 (Roger Schlafly)
Re: Turing's Treatise on Enigma (pink aka Chr. Boesgaard)
Re: problem solving ("Axel Lindholm")
----------------------------------------------------------------------------
From: "C. Prichard" <[EMAIL PROTECTED]>
Subject: Re: Chosen plaintext attack, isn't it absurd?
Date: Wed, 17 May 2000 15:53:23 GMT
I don't think your decryption process is criticized.
Message security has much to do with the perceived integrity of your =
encryption, not your decryption process. The message actually contains =
all the essence assuming you have done everything properly in your =
algorithm.
Key domain is important. This and the desire to compress data for =
transmission were two of the biggest reasons to move to 'blocking' =
ciphers with mapped output a few years ago. I'm still learning a few of =
the peculiar seeming things about the reasons for believing that the =
block ciphers are better.
As for my own work I has developed a cipher that uses a restricted =
domain in creating ciphered output that can be transmitted in the =
default protocol. The problem with a restricted domain of input =
characters is that the number of key combinations are reduced =
proportionate to your restriction. I new about it but have been =
demonstrating the performance of the cipher anyway looking for someone =
to give me advice more positive than the "Why not use one that works?"=20
I come back to the cipher when there is time for it. Recently I learned =
that security analysis is based on many things, but there is a nearly =
universal expression for the relative strength assuming only a brute =
force attack can convincingly deliver the plaintext message and key.
Apparently a double cipher is considered a little silly, because if you =
do can the job properly in one pass, why bother to do it over again? =
This is one of the problems I have with CipherText in the community =
because it was largely developed by an ignorant person and wreaks of it =
with the atrocious double pass cipher.=20
Because I truly believed that there should be more analysis done than =
merely calculating the extent of the possible key domain, I parlayed the =
work. Its not difficult to do and will give you insight on the relative =
strength of your encryption if you examine the key domain.
For example 56 bit DES uses 7 keys all having 256 possible ordinate =
values. 256 ^ 7 =3D 7.205 E + 16 is a relative indication that will tell =
you how strong the encryption is. The calculation assumes a purely =
random cipher and set of keys (theoretically possible but hardly ever =
the case.) 128 bit DES gives you 3.402 E +38 for a strength index based =
on the cipher key combinations.
I took these numbers in and then I calculated the strength of my =
CipherText cipher with the restricted key domain. With 8 key characters =
each having 10 possible ordinate values, the calculation is 10 ^ 8 =3D 1 =
E +8. This is the strength when using numeric values only for key =
elements.
To put things in perspective, there is quickly an assumption that the =
DES cipher is superior to CipherText giving hundreds of millions of =
times greater message diversity because of the key combinations. This is =
where most cryptologists lose interest real fast in YOUR so called =
'work'.
I used my algorithm to develop demonstrations of various uses within the =
default protocol sending encrypted text back and forth at lightning =
speed and giving myself all the credit in the world for a job well done =
proving that it can still be done.
You are aware that the US government is looking at 512 bit ciphers that =
deliver E +300 possible encryption keys aren't you? Its mind boggling to =
think that its even necessary, but the experts say it is.
Anyway, I learned recently of an Old technique called 'the whitening' of =
ciphered messages. Apparently in the days before block ciphers, someone =
figured out that they could use numeric keys, and then use a set of =
random ordinates to MASK the first message giving it a 'whiter' (more =
random I assume) domain. The idea occurred plausible to me after =
thinking about an analogy to creating a set of values called a number =
and them articulating a change to its BASE. The result of course being a =
different-looking number. In my mind I had to justify how it would be =
done, using a large random mask to 'whiten' CipherText's output. After =
working on another mask distribution scheme, it hit me that it is very =
practical to simply have a fixed set of MASK ordinates and encrypt the =
mask for each message (prior to transmission normally.) The scheme =
relies on a key exchange for the whitener MASKING key as well as the =
CipherText key.=20
The random ordinates are quickly calculated as random numbers greater or =
equal to 0 and less than 96 and then added to 32 to give values greater =
than 32 and less than 128. Briefly, this is necessary to maintain =
compatibility with the domain of values that can be transmitted in the =
default HTTP protocol without conversion.
What this does to the strength of encryption is interesting. Assuming =
just 8 ordinates having 96 possible values the combinations are: 96 ^ 8 =
=3D 7.213 E +15. This from whitening alone. Multiplying by 10 ^ 8 gives =
7.213895 E +23 ( a few hundred million times stronger than DES ) and =
still compatible with the default HTTP protocol.
Suddenly CipherText is serious encryption.
Cryptologists want to see that you have applied as much of a true =
randomness to your encryption as possible. That is something that they =
understand as vital to having a strong encryption algorithm. This could =
probably be RULE 1.
RULE 2 is probably that you have read the FAQ for their newsgroup. This =
could probably be RULE 1 also. hehe
However, if you take your work seriously you can get beyond these =
important issues and begin to examine other things. Now that I =
understand this much about my own algorithm, I don't need that much more =
from this newsgroup except for an honest opinion about the viability of =
CipherText as a commercial solution for use with the internet, given the =
future of technology so close at hand.
Its very hard to make contact with a world renowned cryptologist who has =
worked hard to earn the regard of his peers in cryptology as well as =
others. One cannot even know where to start to explain what he knows. =
And the funny thing is, they may even pretend to not know about some =
things.=20
You need to take time to understand the source of criticism, and give =
yourself some credit. But you also need to apply yourself and work hard =
to be able to demonstrate that you are learning anything about =
cryptology.
The advanced people here have understanding that allows them to =
patiently apply computer analysis methods to search data for little =
clues. You can see the explanations in print, but they somehow don't =
reveal much about what they know. Its amazing how someone can figure out =
how to break one of these ciphers.
To put my work on CipherText in perspective, I think I have made a good =
start in cryptology to learn something about past technology in =
attempting to rework it and make it useful today. You have to look at an =
ASCII cipher and realize that with whitening they all had that strength =
back 30 years ago, before keys were exchanged electronically. Back then =
a computer couldn't search the key combinations fast enough to ever =
mount a successful brute force attack. That was a time when even a =
wasted byte in DOS memory for the time (Y2K) was considered expensive. =
Compression and data throughput became the compelling reason to create =
block ciphers and encoding methods making information suitable for more =
reliable transmission or storage. The compression is done in blocks and =
its natural to do encryption the same way. With the added key =
combinations in the encryption ciphers, the need for greater security =
possibly has always taken precedence over other considerations. Even =
over transmission tradeoffs, as it was thought that an 8 bit transfer =
protocol would be developed mainly for use with encrypted messages.
With CipherText I am exploring some of the opportunities that might =
exist for using encryption within the default transmission protocol. So =
far I have found few people who are interested in the same.
I'm developing interest in a mapped 7-bit cipher ( also wreaking of =
ignorance and a disgrace to cryptology.) But I would not be thinking =
about it if I did not believe that my Ciphertext now has some value to =
me as an 'encryption' algorithm.
Developing methods for attacking encryption allows you to develop better =
encryption methods. I think this is obvious. But there is more to =
cryptology that creating state of the art block ciphers. Application =
often has unexpected requirements. A block cipher is often not practical =
for somebody's real important requirement for some type of security. I =
don't think alot of the younger 'cryptologists' really regard anything =
but a block cipher as real encryption. Its amazing what an internal =
boost some people get from a college degree.
Charles Prichard
www.greentv.com
Manuel Pancorbo <[EMAIL PROTECTED]> wrote in message =
news:8fu7ov$505$[EMAIL PROTECTED]...
> I mean, if the attacker is able to access the encipher machinery (but =
not
> the actual key) and then test the ciphertexts she wants, what stops =
her to
> access the DEcipher machinery?
>=20
> I posted here some months ago a question about the security of an =
algorithm
> with involution property, that is cryptosystem where encryption =3D
> decryption:
> Ek(Ek(m)) =3D m
>=20
> If the above argument is really silly (counterarguments, please) I =
will
> quickly understand why involution algorithms are weak!
>=20
>=20
> --
> =
_________________________________________________________________________=
___
> _________
>=20
> Manuel Pancorbo
> [EMAIL PROTECTED]
> "...
> M=E1s vale aprender una sola l=EDnea de Ciencia
> que postrarse cien veces en oraci=F3n. (Cor=E1n)
>=20
> Pli valoras lerni ech nur unu linion de Scienco
> ol preghe genui cent fojojn. (Korano)
> ..."
> =
_________________________________________________________________________=
___
> _________
>=20
>=20
>=20
------------------------------
From: David Crick <[EMAIL PROTECTED]>
Subject: Re: NIST releases final AES comments
Date: Wed, 17 May 2000 19:13:34 +0100
DJohn37050 wrote:
>
> NIST releases final AES comments. See Round 2 comments.
> Some are in separate files and some are in a big text file
> if sent as a note.
> Don Johnson
I thought that a very interesting comment was the one from
the US DoJ INS. They recommended Twofish, but with 256-bit
keys only and with a minimum of 20 rounds, with 24 as the
recommendation.
Coming from a Government department that uses different
levels of crypto (including spook-designed), I thought the
endorsement of 256-bit keys and a safety margin of 18 rounds
(from the current 6 rounds attacked by the public) was
significant.
David.
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Theoretical question
Date: Wed, 17 May 2000 20:27:31 +0200
Bryan Olson wrote:
> Mok-Kong Shen wrote:
>
> > Under that very general assumption (all functions without
> > restrictions to the properties) I don't yet see that much
> > useful properties could be derived therefrom.
>
> But the parenthesized description is not at all the same as
> the definition Nicol So stated. A random function is not
> all functions nor an arbitrary choice. It's a random
> choice, with all candidates equally probable.
>
Sorry for my poor knowledge. But what ARE the 'candidates'?
Are there restrictions about which functions are admitted as the
candidates (from which one then randomly chooses)? There are
lots of general/special properties of functions, aren't they?
For example, must these be linear, differentiable, etc? Or, as I
asked, is ANY arbitrary function mapping from a given domain
to a given codomain eligible to be a candidate in the present
context? Thanks.
M. K. Shen
------------------------------
From: David A Molnar <[EMAIL PROTECTED]>
Subject: Re: Jobs at Cloakware
Date: 17 May 2000 18:47:57 GMT
Marlies Vincken <[EMAIL PROTECTED]> wrote:
> · Knowledge of computational graph theory, complexity theory, number theory
> and discreet mathematics.
^^^^^^^^
This is a joke?
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Crypto & UNICODE???
Date: Wed, 17 May 2000 21:13:12 +0200
Marcin Jaskolski wrote:
> On Wed, 17 May 2000, Mok-Kong Shen wrote:
>
> >
> > Kenneth Cascio wrote:
> >
> > > If I have a plaintext Message "ABCDEFG" (Represented in memory by 7-Bytes
> > > (HEX): 41, 42, 43, 44, 45, 46, 47) that I want to keep a secret (i.e.
> > > encrypt) and my application is using standard ASCII character strings (1
> > > byte per character), than an eavesdropper, unless he has other methods, can
> > > not infer anything about my original message from the ciphertext.
> > >
> > > On the other hand, if my application is using UNICODE instead of ASCII, the
> > > same message "ABCDEFG", now occupies 14-Bytes of memory (UNICODE is a
> > > multi-byte character) and is represented in memory (on an Intel based
> > > machine) as: 41, 0, 42, 0, 43, 0, 44, 0, 45, 0, 46, 0, 47, 0. Any algorithm
> > > acting on this block of memory (now 14 bytes) will be encrypting the 0s
> > > which are now part of the message.
> > >
> > > The eavesdropper could now infer (if he knows anything about my system)
> > > parts of the original plaintext message. He/she could assume that the
> > > original message looked something like this: ?, 0, ?, 0, ?, 0, ?, 0, ?, 0,
> > > ?, 0. The "?" represents an unknown BYTE and the 0s are the known BYTES
> > > (zeros). Now, he/she knows half of my original message! With this
> > > information, I would think that a "Known Plaintext Attack" could be used in
> > > an attempt to decrypt the ciphertext.
> >
> > Sorry for my ignorance. I don't yet understand your agruments. If, as
> > you said, the opponent knows of you system that every other byte is
> > a meaningless 0, then he reduces the information obtained to that of
> > the first case you described. How can he be in a better position to
> > crack than in the first case? Presumably I have missed quite a lot.
> > Could you please illustrate with a tiny concrete example of your
> > known plaintext attack? Thanks in advance.
> >
>
> hmmm. I don't really have the point. If the cryptosystem works in way
> described above, then itlooks like a block cipher taking only one
> byte at a time, then encrypting it. So, message AAABBBCCCAAA will be
> encrypted like that : XXXYYYZZZXXX., Then its
> 1.very vulnerable to chosen plaintext attacks - the attacker will
> encrypt the message :ABCD.....WXYZ - then he will know everything;
> 2.vulnerable to known plaintext attacks - the eavesdropper is likely to
> decrypt part of the message;
> 3.assuming you are using english language in your secrets, attacker
> can guess quite a lot by doing statistical research - for example
> AFAIK the 'e' letter is very often used in english - you got the point
>
> I think you should use a block cipher which takes at leas, say 128 bits
> (?) at a time. Attacks described above will become, uhm, not very
> practical :-)
>
I am afraid that you misunderstood what I meant (and probably also
what the original poster meant). It is not an issue of what encryption
algorithm to use!
Let me formulate the two cases of the original poster (as I understand
them):
Case 1: The given plaintext is in Hex: 41424343454647 (7 bytes).
Case 2: The (transformed) given plaintest is in Hex:
4100420043004400450046004700 (14 bytes)
It is assumed that the opponent knows the scheme, i.e. the transformation
from case 1 to case 2 (it wouldn't also be hard for him to infer that).
If any trick, including known plaintext, works well when a certain
encryption algorithm is applied in case 2, why shouldn't it work 'equally'
well in case 1? That was my question.
M. K. Shen
------------------------------
From: Eric Lee Green <[EMAIL PROTECTED]>
Subject: Re: QUESTIONS About ALGOS !!
Date: Wed, 17 May 2000 19:12:54 GMT
Karim A wrote:
> But I have to make a choice between efficiency and speed !
> Well I'd like to know if the DES / 3DES is a very fast algo ?
DES is insecure and slow. 3DES is secure and even slower. I would not use DES
in any program, it has been cracked aned cracked badly, but 3DES, though slow,
is as close to a "proven secure" cipher as is currently available (note that
there is no real way to prove that a cipher is secure... but 3DES has survived
all attempts to crack it to date).
> I've been told that Blowfish algorithm was very fast and secure.
> What do you think about it ?
Blowfish is a good choice if you're looking for a proven algorithm. It has
known flaws -- the key schedule is somewhat slow, and the 64-bit block size is
a limiting factor in how many messages you can transmit without re-keying --
but if you need faster performance than 3DES, in an algorithm that has
survived almost as much attempts to crack it as 3DES, then Blowfish is a good
choice.
If you were looking for an algorithm that is more modern than the above,
Twofish is a good choice. It is fast, has a 128-bit block size, is free (does
not require licensing), and is reasonable to implement, but has the
disadvantage that it has not stood the test of time like 3DES and Blowfish
(though significant, though unsuccessful, effort has been made to crack it, as
part of the AES contest).
Here's how I would rate it. If you're after security, use 3DES. It is
time-tested and as close to "secure" as we can say given the fact that it's
currently impossible to mathematically prove any cipher "secure" (with the
exception of One Time Pads, which are impractical).
If you need more speed, it's a harder choice. I personally chose TwoFish -- it
is fast, and the 128-bit block size makes it inherently more resistent to
attempts at differential analysis even if differential attacks are discovered,
not to mention making it a good complement to the MD5 message digest algorithm
(which has a 128-bit output). But Blowfish certainly would not be a bad
choice.
--
Eric Lee Green [EMAIL PROTECTED]
Software Engineer Visit our Web page:
Enhanced Software Technologies, Inc. http://www.estinc.com/
(602) 470-1115 voice (602) 470-1116 fax
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Diffie's Randomized Stream Cipher
Reply-To: [EMAIL PROTECTED]
Date: Wed, 17 May 2000 18:37:45 GMT
I, Tim Tyler <[EMAIL PROTECTED]> wrote:
: Andru Luvisi <[EMAIL PROTECTED]> wrote:
: : On page 419 of the 2nd edition of Applied Cryptography, Bruce Schneier
: : mentions a scheme invented by Whitfield Diffie where you send someone
: : 2^n random bit strings, and then the message xored against one of
: : them. The key is an n bit value which specifies which one. He says
: : "Any attack must examine an expected number of bits which is in
: : O(2^n). Rueppel points out that if you send n random strings instead
: : of 2^n, and if the key is used to specify a linear combination of
: : those random strings, the security is the same."
: This last appears to me to be questionable. [...]
Thinking about it further, "wrong" might be a better description.
If the n random strings are linearly combined with XOR (to produce the
pad) there's a simple known-plaintext attack on the resulting system,
which recovers the key using a couple-of hundred bits of known plaintext.
This sets up slightly more than 128 linear equations based on the
known plaintext/cyphertext pairs, and bits from the key. These can be
solved via linear algebra techniques - i.e. eliminate the variables, one
at a time, and then substitute the key bit values back in, as they become
known.
If the linear combinator is addition, with carry, a very similar attack
can be used. If the known-plaintext is at the start of the message
(or at the point the carrys travel away from), you wind up with a
very similar bunch of linear equations.
I find it hard to visualise how any system that fits the description
given could possibly be of significant strength - since there seems to be
no non-linear component, the volume of data employed is quite small,
and everything except the key is public.
The only such scheme I can think of hashes the key with a counter (to
stretch it out to the length of the message) and performs a *different*
key-dependent linear transformation on each bit from the n random strings
to generate the pad.
Here the strength comes from the hash of the key - and the n random
strings are basically pointless - using a minimal predetermined orthogonal
set would offer very similar strength :-(
--
__________ Lotus Artificial Life http://alife.co.uk/ [EMAIL PROTECTED]
|im |yler The Mandala Centre http://mandala.co.uk/ Goodbye cool world.
------------------------------
From: "Michael Scott" <[EMAIL PROTECTED]>
Subject: Re: AES final comment deadline is May 15
Date: Wed, 17 May 2000 20:29:57 +0100
It seems to be between Twofish and Rijndael at this stage. I much prefer the
latter, but Twofish has undoubtedly been marketed rather better.
Would others agree that its a two horse race? (I nearly typed "two fish
race").
Mike Scott
------------------------------
From: Eric Lee Green <[EMAIL PROTECTED]>
Subject: Re: Key generation
Date: Wed, 17 May 2000 19:42:54 GMT
"C. Prichard" wrote:
> (this is not dis-information now)
[Should keep people from just banging away with bad keys for network
authentication.]
> (Returning you now to your previous military dis-information service.)
I'm not sure we were discussing network authentication. In any event, I think
you have stated an obvious observation that needed to be stated: limits need
to be placed in order to prevent, e.g., "flood" attacks that exploit the
limited entropy of PRNG's, for example.
Unfortunately, what you then have is the opportunity for denial of service
attacks. The attacker can sniff the network (either with a network scanner, or
because he's already an employee with non-admin access and can use the OS's
native directory function to gather the user names), detirmine what user names
are in use, and then systematically attempt to log in to the server with each
of those user names plus an invalid password. The result is an inaccessible
server.
Heading off that DOS attack means logging the connector's network ID and
locking out that network ID. Unfortunately, that's nigh impossible, because I
can shut down my network stack and bring it back up with a different IP and
MAC address without difficulty (I run Linux, and happen to be using a network
card that has a programmable MAC address -- a fact which causes our local
network monitor system, ARPWATCH, some disconcertation, because I dual-boot
with FreeBSD, and FreeBSD and Linux program the MAC address differently).
A switched network fabric would help in that it would make network scanning
much harder (you would have to have compromised the server, in which case,
what's the point?), but would not otherwise help. My network switch, for
example, has no problem with me switching my MAC address to some other MAC
address -- it thinks I simply brought another machine online on my hub out
here, and happily routes packets to said MAC address.
The best I can think of is what the Linux and Solaris PAM (Pluggable
Authentication Module) libraries do -- they insert an arbitrary delay into
each failed authentication attempt, so that attackers cannot flood the system
with arbitrary attempts, and they inform the system logger so that if you have
LogWatch programmed right, it can beep you that someone's trying to break into
the system. Thus the attacker is limited to, say, 6 attempts per minute,
meaning that if he wanted to try all 2^30 likely passwords and pass phrases,
he's going to be a while :-). This allows protecting the system from a flood
attack, without allowing the attacker to deny service to the users on the
system.
I'm curious if you have any insights here that I haven't pulled out of the
depths of my brain?
--
Eric Lee Green [EMAIL PROTECTED]
Software Engineer Visit our Web page:
Enhanced Software Technologies, Inc. http://www.estinc.com/
(602) 470-1115 voice (602) 470-1116 fax
------------------------------
From: Roger Schlafly <[EMAIL PROTECTED]>
Subject: Re: AES final comment deadline is May 15
Date: Wed, 17 May 2000 12:44:44 -0700
Michael Scott wrote:
> It seems to be between Twofish and Rijndael at this stage. I much prefer the
> latter, but Twofish has undoubtedly been marketed rather better.
>
> Would others agree that its a two horse race? (I nearly typed "two fish
> race").
No. Serpent and RC6 make some good arguments for themselves.
See the arguments at:
http://csrc.nist.gov/encryption/aes/round2/conf3/aes3papers.html
------------------------------
From: [EMAIL PROTECTED] (pink aka Chr. Boesgaard)
Subject: Re: Turing's Treatise on Enigma
Date: 17 May 2000 21:54:08 +0200
[EMAIL PROTECTED] (Richard Herring) writes:
> Not Found
> The requested URL /frode/crypto/Turing/index.html was not found on this server
> :-(
Works fine today -- maybe you hit the server while generating the page
or something.
------------------------------
From: "Axel Lindholm" <[EMAIL PROTECTED]>
Subject: Re: problem solving
Date: Wed, 17 May 2000 21:59:00 +0200
If a = A and b = B then there just might be a way to reform it as a
diofantic equation, like ax + by = c.
An equation like that can be solved using Euklides' algorithm if gcd(a, b) |
c. I havn't done any counting on it, so I can't tell for sure, but it might
be helpful for you.
Axel Lindholm
"Nicolas Riesco" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Is there any easy way to solve this kind of equation?
>
> (a*b*GIVENNUMBER)/ (A+B) = OTHERGIVENNUMBER
>
> the thing is that a and b are integers and threr's one solution only
>
> thanks
> --
> Para responder borra NO_SPAM en mi direccion...
>
------------------------------
** 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
******************************
