Cryptography-Digest Digest #16, Volume #13 Fri, 27 Oct 00 13:13:00 EDT
Contents:
Re: Is OPT the only encryption system that can be proved secure? (SCOTT19U.ZIP_GUY)
Re: On block encryption processing with intermediate permutations (James Felling)
Re: frequency analysis (JPeschel)
Re: End to end encryption in GSM ([EMAIL PROTECTED])
Re: Q: Computations in a Galois Field (Tom St Denis)
Re: BEST BIJECTIVE RIJNDAEL YET? (Tom St Denis)
Re: Rijndael and PGP (Tom St Denis)
Re: Collision domain in crypt()? (Tony L. Svanstrom)
Software with embedded keys (BillW)
Re: End to end encryption in GSM (Steve Cerruti)
Re: Software with embedded keys (Tom St Denis)
Re: End to end encryption in GSM ([EMAIL PROTECTED])
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Is OPT the only encryption system that can be proved secure?
Date: 27 Oct 2000 15:14:59 GMT
[EMAIL PROTECTED] wrote in <8tc2bi$k4e$[EMAIL PROTECTED]>:
>In article <[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY) wrote:
>> [EMAIL PROTECTED] wrote in <8tbhk0$7b8$[EMAIL PROTECTED]>:
>>
>> >Tim
>> >Thanks for your esoteric reply, but I dont think that Scott had this
>in
>> >mind when he referd to PK and PGP.
>> >
>>
>
>Please read your last message.
No quote what you want
>
>You claim that there is some inherent weakness in Public Key crypto in
>reference to PGP
Many of the weakness are well known and I have commented many
times on them, Look them up as you want be to do with the Hasy
Pudding cipher.
>
>
>> Not sure what you are talking about. But Tim writes my
>> on thoughts as what gets communicated far than what I usually
>> write as they get mangled in others peoples minds. So assume
>> he was better at explain what he thought I meant than what you
>> thought I meant.
>>
>> >Perhaps he will answer directly...I also have been meaning to ask him
>> >about his cipher, whether its a conventional product/feistel network
>> >cipher .....
>>
>> It is my own design I prefer to call it a cipher that is
>> based on a single cycle look up table 19 by 19. The key is
>> such that any single cycle table is possible. The users password
>> can be any size for any key. Since the key used for message is
>> actully encrypted by the password and stored in a encrypted key
>> file. THe sturcture is like comparing IDEA to a BLock except the
>> WHOLE file is treated as a single block. What words you wish to
>> call it is up to you. However if you go to Horsts description of
>> it at me webpage you can see it explained or look at the source
>> code.
>
>Sounds the same as the AES hasty pudding cipher....have you checked that
>one out?
Obviously you haven't looked at both. They are not the same.
>>
>> Aparrently its not conventional our maybe Mr wagner would not have
>> shot his mouth off is quickly to say the slide attack would destroy
>> it. He was proved wrong and one time admitted he could not follow
>> the code even though it was source code.
>>
>> David A. Scott
>> --
>> SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
>> http://www.jim.com/jamesd/Kong/scott19u.zip
>> Scott famous encryption website **now all allowed**
>> http://members.xoom.com/ecil/index.htm
>> Scott LATEST UPDATED source for scott*u.zip
>> http://radiusnet.net/crypto/ then look for
>> sub directory scott after pressing CRYPTO
>> Scott famous Compression Page
>> http://members.xoom.com/ecil/compress.htm
>> **NOTE EMAIL address is for SPAMERS***
>> I leave you with this final thought from President Bill Clinton:
>>
>
>
>Sent via Deja.com http://www.deja.com/
>Before you buy.
>
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website **now all allowed**
http://members.xoom.com/ecil/index.htm
Scott LATEST UPDATED source for scott*u.zip
http://radiusnet.net/crypto/ then look for
sub directory scott after pressing CRYPTO
Scott famous Compression Page
http://members.xoom.com/ecil/compress.htm
**NOTE EMAIL address is for SPAMERS***
I leave you with this final thought from President Bill Clinton:
------------------------------
From: James Felling <[EMAIL PROTECTED]>
Subject: Re: On block encryption processing with intermediate permutations
Date: Fri, 27 Oct 2000 10:34:59 -0500
Bryan Olson wrote:
> James Felling wrote:
>
> > Now the only way I can see of this scheme working in an even remotely
> > plausible way is by seperating the mixing from the feistel.
>
> I'd separate out the permutations entirely. :)
>
> > This is
> > only accomplishable if the feistel is unballanced, or in the case of a
> > balanced feistel, if the block is divided into an odd number of pieces
> > by the permuataion. Otherwise this attack applies, as one can always
> > find a set of properly formed blocks to peel off a 2 round pair.
> > Unfortunately most cyphers use block sizes that are power of two bits
> in
> > size. This will limit the aplicability of this method. In addition
> > such splitting will likely result in a substantial slowdown of the
> > cypher. OTOH, in these cases, this attack fails, and I have trouble
> > seeing an alternate line of attack. Brian?
>
> Can I plead burn-out? I think there are many potential
> problems, but I'm out of attacks. I would never have found
> the line of current attack had I not been home with the flu,
> bored out of my mind.
>
> I think the approach is misguided, for reasons previously
> stated. Furthermore, it solves no problem. What's wrong with
> a conventional chaining mode, IV and a modern block-cipher?
> True, we cannot prove security, but don't claim to solve that
> one without theorem in hand. The reason sci.crypt is flooded
> with techniques for symmetric encryption is not that the world
> needs them; it's that they're easy to produce.
>
> There may be interesting research questions on the value of
> message-in-one-block encryption. There's no clear indication
> whether it can be as (or more) efficient and secure, compared
> to fixed-size block schemes. Several advocates of
> variable-size blocks post here, but none of them seem
> interested in cryptanalysis.
>
> --Bryan
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
Agreed. I was merely exploring the idea. I agree that this methodology is
more trouble than it is worth at this point in time.
------------------------------
From: [EMAIL PROTECTED] (JPeschel)
Date: 27 Oct 2000 15:36:19 GMT
Subject: Re: frequency analysis
[EMAIL PROTECTED] writes:
>i think i could write one, in c, c++, basic, or java
>
>
>binary digit wrote in message ...
>>Anyone know of any programs out there that will try to do a frequency
>>analysis on a peice of enciphered text and it will output occording to the
>>amount of times a letter appears which letter is which?
You'll find the frequency analysis program "letcount" on the "Historic"
page of my web site. This program was used as a tool in
Singh's cipher challenge. It does single character and digraph
counts.
Joe
__________________________________________
Joe Peschel
D.O.E. SysWorks
http://members.aol.com/jpeschel/index.htm
__________________________________________
------------------------------
From: [EMAIL PROTECTED]
Crossposted-To: nl.comp.crypt,alt.comp.opensource,alt.cellular.gsm
Subject: Re: End to end encryption in GSM
Date: Fri, 27 Oct 2000 15:42:37 GMT
All the answers here refer to the old sim card...
The new Java based sim card should be more flexible and should allow u
to down load an applet to do DH
In article <[EMAIL PROTECTED]>,
Jouni Hiltunen <[EMAIL PROTECTED]> wrote:
> Greetings, first apologies in cross posting this to
> hell and back, but I'm really interested in
> extending privacy to cellular communications.
>
> Here is the problem, present GSM system offers you
> an illusion of privacy, communications are
> supposedly secured by encryption. However, depending
> on the operator and country you might have weak or
> no encryption and no way to verify how your
> communications are secured. Also encryption only
> happens over the air interface i.e. between phone
> and base station from there on all communications
> are plain. To make matters worse, standards require
> manufacturers to design legal interception gateways
> into the switches.
>
> What I have in mind is program which you could
> download into your phone which allows Diffie/Hellman
> key exchange and encryption of the following call to
> make sure your private conversations remain private.
>
> Anybody interested in developing a program to do
> that? I sure as hell cannot do it myself,
>
> Anyone interested in e-mailing me, please use the
> public key below. Post the follow-ups to sci.crypt
>
> Jouni Hiltunen
>
> -----BEGIN PGP PUBLIC KEY BLOCK-----
> Version: PGPfreeware 6.5.3 for non-commercial use
> <http://www.pgp.com>
>
> mQGiBDj8X6oRBADfW0QUWoXeQPV5Cys3xKXK4obFDX9NrR2p/1G6q9w8uC7AWh1z
>
> IFVL6kvdpsmpDLh9COXYUiAjti9T9pWCBLj8ja/XrYIF9bmsi0Vhf7szDYfuCU1N
>
> Ar44FcEAZv6+ifvNhb82TAzYwhX7cnBUVEm9Ql3BA8rsGNxtbl7HcUJnuQCg/zrC
>
> Ujw9BIg+W/IdCoqmZ3F99J8EALuRnbf8hi2+A9MMTUEEf5JppLzBIcE5W4PSYVN9
>
> dLXYpHwrOsn7HcaMtL53B5oCbbzYJX3fLvU9NZGEb9LHhhkFr/Q8B1jlhD00gapo
>
> hAUQYB9T8tDz+/LBxnRwxnZyBrNjtpo9rFmBRI0ulaKT2ILMNnFNSoiL7CHL2fw5
>
> NBw2A/9EkQnnLGCAGxP2DCfZVrbQiulJKA/v+FKIV9FlLy+UuINMWDebueLSSqbO
>
> Hz1qe/PhfmnPufQttfAFuiwG6x7F2DAVyTncx2GzXDAMwMMq3tf6XjjTXGgWqoby
>
> evV2xWIKEfJhMjfvGPRJu1gZVVtqGLhl1JEPK5bquyMXrft16bQrSm91bmkgSGls
>
> dHVuZW4gPGpvdW5pLmhpbHR1bmVuQGtvbHVtYnVzLmZpPokATgQQEQIADgUCOPxf
>
> qgQLAwIBAhkBAAoJEFHhnQ8I1H7Z4JYAoMjdiJ9LupLakXMWRkorpXt0lkS2AJ9y
>
> xjEJqXfdY87AkiNWoK9msTlkzLkCDQQ4/F+rEAgA9kJXtwh/CBdyorrWqULzBej5
>
> UxE5T7bxbrlLOCDaAadWoxTpj0BV89AHxstDqZSt90xkhkn4DIO9ZekX1KHTUPj1
>
> WV/cdlJPPT2N286Z4VeSWc39uK50T8X8dryDxUcwYc58yWb/Ffm7/ZFexwGq01ue
>
> jaClcjrUGvC/RgBYK+X0iP1YTknbzSC0neSRBzZrM2w4DUUdD3yIsxx8Wy2O9vPJ
>
> I8BD8KVbGI2Ou1WMuF040zT9fBdXQ6MdGGzeMyEstSr/POGxKUAYEY18hKcKctaG
>
> xAMZyAcpesqVDNmWn6vQClCbAkbTCD1mpF1Bn5x8vYlLIhkmuquiXsNV6TILOwAC
>
> Agf+Mi5yC47v4wqthNU6FAHcrVd2SMrhDlPDNtoR6m5yry3fO95FxBrXV4OnVVSe
>
> hb6OwysvG4yltg26wzCJHwaw1W2zVm4x3FWGJ5rLqvHS3T9z2lKvg6+Emvwk5mYs
>
> mTYPiQNN00mZpnxyjQ5byX+GOrUG04zaReuHe0Sy9OyUG9Gsi9ISD5Xw+Ww+8afe
>
> hSsp+xnojyD9e2GVwL1EHjYiS4U5MkQRJOYbrAF32g+4Ssydl/tT38bxU/dyp967
>
> VV6tD+RTFdRtgQeYzbEqOhIcC8rKE2CBO27icpEuLbtedf4wsjtp9qING8nM8tX1
>
> zIwvw3PT1n2h0//PPUvW5ATbHIkARgQYEQIABgUCOPxfqwAKCRBR4Z0PCNR+2YBi
>
> AKCvRJ7IVzYk14zbS8EwdJhjN8DEXwCg1X35+5PCRzXFqqvih8bgv2t1WGg=
>
> =isQf
> -----END PGP PUBLIC KEY BLOCK-----
>
>
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Q: Computations in a Galois Field
Date: Fri, 27 Oct 2000 15:47:21 GMT
In article <8tc3t2$q16$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> Tom St Denis <[EMAIL PROTECTED]> wrote:
> > In article <8tb8u9$is$[EMAIL PROTECTED]>,
> > "kihdip" <[EMAIL PROTECTED]> wrote:
>
> >> Field:
> >> In abstract algebra, a commutative ring in which all non-zero
> >> elements have a multiplicative inverse. (This means we can divide.)
>
> > If every element of a ring is a unit then i believe it's also a
field.
>
> Ummm.... since the definition of "unit" in a commutative ring is an
> element with a multiplicative inverse, I'd say you just repeated the
> definition given above.... (although you need to make sure you say
> all *non-zero* elements are units)
You're of course correct. Sorry dudes.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: BEST BIJECTIVE RIJNDAEL YET?
Date: Fri, 27 Oct 2000 15:50:18 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> Tom St Denis <[EMAIL PROTECTED]> wrote:
> : [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY) wrote:
>
> :> If you folks check at comp.compression you we see a note
> :> from Matt Timmermans on his super bijective PPM compressor
> :> with a built in bijective RIJNDAEL in modied CBC mode.
>
> [...]
>
> :> http://www3.sympatico.ca/mtimmerm/bicom/bicom.html
>
> : Perhaps us "know nothing" people prefer to leave our security to
> : security related algorithms.
>
> I believe that's why the product includes a bijective version of
Rijndael
> - without that there would be no security at all.
Of course Rijndael is bijective it's a friggin block cipher. You might
as well qualify it as a Square-Based Symmetric Keyed Bijective
Invertable Permutation Cipher.
> The PPM bijective compressor is intended to minimise known probable
> plaintext before encryption, reduce bandwidth and maximise the
> number of possible decrypts that look like plausible messages.
While the PPM codec may reduce the redundancy in the plaintext I have
yet to hear of any cryptosystem broken because the plaintext was ASCII
text only.
Think of the encryption as a "blinding" procedure. Even if the input
is ASCII the output is garbage. And don't forget that you might
say "ASCII has alot of redundancy" but by compressing the message you
are *NOT* increasing the entropy so the message is no more random then
it was before.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Rijndael and PGP
Date: Fri, 27 Oct 2000 15:52:42 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (SCOTT19U.ZIP_GUY) wrote:
> The truth asshole is that bijective compression has not been out
> very long so there are fewer methods. And size is not the only way
> to judge compression when one encrypts but the concept seems beyound
> your reach of lgoic so I will not go there you can't learn.
Um you're wrong. There are several ways to judge compression but
it's "security" is not one of them. If the codec has a good ratio,
uses little resources it's a good codec. Just because all possible
inputs decompress into something (which is a property of deflate btw)
doesn't make it any better/worse.
> The good NEWS is Matt has come up with a very hot bijective
compressor
> that beats the socks off 90% of the other compressors in the market.
> his code also combines it with Rijndael in a modifed CBC bijective way
> so one gets all in one package. But you don't need to use it. Wait
> for the PGP people to poorly impliment the AES cipher so that it is
> easier for the NSA to break.
The bad news is his codec only makes the ciphertext smaller, and no
more secure. Unless you have an attack on Rijndael you're not telling
us.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
Subject: Re: Collision domain in crypt()?
From: [EMAIL PROTECTED] (Tony L. Svanstrom)
Date: Fri, 27 Oct 2000 16:13:28 GMT
<[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] wrote:
>
> > Which algorithm did you use? Did it begin with SHA or was it MD5, or
> > Tiger, or RipeMD. If it was, please, I beg of you, publish the input
> > and their hashes, any collisions of those hashes would be of extreme
> > interest. If it wasn't one of those algorithms you might want to retry
> > with one of those algorithms, any of them should provide collision-free
> > operation for 4 million values.
>
> It was MD5..
>
> Unfortunately, I don't have that hash list any more.. I overwrote it with
> the 32-char digests.
>
> But I can can tell you that I was seeding the MD5 hash with a unique email
> address, first and last name, current timestamp, current PID and a pseudo
> random number which I thought should generate enough variety to give me unique
> hashes..
That just isn't right; either you did something that no one has ever
been able to do before, or something wasn't working right.
/Tony
--
/\___/\ Who would you like to read your messages today? /\___/\
\_@ @_/ Protect your privacy: <http://www.pgpi.com/> \_@ @_/
--oOO-(_)-OOo---------------------------------------------oOO-(_)-OOo--
on the verge of frenzy - i think my mask of sanity is about to slip
---ôôô---ôôô-----------------------------------------------ôôô---ôôô---
\O/ \O/ ©99-00 <http://www.svanstrom.com/?ref=news> \O/ \O/
------------------------------
From: BillW <[EMAIL PROTECTED]>
Subject: Software with embedded keys
Date: Fri, 27 Oct 2000 12:16:40 -0400
This is something of a newbie question; in part, the problem is that I
lack the correct terminology to even begin researching the question.
Basically, there are cases where encryption is used to tie data to a
licensed application (i.e., so that the data file cannot be exported to
and used by another vendor's application, or otherwise operated on). An
example of this would be the (failed) DVD CSS. The point here is that
encrypted data is being made available to a user through an intermediary
device (software or hardware) where the user isn't required to provide a
key. I have looked through the FAQ and some of Bruce Shneier's works,
but haven't found what I'm looking for.
The question is, is there actually a way of doing this that is actually
(reasonably) secure, especially for a software implementation? It seems
to me that to accomplish this, keys have to be kept with the data and/or
the decrypting software/hardware. The keys themselves may be encrypted,
but then of course, one needs another key to decrypt those -- at some
point, a key must be stored in plaintext form that makes the whole thing
a house of cards (e.g., by looking at the program executable with a
disassembler). To explain my purpose here, I'm trying to convince
someone that this is a bad idea, but I need some facts.
I hope my question makes sense; as I mentioned, even providing me with
terminology (what is this type of crypto application called?) or
references would be tremendously helpful.
Thanks!
Bill
------------------------------
From: Steve Cerruti <[EMAIL PROTECTED]>
Crossposted-To: nl.comp.crypt,alt.comp.opensource,alt.cellular.gsm
Subject: Re: End to end encryption in GSM
Date: Fri, 27 Oct 2000 16:09:09 GMT
In article <8tc7pb$p19$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> All the answers here refer to the old sim card...
No they don't.
> The new Java based sim card should be more flexible and should allow u
> to down load an applet to do DH
It doesn't get around the basic problem that the requested functionality
would have to be installed between where the voice was digitally sampled
and where it was encoded without changing the basic characteristics of
the human voice.
I also have some doubt that a JVM on a SIM card would have enough
throughput to process a real time audio stream. Have you got performance
metrics?
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Software with embedded keys
Date: Fri, 27 Oct 2000 16:35:22 GMT
In article <[EMAIL PROTECTED]>,
BillW <[EMAIL PROTECTED]> wrote:
> This is something of a newbie question; in part, the problem is that I
> lack the correct terminology to even begin researching the question.
> Basically, there are cases where encryption is used to tie data to a
> licensed application (i.e., so that the data file cannot be exported
to
> and used by another vendor's application, or otherwise operated on).
An
> example of this would be the (failed) DVD CSS. The point here is that
> encrypted data is being made available to a user through an
intermediary
> device (software or hardware) where the user isn't required to
provide a
> key. I have looked through the FAQ and some of Bruce Shneier's works,
> but haven't found what I'm looking for.
>
> The question is, is there actually a way of doing this that is
actually
> (reasonably) secure, especially for a software implementation? It
seems
> to me that to accomplish this, keys have to be kept with the data
and/or
> the decrypting software/hardware. The keys themselves may be
encrypted,
> but then of course, one needs another key to decrypt those -- at some
> point, a key must be stored in plaintext form that makes the whole
thing
> a house of cards (e.g., by looking at the program executable with a
> disassembler). To explain my purpose here, I'm trying to convince
> someone that this is a bad idea, but I need some facts.
>
> I hope my question makes sense; as I mentioned, even providing me with
> terminology (what is this type of crypto application called?) or
> references would be tremendously helpful.
The reason it won't work is because the security model is based on
obscurity instead of some intractable problem. (like
differential/linear models or guessing the key).
You simply can't hide secrets very effectively in the open.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED]
Crossposted-To: nl.comp.crypt,alt.comp.opensource,alt.cellular.gsm
Subject: Re: End to end encryption in GSM
Date: Fri, 27 Oct 2000 16:50:30 GMT
In article <8tc9at$qii$[EMAIL PROTECTED]>,
Steve Cerruti <[EMAIL PROTECTED]> wrote:
> In article <8tc7pb$p19$[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] wrote:
> > All the answers here refer to the old sim card...
>
> No they don't.
>
> > The new Java based sim card should be more flexible and should allow
u
> > to down load an applet to do DH
>
> It doesn't get around the basic problem that the requested
functionality
> would have to be installed between where the voice was digitally
sampled
> and where it was encoded without changing the basic characteristics of
> the human voice.
>
The Javasim toolkit is not low level enough to get at the sampled voice?
> I also have some doubt that a JVM on a SIM card would have enough
> throughput to process a real time audio stream. Have you got
performance
> metrics?
32 bit Java simcards are now available ....
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
>
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
** 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
******************************
