Cryptography-Digest Digest #790, Volume #11 Tue, 16 May 00 15:13:00 EDT
Contents:
Re: Is OTP unbreakable? (Paul Schlyter)
Re: Unbreakable encryption. ("C. Prichard")
bamburismus ("Ferrante Formato")
Re: Definition of "Broken" Cipher (Mike Rosing)
Re: Bigger numbers... ("C. Prichard")
BIG NUMBERS for CipherText ("C. Prichard")
Is there a patent protecting use of an encrypted 1024 byte mask ("C. Prichard")
Quake Encryption (Donald R. McGregor)
Re: Cascading Crypto Attack (Tim Tyler)
Re: Is OTP unbreakable? (Paul Koning)
Re: Definition of "Broken" Cipher (Paul Koning)
Re: AES Comment: the Hitachi patent (Paul Koning)
Re: Is there a patent protecting use of an encrypted 1024 byte mask (Eric Lee Green)
Re: BIG NUMBERS for CipherText (Eric Lee Green)
Re: Whitening ("C. Prichard")
Re: Unbreakable encryption. ("C. Prichard")
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Paul Schlyter)
Subject: Re: Is OTP unbreakable?
Date: 16 May 2000 17:37:23 +0200
In article <8fr420$j1o$[EMAIL PROTECTED]>,
Simon Johnson <[EMAIL PROTECTED]> wrote:
> Moreover, the key has to be the same length as the text you want to
> encrypt (repeating a key over the plain-text falls to an attack related
> to the one obove). Encrypting with a OTP is pointless simply because
> now you now have to figure out a way to secure the OTP key!!!!!!!
Well, OTP isn't always pointless. If you need secure communication
of a limited amount of data with someone in the future, when you have
no secure communications channel available, and if you have a secure
communications channel available now, you can exchange an OTP key
now with that person, to be used in the future.
Still, OTP has two weaknesses though:
1. An eavesdropper can figure out the length of the message. This
can be countered by adding random garbage to your actual message.
2. An eavesdropper can figure out that a message has been sent.
This can be countered in two ways: either by steganography (which
hides the message somehow), or by sending many extra messages
containing nothing but garbage.
--
================================================================
Paul Schlyter, Swedish Amateur Astronomer's Society (SAAF)
Grev Turegatan 40, S-114 38 Stockholm, SWEDEN
e-mail: pausch at saaf dot se or paul.schlyter at ausys dot se
WWW: http://hotel04.ausys.se/pausch http://welcome.to/pausch
------------------------------
From: "C. Prichard" <[EMAIL PROTECTED]>
Subject: Re: Unbreakable encryption.
Date: Tue, 16 May 2000 17:27:31 GMT
YOU can't break a random MASK that holds a message unless YOU know the =
key.
You don't know the key, applied. Go figure how many permable =
combinations are created with 8 ordinates having 96 possibilities each.
Get out of the newsgroup if you can't grasp the content.
-Charles Prichard
Eric Lee Green <[EMAIL PROTECTED]> wrote in message =
news:[EMAIL PROTECTED]...
> "C. Prichard" wrote:
> > Rather than distibute new masks for each message, its simply =
necessary to associate a mask key to create a somewhat unique mask.
>=20
> Sigh. Simple XOR? That was breakable a hundred years ago.=20
>=20
> There are standard terminology, techniques, and attacks. Learn them, =
then get
> back to us. The sci.crypt faq, posted once a month, has a large =
reference list
> of books to read before you can consider yourself "educated" in =
cryptography.
> You should at least read a couple of those before making a fool of =
yourself in
> this group -- or at least display some humility about the (lack of) =
knowledge.
> Lord knows I made a fool of myself plenty of times in the past, but =
was not
> ashamed to say that I knew little about cryptography and was having =
trouble
> understanding a concept or whether a certain technique was secure or =
not.
>=20
> Some key words or terms to think about:
>=20
> whitening
> public key encryption
> key exchange protocols
> replay attacks
> chosen plaintext attacks
> salt
> challenge
> ...
> =20
> --=20
> 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: "Ferrante Formato" <[EMAIL PROTECTED]>
Subject: bamburismus
Date: Tue, 16 May 2000 18:59:48 +0200
Any information about Turing's Bamburismus?
It was a probabilistic meythod settled to crack Enigma code in WWII
Thanks
Ferrante Formato
------------------------------
From: Mike Rosing <[EMAIL PROTECTED]>
Subject: Re: Definition of "Broken" Cipher
Date: Tue, 16 May 2000 12:30:39 -0500
Adam Durana wrote:
> For the purposes of this contest I think it is very fair to define breaking
> a cipher as finding an attack that can find the plaintext or key faster than
> brute force. This is not AES, it is just a contest for fun. Also this
> contest is just as much about analysis as it is about cipher design, and if
> someone finds an attack which is better than brute force their efforts
> should most definitely be rewarded by having the cipher in question removed.
I'll buy that. I think you should add another list, name of
cryptanalyst and
number of ciphers "broken". Since anything better than brute force
counts,
any cryptanalyst has to think pretty hard about every entry. I think
it'll
add motivation too, people can submit ciphers to the contest and try to
knock
off the competition at the same time. Even if their cipher doesn't stay
long,
a contestant can still have their name up in lights.
Patience, persistence, truth,
Dr. mike
------------------------------
From: "C. Prichard" <[EMAIL PROTECTED]>
Subject: Re: Bigger numbers...
Date: Tue, 16 May 2000 15:16:55 GMT
Assuming its necessary to minimze the key MASK exchange to only 8 bytes, =
its still possible to actually index a much stronger mask key of 32 to =
96 bytes.
Use would eliminate forced entry using brutal force almost entirely.
Calculate 96 ^ 32 =3D 2.70819204 E+63 (For a 32 byte MASK key.)
3628800 * 2.70819204 E+63 =3D 9.827487275 E+69
This 1024 byte mask can be severely alterred using masks of considerable =
length, with the increase in combinations staggering to comprehend. I =
estimate that its easy to index a 128 byte mask key with an 8 byte =
value. A breach in security would then come only from within the human =
system as one who had access to the MASK key at the time the message was =
handled by the system and then had the resources to break the CipherText =
userkey with roughly at least 58 million possibilities.
That the algorithm is so easily implemented is an unusual aspect of =
rather serious encryption. These are all calculations for messages that =
can use the default HTTP protocol without conversion.
-Charles Prichard
www.greentv.com
------------------------------
From: "C. Prichard" <[EMAIL PROTECTED]>
Subject: BIG NUMBERS for CipherText
Date: Tue, 16 May 2000 15:56:58 GMT
I'm getting possible combinations for KEYS to compare strength VS. BRUTE =
force attacks on algorithms.
Any cipher using a 56 bit key (seven or eight characters with or without =
compression, you can decide for youself ) has 256 ^ 8 =3D 1.844674407 =
E+19 possible key combinations. This is the relative strength index of =
56 bit DES.=20
My calculations involving CipherText and a known 1024 byte mask alterred =
by a private MASK key of only 32 characters far exceeds this standard =
yielding something on the order of several hundred million times =
stronger.
It looks like the technology to perform key exchanges is crucial to =
commanding a price for internet encryption. With the ability to =
calculate keys of 16 bytes (128 bits) anyone can go into the business =
licensing CipherText and a public 1024 byte mask.
After all MASKED CipherText several hundred million time stronger than =
the DES was with 56 bit encryption.
Bumping DES to 128 bits yeilds 3.402823 E+38 which is what many consider =
still secure. A 32 byte indexed MASK key creates a MASK for the =
CipherText message that is again several hundred million times stronger.
CipherText is a very serious algorithm, and its output can be =
transmitted using the default
HTTP protocol.
Charles Prichard
www.greentv.com
------------------------------
From: "C. Prichard" <[EMAIL PROTECTED]>
Subject: Is there a patent protecting use of an encrypted 1024 byte mask
Date: Tue, 16 May 2000 17:10:14 GMT
I seriously doubt there is already a patent protecting use of an =
encrypted 1024 byte mask for ASCII message transmission, in asystem for =
exchanging keys between ends to resolve the session mask key. With the =
ability to exchange strong keys, its possible to use nearly any other =
algorithm for message encryption with a user key.
CipherText has been designed to provide the security of inductrial =
strength encryption and compatibility with the default HTTP transmission =
prtocol without message conversion.
If anyone knows of a confounding-compelling reason why I should not use =
the 1024 byte masking solution for CipherText, I'd appreciate the =
comment.
Its such a logical solution to improving CipherText that I can't believe =
I'll even be allowed to use it. It has to be in use in some form =
already.
Thanks.
-Charles Prichard
------------------------------
From: [EMAIL PROTECTED] (Donald R. McGregor)
Subject: Quake Encryption
Date: Tue, 16 May 2000 17:55:09 GMT
A student is attempting to reverse-engineer the Quake III protocol.
It seems that the data in UDP packets it sends out is encrypted.
Anyone have any ideas about the scheme used? I figure it can't
be that complex, since they can't spend a lot of CPU or time
decoding the data, which is sent out at framerate.
Interestingly enough, it seems to be resistent to replay
attacks as well.
--
Don McGregor | You know trouble is brewing in the military when
[EMAIL PROTECTED] | the senior NCO says "I know a guy."
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Cascading Crypto Attack
Reply-To: [EMAIL PROTECTED]
Date: Tue, 16 May 2000 17:43:22 GMT
Richard Heathfield wrote:
: A recent thread (which I can't now find, hence this new thread)
: discussed the possibility of using more than one encryption technique:
[...]
: C = E9(E8(E7(E6(E5(E4(E3(E2(E1(P)))))))))
:
: It was later suggested that this could actually /weaken/ the encryption.
:
: If this is so, I have a suggested attack for any crypto system ever.
:
: Given any ciphertext, progressively weaken it by applying more and more
: encryptions of different kinds to it, until eventually the plaintext is
: revealed.
:
: Like the well-loved 1 == 2 proofs, this is (a) counter-intuitive and (b)
: surely wrong. Yet it proceeds logically from the proposal that
: successive encryptions weaken security.
:
: Where is the flaw?
Successive encryptions weaken security only extremely rarely, if ever.
In practice, successive encryptions are /vastly/ more likely to increase
security than to weaken it.
--
__________ Lotus Artificial Life http://alife.co.uk/ [EMAIL PROTECTED]
|im |yler The Mandala Centre http://mandala.co.uk/ Namaste.
------------------------------
From: Paul Koning <[EMAIL PROTECTED]>
Subject: Re: Is OTP unbreakable?
Date: Tue, 16 May 2000 13:05:35 -0400
[EMAIL PROTECTED] wrote:
>
> Is it possible to prove theoretically that OTP using a truely random key
> is unbreakable?
Yes; the proof is given in Communications Theory of
Secrecy Systems, C. E. Shannon, Bell System Technical
Journal, Vol 28, Oct 1949. Specifically, pages 679 to 682.
See http://www3.edgenet.net/dcowley/docs.html
Best to read the whole thing, actually. Lots of great
stuff there.
paul
--
!-----------------------------------------------------------------------
! Paul Koning, NI1D, D-20853
! Lucent Corporation, 50 Nagog Park, Acton, MA 01720, USA
! phone: +1 978 263 0060 ext 115, fax: +1 978 263 8386
! email: [EMAIL PROTECTED]
! Pgp: 27 81 A9 73 A6 0B B3 BE 18 A3 BF DD 1A 59 51 75
!-----------------------------------------------------------------------
! "A system of licensing and registration is the perfect device to deny
! gun ownership to the bourgeoisie."
! -- Vladimir Ilyich Lenin
------------------------------
From: Paul Koning <[EMAIL PROTECTED]>
Subject: Re: Definition of "Broken" Cipher
Date: Tue, 16 May 2000 13:20:17 -0400
Tom St Denis wrote:
>
> In article <[EMAIL PROTECTED]>,
> Paul Koning <[EMAIL PROTECTED]> wrote:
> > Tom St Denis wrote:
> > >
> > > It's quite simple. You don't say your car is broken because of a
> dent
> > > in the fender right?
> > >
> > > Well if I can attack a cipher X, in 2^100 steps is it really broken?
> > > Let's see, does it secure information? Yes. How is that broken?
> > >
> > > I think the definition of "broken" for a cipher is when finding the
> key
> > > and/or plaintext from ciphertext only is easier then brute forcing
> the
> > > key.
> >
> > Absolutely not. That's a dangerously weak standard.
> >
> > Chosen plaintext attacks are clearly feasible in practice in
> > many cases. Known plaintext attacks have been used for centuries.
> >
> > > Let's be realistic, getting 2^50 pairs of plaintext/ciphertext is
> not
> > > possible for two reasons. a) Bandwidth, b) smart people re-key
> their
> > > ciphers.
> >
> > That may be true. Or maybe not. Remember how quickly the
> > total throughput of the Internet is increasing.
>
> However most sane protocals will re-key to avoid using the same key for
> any long period of time. Say every 2^20 blocks....
2^20 blocks is NOT a long time! That's only 64 (or 128 for AES)
megabits. That's less than a second of traffic for the sort of
high speed links you can get as a high end Internet *user*, never
mind the far faster links used in the Internet core. (The latter
are less relevant since encryption is normally an end to end
activity. But if you have an OC-3 link into the Internet, you're
not particularly likely to rekey as often as you suggest, not
by a long shot.
Indeed, one of the arguments against *all* 64-bit blocksize ciphers
is that you need to rekey within 2^32 blocks, and that's rather fast
for modern high speed traffic...
paul
------------------------------
From: Paul Koning <[EMAIL PROTECTED]>
Subject: Re: AES Comment: the Hitachi patent
Date: Tue, 16 May 2000 13:15:30 -0400
Mok-Kong Shen wrote:
> ...
> I am surprised that , before the letter of Schneier now, apparently no
> effort whatsoever has been done by the AES submitters or by NIST
> in that direction. As I indicated elsewhere, it is strange that on the one
> side academics seem to neglect patents, in that patents are not cited
> in their publications ...
I think you have a highly inaccurate notion of what patents look
like and how they are searched. It would help if you tried a
little experiment: pick some topic that might be covered by patents
(say, DES) and find the relevant patents. Report back within
3 months with your results. Be sure not to miss any.
Ready? :-)
I can think of a lot of reasons why patents are rarely
cited in academic writing. Certainly one of them is that
it's *hard* to find things. The volume is very large, the
indexing is somewhere between feeble and non-existent, the
language is much worse even than academic english, and
the signal to noise ratio is quite bad.
Certainly you cannot validly claim on the evidence presented
that "no effort whatsoever has been done". It may well be
that a significant effort has been made without result.
Do you have any idea how hard it was to find that one patent that
Bruce commented on? I don't know the specific answer here, but
I certainly would not assume, as you appear to be doing, that
it was a simple matter to find it.
paul
------------------------------
From: Eric Lee Green <[EMAIL PROTECTED]>
Subject: Re: Is there a patent protecting use of an encrypted 1024 byte mask
Date: Tue, 16 May 2000 18:22:58 GMT
"C. Prichard" wrote:
> If anyone knows of a confounding-compelling reason why I should not use the 1024
>byte masking solution for CipherText, I'd appreciate the comment.
Read the literature on "whitening" and get back to us.
Summary: It's useful in certain circumstances, but if the cipher is already
strong, it doesn't add any more strength. All it accomplishes in that case is
to slow things down. If your goal is to obscure patterns, a cipher block
feedback mode with a reasonable-sized random initialization vector works
better, and it is allowable for initialization vectors to be sent "in the
clear" (does not harm the strength of the cipher). Otherwise you're not
accomplishing anything.
If you're going to use a slow cipher, just use 3DES. Slow, but proven, and has
survived every attack ever thrown at it. There's no need to invent a new slow
cipher, especially one whose details have not been fully disclosed and thus
which has not been fully cryptanalyzed and checked for possible attacks.
BTW, you are running up high scores on the Snake Oil FAQ's bogosity meter. You
may wish to re-read the Snake Oil FAQ and re-word your messages so they don't
score so high there. Or just read Tom St. Denis's postings, they are an
excellent example of how to present an unknown/untested cipher to this
newsgroup. If he was out of school, I'd hire the kid in a minute.
--
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: Eric Lee Green <[EMAIL PROTECTED]>
Subject: Re: BIG NUMBERS for CipherText
Date: Tue, 16 May 2000 18:33:19 GMT
"C. Prichard" wrote
> Any cipher using a 56 bit key (seven or eight characters with or without
>compression, you can decide for youself ) has 256 ^ 8 = 1.844674407 E+19 possible key
>combinations. This is the relative strength index of 56 bit DES.
Not exactly. 56 bit DES actually has slightly less strength than that, because
some differential atacks have been discovered. They require a lot of
ciphertexts, though.
Rule #1 of cryptography: The length of the key is not the same as the strength
of the algorithm. There are a number of attacks that can take less than 2^n
time to complete, where n is the number of bits.
I don't know why I'm bothering, actually. This is all explained much better in
"Applied Cryptography" (Bruce Schneier), which is actually comprehensible by
mere mortal engineers, unlike so many other cryptography texts out there. You
may wish to read some of the stuff on attacks.
> CipherText is a very serious algorithm, and its output can be transmitted using the
>default
> HTTP protocol.
I have experimented with extending the HTTP protocol to insure strong
authentication and key exchange without succeptibility to replay attacks.
Adding header values for 'Seq:' (Sequence) and 'Challenge:' (a challenge
string sent as part of the request by the other end) was necessary, amongst
other additions. While doable, it was quite clear that HTTP protocol was not
well suited to the task (not to mention the client problem!). That is why
HTTPS is layered on top of the SSL secure socket layer, rather than the secure
authentication and key exchange being part of HTTP itself.
--
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: "C. Prichard" <[EMAIL PROTECTED]>
Subject: Re: Whitening
Date: Tue, 16 May 2000 18:37:57 GMT
Thanks for the tip.
There is no problem with using a simple XOR pass to alter the whitening =
MASK before applying it to the already ciphered message. No problem what =
so ever.
You are mistaken about thinking a simple XOR leaves you vulnerable. It =
most certainly does not. Remember that it is not the message sent. It is =
ciphered with an actual message before you get your whack at it. Then =
you have no way to determine message from mask. No way without =
surmounting some form of attack on the calculated 5 E + 63 combinations. =
Go recheck your analysis. Its a very solid solution. My calculations for =
key combinations are valid. Simple XOR of the whitening mask works =
great. CipherText is a fast algorithm. Whitening will slow it down just =
a little.
-Charles Prichard
www.greentv.com
Eric Lee Green <[EMAIL PROTECTED]> wrote in message =
news:[EMAIL PROTECTED]...
> "C. Prichard" wrote:
> > If anyone knows of a confounding-compelling reason why I should not =
use the 1024 byte masking solution for CipherText, I'd appreciate the =
comment.
>=20
> Read the literature on "whitening" and get back to us.
>=20
> Summary: It's useful in certain circumstances, but if the cipher is =
already
> strong, it doesn't add any more strength. All it accomplishes in that =
case is
> to slow things down. If your goal is to obscure patterns, a cipher =
block
> feedback mode with a reasonable-sized random initialization vector =
works
> better, and it is allowable for initialization vectors to be sent "in =
the
> clear" (does not harm the strength of the cipher). Otherwise you're =
not
> accomplishing anything.=20
>=20
> If you're going to use a slow cipher, just use 3DES. Slow, but proven, =
and has
> survived every attack ever thrown at it. There's no need to invent a =
new slow
> cipher, especially one whose details have not been fully disclosed and =
thus
> which has not been fully cryptanalyzed and checked for possible =
attacks.=20
>=20
> BTW, you are running up high scores on the Snake Oil FAQ's bogosity =
meter. You
> may wish to re-read the Snake Oil FAQ and re-word your messages so =
they don't
> score so high there. Or just read Tom St. Denis's postings, they are =
an
> excellent example of how to present an unknown/untested cipher to this
> newsgroup. If he was out of school, I'd hire the kid in a minute. =20
>=20
> --=20
> 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: "C. Prichard" <[EMAIL PROTECTED]>
Subject: Re: Unbreakable encryption.
Date: Tue, 16 May 2000 18:11:19 GMT
Thank you for pointing out the mistake in forgetting how easily the key =
can be recovered knowing the original MASK.
The problem of using a known 1024 byte mask and using any keys to alter =
the mask is that its possible to simply recover the key however, what =
you will be attempting to do is recover the key from a message already =
ciphered with the message as well as the MASK key. Assuming no way to =
extract the key from the message without brute force, the combinations I =
have calculated are valid leaving you lots of work to do breaking it.
If I thought that there was a problem using a single XOR pass to alter =
the mask before use, I could try something more astute to garble the =
mask still restricting the output domain, that provide a good number of =
combinations without getting carried away with the method.
Using two keys, each within a small portion of the message domain where =
the second key is based on some relation to the original, will produce a =
good mask. CipherText has been used with a very strict key domain of =
only 10 characters to yield just fair encryption within the default =
protocol.
The algorithm cannot be reverse engineered though. It is based on two =
ciphers that mask the root key length with the second cipher having a =
rotation that is affected by the composite values of the root key. It is =
a good candidate for the needed solution that creates an alterred MASK =
without changing the domain of the original MASK. Its possible that =
opening the restriction on the CipherText key domain to something like =
32 or 42 values will be acceptable for the application.
It would diminish the security I calculated using 96 values in the key =
domain, but it will still provide good security:
A 16 byte MASK key with 42 possible elements would yield 42^16 =3D =
9.375 E + 25 combinations.
A 32 byte mask: 1.645 E + 63 combinations.
To be honest I need to be sure that the algorithm will restrict the =
output domain as desired when using 42 key domain elements, but this is =
great news for CipherText.=20
I see no problem using a single XOR pass to alter the MASK before =
encrypting an already encrypted message. No problem what-so-ever.
-Charles Prichard
Eric Lee Green <[EMAIL PROTECTED]> wrote in message =
news:[EMAIL PROTECTED]...
> "C. Prichard" wrote:
> > Rather than distibute new masks for each message, its simply =
necessary to associate a mask key to create a somewhat unique mask.
>=20
> Sigh. Simple XOR? That was breakable a hundred years ago.=20
>=20
> There are standard terminology, techniques, and attacks. Learn them, =
then get
> back to us. The sci.crypt faq, posted once a month, has a large =
reference list
> of books to read before you can consider yourself "educated" in =
cryptography.
> You should at least read a couple of those before making a fool of =
yourself in
> this group -- or at least display some humility about the (lack of) =
knowledge.
> Lord knows I made a fool of myself plenty of times in the past, but =
was not
> ashamed to say that I knew little about cryptography and was having =
trouble
> understanding a concept or whether a certain technique was secure or =
not.
>=20
> Some key words or terms to think about:
>=20
> whitening
> public key encryption
> key exchange protocols
> replay attacks
> chosen plaintext attacks
> salt
> challenge
> ...
> =20
> --=20
> 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
------------------------------
** 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
******************************
