Cryptography-Digest Digest #182, Volume #10 Sun, 5 Sep 99 14:13:04 EDT
Contents:
Re: DES cfb stream cypher and "whitening" or initialization (Paul Crowley)
Re: DES cfb stream cypher and "whitening" or initialization (Tom St Denis)
Re: DES cfb stream cypher and "whitening" or initialization (SCOTT19U.ZIP_GUY)
Re: point of a cipher (SCOTT19U.ZIP_GUY)
Re: Description of SQ (Eric Lee Green)
Re: DES cfb stream cypher and "whitening" or initialization (Tom St Denis)
Re: NSA and MS windows (Anders Henriksson)
Some law informations... ("Michaël Chassé")
Re: point of a cipher (SCOTT19U.ZIP_GUY)
Re: NSA and MS windows (Anders Henriksson)
----------------------------------------------------------------------------
From: Paul Crowley <[EMAIL PROTECTED]>
Subject: Re: DES cfb stream cypher and "whitening" or initialization
Date: 5 Sep 1999 14:21:42 +0100
Scott Fluhrer <[EMAIL PROTECTED]> writes:
> >Otherwise... DROP DES. Use RC4 if you need a good stream cipher (or
> >just make up some Algorithm M clone). RC4 is about 20 times faster,
> >more compact and easier to get RIGHT. It's also not yet vulnerable
> >to any known attack.
> >
> Actually, it is. If the attacker knows the plaintext of a message, he
> can modify the ciphertext so that, when the receiver decrypts that
> modified ciphertext, he gets a message of the attacker's choosing (of
> the same length as the original message).
> CFB is slightly stronger, in that if the attacker attempts to modify a
> block, the next block will decrypt to garbage.
It's a bad idea to try and make your stream encryption do double duty
as an authenticator. Use a real MAC for authentication.
RC4 is a good choice in some ways, and it's not patented, but RSADSI
seem to regret not patenting it and demand licensing fees from some of
the people who use it on threat of unspecified legal trouble. Another
stream cipher (eg Panama), or a better block cipher (eg Blowfish) in a
chaining mode would do you better.
The original problem you pose is common to all forms of stream
encryption AFAIK: if you use all the same shared information to
initialise the stream, and the two plaintext streams start the same
way, the two ciphertext streams will start the same way, so you'll
leak information. You have to have something change with each new
stream: either the key if you use RC4, or the IV ("initialisation
vector" of the chaining mode) if you use a block cipher.
--
__
\/ o\ [EMAIL PROTECTED] Got a Linux strategy? \ /
/\__/ Paul Crowley http://www.hedonism.demon.co.uk/paul/ /~\
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: DES cfb stream cypher and "whitening" or initialization
Date: Sun, 05 Sep 1999 16:46:55 GMT
> Why DES?
>
> 1) Export issues.
> 2) Licence issues.
> 3) Marketing issues. We want to be able to tell the customer exactly
> what the encryption (we may even call it "scrambling") is so they
> can either build their own end easily, or at least check it out.
> PHBs might even know what DES is.
Basically you are trying to be 'buzzword' compliant right?
Can I find the name of your company so I can rememeber never to look at it
again?
Your real question is moot, why use DES in a NEW application? It makes no
sense... why not build 8086 desktops? Cuz they are obsolete.... DES might
have been strong 10 years before it was made, but not now...
Tom
--
damn windows... new PGP key!!!
http://people.goplay.com/tomstdenis/key.pgp
(this time I have a backup of the secret key)
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: DES cfb stream cypher and "whitening" or initialization
Date: Sun, 05 Sep 1999 17:14:37 GMT
In article <7qu1g2$1f0$[EMAIL PROTECTED]>, Tom St Denis <[EMAIL PROTECTED]> wrote:
>In article <7qtpp5$2id2$[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY) wrote:
>> In article <7qstef$[EMAIL PROTECTED]>, Scott Fluhrer
> <[EMAIL PROTECTED]> wrote:
>> >In article <7qsl65$5fs$[EMAIL PROTECTED]>,
>> > Tom St Denis <[EMAIL PROTECTED]> wrote:
>> >
>> >>In article <7qrflp$446$[EMAIL PROTECTED]>,
>> >> [EMAIL PROTECTED] (Cary O'Brien) wrote:
>> >>> I (like probably 10% of the readers) need to encrypt a data stream with a
>> >>> stream cypher. I want to use des in cfb mode (specifically
>> > des_cfb64_encrypt
>> >>> from libdes). The system will use shared secrets for keys. The problem
>> >>> is that the packet structure of the underlying data stream would be know
>> >>> to an attacker (ok, ok, it is ppp). I'm worried that this will provide
>> >>> the attacker with a known-cleartext attack. Not good.
>> >>>
>> >>> I propose to insert 4 bytes of "random" data to the beginning of the
>> >>> cleartext data stream on the encryption side, and drop the first 4 bytes
>> >>> on the decryption side.
>> >>>
>> >>> 1) Is this worth the effort?
>> >>> 2) Am I being otherwise stupid?
>> >>>
>> >>> Thanks,
>> >>
>> >>Here's a question.... why are you using des? Is this to be compatible with
>> >>another app? In this case your question is moot.
>> >>
>> >>Otherwise... DROP DES. Use RC4 if you need a good stream cipher (or just
>> >>make up some Algorithm M clone). RC4 is about 20 times faster, more
> compact
>> >>and easier to get RIGHT. It's also not yet vulnerable to any known attack.
>> >>
>> >Actually, it is. If the attacker knows the plaintext of a message, he can
>> >modify the ciphertext so that, when the receiver decrypts that modified
>> >ciphertext, he gets a message of the attacker's choosing (of the same
>> >length as the original message). In other words, the attacker can change:
>> >
>> > "Pay to Alice: $1064.76"
>> >
>> >to
>> >
>> > "Pay to Mallet: $999999"
>> >
>> >CFB is slightly stronger, in that if the attacker attempts to modify a
>> >block, the next block will decrypt to garbage.
>> >
>> What you said is ture sort of. Well at least for CFB but with the
>> wonderful error recovery feature of the NSA approved 3- letter chaining
>> the next block after the garbage block will be OK. And who knows what
>> the average user will do with a message that looks almost correct he
>> may not even notice.
>> You could use if you have the time and don't want error recovery use
>> RC4-257 or RC4-17 You use the current "plain text character" in a secondary
>> RC4 to generate a 8 bit caharacater that either directly pick the next
>> main RC4 fuction that is used or divide by 16 and use remander to pick
>> 1 of 16 RC4. This gets rid of error recovery that helps the NSA break the
>> code and the problem metioned in single RC4 where a message can
>> be modifed by the technique above. The nice thing about this approach
>> is it takes only about twice the speed of RC4 but greatly increase its
>> security.
>>
>> Example use tommys method and use padding in front of file
>> to encrypt old way each character
>> Cn = RC4(K,Pn)
>>
>> modifed way if using RC4-17
>>
>> T = RC4( K16,Pn-1); p-1 is an IV character know to both parites
>> K = S[ T % 16]; a 16 entry look up table that returns a pointer to the next
>> RC4 funtion to be used
>> Cn=RC4( *K,Pn) I wrote it as *K for reasons of pointer to show that the key
>> used is really just the key from the 0 to 15 choices.
>>
>> This is actaully a hair slower that 2 times RC4 but it gains you a lot in
>> securtiy.
>
>You are a very creative person Mr Scott. Might I just suggest using a
>digital signature?
>
>RC4 for example is very secure (as long as the key is random). The chances
>of guessing the next byte of keystream is about 1/256, which means forging
>the message without knowledge of the keystream is really hard.
Not that I can prove otherwise. But what makes you think RC4 is
so secure. You seem to base most of what you say only on blind key
searches and random guesses. Like others have pointed out this is not
the main way code is broken. You might make the statement plain
RC4 is secure enough for you. But your beliefs and wishes do not
mean that RC4 is not broken by the NSA. You can't possbily prove this.
But you continue to close your mind to any other possibility. Why
is that. It is as if Bruce and David Wagner have not said that it is weak
it must be strong. As another person on this forum has posted and as
something that I have not considered as much as I should. Bruce has
his own company. He may know more about security that he can
openly tell. I have not always been kind to him and just assumed
he was plain lying. But he may have little limited optoins on just
what he can and can not say. He may deny this but if he pissed off
the NSA or the people in power by letting out some secret out that
would enable the masses to do real encryption his company would
have to suffer and I am sure he has a sense of self preservation.
>
>If you know the plaintext yes you get keystream, but the signature should not
>match so it doesn't matter what you do.
>
>Tom
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
http://members.xoom.com/ecil/index.htm
NOTE EMAIL address is for SPAMERS
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: point of a cipher
Date: Sun, 05 Sep 1999 18:34:33 GMT
In article <0fwA3.21178$[EMAIL PROTECTED]>, "Richard Parker"
<[EMAIL PROTECTED]> wrote:
>[EMAIL PROTECTED] (SCOTT19U.ZIP_GUY) wrote:
>> One could take my starting tree for my adaptive huffman compression
>> they are in order. But if you modified them from the natural order I used
>> 0 to 255 to some other order as the way it is done in RC4 initialition you
>> could use that order as the starting end nodes of the tree. I would do that
>> :)
>> But since compression is legal to export no questions asked I have not
>> done this. But I have toyed with the idea of using RC4 with a small random
>> pad in front with a different RC4 for the initianlizetion part only for the
>> starting huffman tree. This would give a cipher of 512 bits and some might
>> find a use for this.
>
>While I can't propose an attack off the top of my head, I would not be
>surprised if an adversary could successfully use a meet-in-the-middle
>known-plaintext attack against this proposed encryption algorithm. If
>such an attack exists, it would limit the effective strength of the
>algorithm to aproximately the same strength as standard RC4.
>
>-Richard
I am sure you are very correct. It was just trying to stimulate
a little thinking. That is why I stated add the "random pad to the
text". I don't really like methods that require the random pad but
in this case it would be needed. It was just to point out if some
one actaully used my compression as a first pass for encryption
that if the order of the end values where changed notice they go
form 0 to 255 just like the array in RC4 during initailization you
could get this added hinderance for free. Since the person is going
to be doing this compression anyway.
But in no way is it as strong as proper solid 512 bit cipher.
But it has to be at least as safe as RC4 itself and if the
attacker knows you are using RC4 but the compression routine
is hidden or known to only you and your friend this would greatly
complicate the decrpytion if the NSA got it. I know that it is best
to assume everything is known about the cipher but as the NSA
knows it is even better if one can hide the cipher one can use and
in many cases between friends this kind of thing can work.
Especailly if the enemy does not know what you are doing.
Again it is not even as safe as a good 300 bit cipher.
It would be as bad as trying to use 2 8-bit random S-tables
instead of one random 16-bit S-table for an encryption
method.
Thanks again for pointing this out. I did not want to imply
that it was as good as a 512 bit method but rather that if one
is doing the compression any way this adds to the complexity
for free.
Actaully there are other ways to add to the security of the
huffman compression and I think I can put these at my site.
I can actaully use two huffman trees at once. One is the one
that my method is based on and the other is done so that
the compression stream as other porperties. This is not
just talk I have some working code I am testing. Since it
is not encryption I call it focusing. Notice that the
huffman compression looks nice if the tree is such that
at each split you have equal weights. If the weights aren't
equal you can focus what you use for the bits so that after
you compress you might make it easyer for a compression
to take place on a second huffman pass. Mainly for what
I am pushing the reverse pass. Also one could legally wirte
a huffman compression so that the output looks more white
this again could be used for who knows what but I will think
of some justifaction before I put it on my site. Example
when one looks at a file compressed by my method the first
bit of the second bite. Will most likley be a "0" this is because
the second byte in the uncompressed file is usually different
than the first byte. If I am "focusing" I could build two trees
for compression such that one tree is like what I have and the
second has a different 1/0 assignment such in this case if the
first byte had a 1 in first position I could use a 1 in first bit
of next byte to mean that a new character has appeared and that 0
would be the token for a repeated character. I could use this until
several new symbols where first used. And then reverse the meaining of
this bit if new symbols not appearing fast enough.
This code does not change the caharcteristics of
the length of the output file. But it does changes the patterns
appearing and the second pass huffman changes length based
on the focusing and undlerlying chacteristics of the first file.
Of course any thing directly on my US site would be pure compression
but one can mode the code. Since I will always give the source.
Note also this means in the real compressed file the ending
would not be the same as in the alternate file. Yes they would
occupy the same space but in the nonfocused huffman only zero
are added for padding and ones are taken off if cuttoff occurred
this is not the case in the forcused version since the pattern add as fill
or cut off is a function of the preceeding charcters.
Take Care
Dave
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
http://members.xoom.com/ecil/index.htm
NOTE EMAIL address is for SPAMERS
------------------------------
From: Eric Lee Green <[EMAIL PROTECTED]>
Subject: Re: Description of SQ
Date: Sun, 05 Sep 1999 10:42:57 -0700
"Douglas A. Gwyn" wrote:
> produced that would contradict that theory. This is *not* the
> case for mathematical "theories" such as the ones I mentioned;
> whenever their axioms apply to a system, their conclusions about
> that system are valid, and whenever their axioms do not match a
> system, they have nothing to say about that system. But when
> they apply, there is no question of their being overturned by
> newly discovered facts.
The problem with applications of mathematical theories to real life is
that the axioms of reality may not match the axioms underlying the
mathematical theory, or that there may be assumptions underlkying the
mathematical system that a) have not been expressed, or b) do not apply
in real life. A classical example is F=ma, which when applied
classically would mean that applying more force will cause more
accelleration, always, and thus one can accellerate right through the
speed of light. Except there's the underlying assumption that the mass
of an object is a constant -- which we know is not true as one
approaches significant fractions of the speed of light (relativity
effects, y'know).
Not that I think Shannon information theory is a shuck, just that as a
mathematical body of knowledge it's rather young and it's likely that
our understanding of what axioms are needed in order to model real-life
systems will continue to increase.
--
Eric Lee Green http://members.tripod.com/e_l_green
mail: [EMAIL PROTECTED]
^^^^^^^ Burdening Microsoft with SPAM!
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: DES cfb stream cypher and "whitening" or initialization
Date: Sun, 05 Sep 1999 17:36:22 GMT
In article <7qu4u2$1jsc$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (SCOTT19U.ZIP_GUY) wrote:
> Not that I can prove otherwise. But what makes you think RC4 is
> so secure. You seem to base most of what you say only on blind key
> searches and random guesses. Like others have pointed out this is not
> the main way code is broken. You might make the statement plain
> RC4 is secure enough for you. But your beliefs and wishes do not
> mean that RC4 is not broken by the NSA. You can't possbily prove this.
> But you continue to close your mind to any other possibility. Why
> is that. It is as if Bruce and David Wagner have not said that it is weak
> it must be strong. As another person on this forum has posted and as
> something that I have not considered as much as I should. Bruce has
> his own company. He may know more about security that he can
> openly tell. I have not always been kind to him and just assumed
> he was plain lying. But he may have little limited optoins on just
> what he can and can not say. He may deny this but if he pissed off
> the NSA or the people in power by letting out some secret out that
> would enable the masses to do real encryption his company would
> have to suffer and I am sure he has a sense of self preservation.
Ok. What is so wrong with RC4 that keysearch is not the fastest attack?
Now you should also mention how RC4 is being used though. If your key is
random and you use a salt RC4 is strong. There are no known ways to guess
the keystream or learn it without knowledge of the key. You seem to assume
that any cipher not designed by you is not strong, but tell me how RC4 is
weak? RC4 has been on the net for quite some time, and has been tought in
many classes, on many websites and in many usenet messages.
I think the main picture is how you use the cipher. You seem to miss that
more often then not. Of couse RC4 is weak if you use the same session key on
a million messages (your THINK message), just like your methods can be weak
if you use it wrong.
BTW, can you finish an idea without resorting to the NSA? Little known fact:
They are not the only people wishing to break crypto and benefit from it.
So try to replace 'NSA' with 'attacker' you will sound more professional.
Tom
--
damn windows... new PGP key!!!
http://people.goplay.com/tomstdenis/key.pgp
(this time I have a backup of the secret key)
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED] (Anders Henriksson)
Subject: Re: NSA and MS windows
Date: 5 Sep 1999 17:06:08 GMT
Roger Schlafly <[EMAIL PROTECTED]> wrote:
>Yes, it is plausible, but not terribly convincing either. Why did
>MS need 2 keys? Is the concern that MS would lose one private
>key? If so, why don't they make 2 copies, instead of using 2 keys?
>Is the 2nd key really just a backup, or are there circumstances
>in which only one of the keys is used?
(Note: Pure speculations ahead...)
It could be a _very_ simplistic way to regulate the possibilities to
use encryption outside the US. Have one key for domestic (strong)
cryptos, and the other for export rated cryptos.[1] Creating an export
rated version would then include wiping the domestic key, rendering
illegaly exported domestic modules unloadable.
It wouldn't hold for very long as the key could be exported and
reinstalled too, but it might keep Average Joe out of the strong
cryptography business. (The persistant, skilled guys wouldn't
be stoppable anyway...)
/Anders
[1] Does anyone know if the "backup" key has been used for any module
out there?
--
Right after Armageddon, using your temperature calibration instruments
may come in a little low on Maslow's hierarchy of needs. Food, shelter
and ISO 9000 compliance may come first...
-- Hart Scientific unofficial y2k page
------------------------------
From: "Michaël Chassé" <[EMAIL PROTECTED]>
Subject: Some law informations...
Date: Sun, 5 Sep 1999 12:06:06 -0400
Hi,
I'm living in Canada and I'd like to know if I can export a relativly
strong encryption program ( more than 256 bits). My program will be in the
public domain.
Thank's
Michaël Chassé
Québec, Canada
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: point of a cipher
Date: Sun, 05 Sep 1999 18:43:46 GMT
>For the love of god, and everything holy, listen (or read) the words I am
>writing...
Tom you wonder why I put you an my kill list for a while you don't think
you ask but never read what is written do you.
>
>One last point: DONT ENCRYPT HEADERS. If you fear giving out known
>plaintext don't encrypt them. If they are known headers anyways why bother
>encrypting them?
>
>Tom
Tom you really meant don't encrypt STRUCTURES yes there are obviuos
headers in some files. The average user does not know how to eliminte them.
Also the headers them selves may contain infortaion about the rest of the file
and these parts of a file can have a structure that leaks information to the
attacker.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
http://members.xoom.com/ecil/index.htm
NOTE EMAIL address is for SPAMERS
------------------------------
From: [EMAIL PROTECTED] (Anders Henriksson)
Subject: Re: NSA and MS windows
Date: 5 Sep 1999 17:23:18 GMT
Gordon Burditt <[EMAIL PROTECTED]> wrote:
>I don't know a lot about the details of the Crypto API: is it
>possible that code in the API itself could leak the session
>key to the NSA *independent of the type of encryption implemented
>by a module*?
If they have separated the PRNG from the crypto modules, they could
in theory do that, but I doubt they would. The problem here is
obtaining a covert channel to NSA computers in time. A separate connection
would be easily spotted, if not on the local machine then in routers
and firewalls.
You could of course piggyback the covert information onto the
cryptoblock being sent, but this might attract hacker attention
(unlabeled reserved blocks often do...) and/or break compatibility
with independent products.
It's much easier to weaken the key generation or PRNG.
/Anders
--
Right after Armageddon, using your temperature calibration instruments
may come in a little low on Maslow's hierarchy of needs. Food, shelter
and ISO 9000 compliance may come first...
-- Hart Scientific unofficial y2k page
------------------------------
** 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
******************************
