Cryptography-Digest Digest #93, Volume #10 Sun, 22 Aug 99 11:13:04 EDT
Contents:
Re: all or nothing (wrapped pcbc) (Tom St Denis)
Re: Attacks on RC4 ? (Tom St Denis)
Re: Ciphile Software (Tom St Denis)
Re: NIST AES FInalists are.... (Paul Crowley)
Mercy (WAS Re: Ciphile Software) (Paul Crowley)
Re: all or nothing (wrapped pcbc) (SCOTT19U.ZIP_GUY)
Re: Blowfish algorithm - Is it full proof? (Dave Hazelwood)
Re: CRYPTO DESIGN MY VIEW (SCOTT19U.ZIP_GUY)
Re: Where to find (SCOTT19U.ZIP_GUY)
Re: Blowfish algorithm - Is it full proof? (SCOTT19U.ZIP_GUY)
----------------------------------------------------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: all or nothing (wrapped pcbc)
Date: Sun, 22 Aug 1999 11:20:48 GMT
In article <7pmvvs$mvu$[EMAIL PROTECTED]>,
David A Molnar <[EMAIL PROTECTED]> wrote:
> you generally would like your encryption to be non-malleable -- by
that I
> mean if an attacker changes bits in the ciphertext, it should
>
> a) be unable to pick any sort of target for the new plaintext
> and
> b) the legitimate decryptor should know the ciphertext was tampered
with.
> Preferably before decrypting, if possible.
>
> The classic example of why you need it is the "auction problem" (due
to
> Moni Naor and maybe others) : lots of people are bidding on items in
an
> auction. The attacker is not powerful enough to impersonate any of
these
> people, but he figures out how to flip the right bits to change, say,
the
> thousands' digit of a bid. Now he can mess with the bids of the
people he
> doesn't like -- and if the auction house doesn't confirm bids with
them
> thru some channel he doesn't control, they never know.
>
> You also need it for bit commitment. If an attacker can damage a
> commitment going between Alice and Bob such that it looks like some
> legitimate value (just not the one which was committed to), then when
it
> comes time to open and compare cmmitments, there will be trouble. The
> values will be different, and Alice and Bob will have no way of
knowing
> whether one cheated the other or who did it.
>
> so yes, it is a nice property to have.
I agree that bit commitment is a nice property, however I still don't
get it.
For example
C1 = Ek(P1)
C2 = Ek(P2 xor C1)
C3 = Ek(P3 xor C2)
... CBC stream ...
if I flip a early bit the rest will mess up, we know this. If I flip a
bit in the last word so what?
C3 = C3 xor bit
What does that give me? Without knowledge of the key I shouldn't be
able to tell C3 OR (C3 xor bit) from random. This means the attacker
should not be able to pick 'plaintext' targets unless they have known
plaintext (and it's the plaintext they need).
So althougth the receiver will get P1/P2 and not P3, they still will
detect a change in the plaintext and know the ciphertext was invalid.
...?
Tom
--
PGP 6.5.1 Key
http://mypage.goplay.com/tomstdenis/key.pgp
PGP 2.6.2 Key
http://mypage.goplay.com/tomstdenis/key_rsa.pgp
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Attacks on RC4 ?
Date: Sun, 22 Aug 1999 11:27:19 GMT
In article <7pn4fv$4l9$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> 1. What kind of attacks were performed on RC4?
> (I would very much appreciate an explaination understandable
> for a non-expert-cryptanalysts)
>
To the best of my knowledge the only attack is on weak keys (1 in 256
are weak this way) where 16-bits of key info is leaked in the first bit
of output. You can solve this by dumping the first n bytes. They
suggest a minimum of n=256, but I used n=1024 just to be ultra-
skeptical.
> 2. How much right or wrong are my beliefs on its security?
Quite well founded. It has been used in a variety of applications
including SSL (I believe?).
Tom
--
PGP 6.5.1 Key
http://mypage.goplay.com/tomstdenis/key.pgp
PGP 2.6.2 Key
http://mypage.goplay.com/tomstdenis/key_rsa.pgp
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: Re: Ciphile Software
Date: Sun, 22 Aug 1999 11:34:49 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Jerry Coffin) wrote:
> They don't tell us what (if anything) they do about key management,
> how they hash pass-phrases to derive keys, etc., etc. Even if we
were
> to blindly assume that they encryption they're using is itself highly
> secure, they might well have all sorts of other problems. If you
look
> around at breaks on encryption programs (as opposed to encryption
> algorithms) you quickly find that lots are based on absolutely STUPID
> things in the programs, and it wouldn't matter what algorithms they
> used -- in many cases, they do things like storing an encrypted key,
> then decrypting it at run-time and comparing it to the key you typed
> in. It's trivial to run things like this under a debugger and get
the
> key to decrypt something almost without doing any real work at all.
Generally though this type of attack isn't even remotely possible.
Otherwise many systems would fail. It's easier for example to exploit
a bad RNG when examining public keys then it is to drivel thru a HD
that you can't actually touch.
> In short, Ciphile's product MIGHT be a perfectly good one. OTOH,
they
> tell us little enough about the internals of how the program really
> works that it's virtually impossible to carry out a technical
> discussion of the algorithm(s?) involved at all. Furthermore, when a
> product smells this strongly of Snake Oil, there's little chance that
> the discussion would be worthwhile or meaningful if it were
possible.
> There are LOTS of interesting ciphers in the world, and full
technical
> disclosure is available on most, making meaningful and interesting
> discussions much easier.
A while back he sent me a mini-documentation about the algorithm. I
personally think he is full of @!@#. The algorithm is basically a very
large rotor. He makes use of 'million-bit keys' (sounds like DS) to
ensure 'high level of security' ... blah blah blah, in other words....
use PGP instead :)
Tom
--
PGP 6.5.1 Key
http://mypage.goplay.com/tomstdenis/key.pgp
PGP 2.6.2 Key
http://mypage.goplay.com/tomstdenis/key_rsa.pgp
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: Paul Crowley <[EMAIL PROTECTED]>
Subject: Re: NIST AES FInalists are....
Date: 22 Aug 1999 11:14:21 +0100
David A Molnar <[EMAIL PROTECTED]> writes:
> What is the largest and best equipped organization which regularly
> posts in the open literature, by the way?
I would have guessed IBM, am I wrong?
cheers,
--
__
\/ o\ [EMAIL PROTECTED] Got a Linux strategy? \ /
/\__/ Paul Crowley http://www.hedonism.demon.co.uk/paul/ /~\
------------------------------
From: Paul Crowley <[EMAIL PROTECTED]>
Subject: Mercy (WAS Re: Ciphile Software)
Date: 22 Aug 1999 11:49:44 +0100
David A Molnar <[EMAIL PROTECTED]> writes:
> For all that's said about David Scott and his system, at least he
> provides free source code for his ciphers and will answer questions.
> Many, MANY other ciphers like the AES candidates have nice descriptions of
> the exact details of their workings that I can read. Still other ciphers,
> like Mercy, have distinguishing characteristics (in Mercy's case, a LARGE
> block size) which make them very interesting to look at and worthy of more
> discussion than they currently receive.
Wow. Well that makes my morning, three times over, with a cherry on
top. I didn't think more than three people had read the description
of Mercy. For anyone curious about what he's talking about:
http://www.hedonism.demon.co.uk/paul/mercy/
FWIW I'm not nearly as happy with Mercy as I used to be myself.
First, nearly every part of it is more complex than it needs to be.
Second, it doesn't even approach making appropriate use of parallelism
on a modern processor - I hadn't read any of Craig Clapp's papers when
I started designing it. Most importantly though, I had thought I'd be
able to construct a good demonstration of resistance to DC and LC, and
now I don't think I can. I'm starting to think about how to build a
successor.
--
__
\/ o\ [EMAIL PROTECTED] Got a Linux strategy? \ /
/\__/ Paul Crowley http://www.hedonism.demon.co.uk/paul/ /~\
------------------------------
From: SCOTT19U.ZIP_GUY <[EMAIL PROTECTED]>
Subject: Re: all or nothing (wrapped pcbc)
Date: Sun, 22 Aug 1999 11:51:23 GMT
In article
<[EMAIL PROTECTED]>,
Eric Lee Green <[EMAIL PROTECTED]> wrote:
>
> Let me get this straight. You say having a check to see if the data is
> correct is bad because it allows an attacker to know whether he
> successfully decoded the data or not. Having an encrypted CRC (or MD5
> hash or etc.) as part of the data is okay. But having one outside is
> not?
It is best to not do what PGP (at least in there DOS
version). They allow a very short amount of work to be
done to test the key. This reduces the work of the attackeer.
I think it is Ok to have a fast check such as going a pkzip
of the encrypted file. This expands the file and allows one a
"small level of confidence" that the file was recieved correctly
but it does not allow the attacker to get any information about
the encrypted file. Yes an attacker could change the encrypted
text and change the outside CRC so that you think you have a valid
file. But when you decrypt the file you would get garbage since
WPCBC is for "all or nothing encryption".
>
> Seems to me that if the attacker gains one of the plaintexts, through
> some out-of-channel attack (e.g. bribed someone to give one to him),
it
> doesn't matter whether the CRC is inside or outside of the data
because
> then he'll know it's inside the data and where exactly where it is
> located inside the data, meaning that he can use it to mount an attack
> on other messages (where the plaintext is unknown). Although I'd
> personally put it inside the data, myself, simply as a screen door for
> the script kiddies (i.e., will keep out people not willing to go
through
> the trouble of intercepting a plain text through some out-of-channel
> attack). But it does appear to me that a good encryption scheme should
> hold up even if a plain text is intercepted, meaning that it should
not
> matter whether the check data is inside or outside of the data.
>
IF you want to use a CRC inside the data ( I would not ) you can
do this as a quick check to see if the file decrypted corrected. But
when Using WPCBC and having the CRC as part of the text does not
give as much information to the attacker sinee he would still have
to do many complete passes through the whole file to get even a look
at the CRC instead of just one pass through a few blocks of the file
as in PGP.
Knowing the structure of a WPCBC file is much less important than
in the Weak error recovery methods that are blessed by the crypto
gods. Since with them file posisssstion is very critcal and allows
only a few encrypted blocks to be looked at. This does not occur
in WPCBC.
> --
> Eric Lee Green http://members.tripod.com/e_l_green
> mail: [EMAIL PROTECTED]
> ^^^^^^^ Burdening Microsoft with SPAM!
>
--
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
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED] (Dave Hazelwood)
Crossposted-To: comp.lang.clipper,comp.security.misc
Subject: Re: Blowfish algorithm - Is it full proof?
Date: Sun, 22 Aug 1999 13:22:00 GMT
Humm....does this mean that if after encrypting a file with blowfish I
change a few bytes here and there that it becomes even more secure?
1. Because even if the key should be compromised or found only I
know that the 69th byte was changed from 13 to 22 and must be restored
before the message can be decrypted?
2. Because if the Blowfish algorithm is ever factored my messages are
still secure?
3. Because even if my message is brute forced it yields garbage?
3. Because it will drive the NSA nuts knowing that everyone is doing
this and every message may be unique?
4. Because it sends a message to Bill Clinton that his new law to
break into our homes and computers and sniff for passwords is easily
defeated by criminals but further erodes the privacy of the majority?
Seriously...can the experts out there comment on whether changing
say a dozen random bytes in a Blowfish encrypted file is a worthwhile
step to improve security?
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: CRYPTO DESIGN MY VIEW
Date: Sun, 22 Aug 1999 14:45:19 GMT
In article <[EMAIL PROTECTED]>, Mok-Kong Shen <[EMAIL PROTECTED]>
wrote:
>In the detailed example I gave the 9 bits were 0 10111010. You
>agreed above that these are all written out. So the 'correct' file
>terminates there (with neither additions nor deletions that could
>take place with your modified Huffman scheme in other more general
>situations). Hence we don't have disagreement as to the content
>of the last 2 bytes of the 'correct' output file. I must nevertheless
Your word "correct" is misleding and wrong. File A which
is a compress file ends in 2 byte in byte 1 there is 7 bits for the x's
the remaining 9 bits forn the next huffman symbol. When the
file is decompressed you get 2 8 bit characters for these lats 2
symobls.
In your next example the compressed file is shorter by one byte
so the symobl that has the X token is followed by the trailing zero
bit. When decompressed you get exactly the same as first file
except that it is shorter by one character. Note neither is correct
or incorrect they are just two seperate cases. And the mapps
are still one to one for the cmpressed and decompressed files
>take this opportunity to say here that I have never understood
>why you ever attempted to omit writing certain bits out at the end
>of the process in case the (unmiodified original) Huffman algorithm
>generate these. Why did you ever do modifications to a well-known
>algorithm?? Why did you want to make the output file a (very) tiny
>bit shorter at all?? Does the saving of one single byte count in
>practice? How many bytes does an output file in practice have? Have
>you ever computed for a concrete example in practice the percentage
>of your 'saving'?? By how much have you complicated your program
>logic through your persuit for this trivial 'economy'? Further,
>since your device (modification) has not been discussed and examined
>in the public, I can't even be sure that your modification is sound
>theoretically. (Sorry to say that. Note that a discussion in the
>public presupposes that you explain your modification either in plain
>English or else in precise and short pseudo-code and not require
>others to dig into your lenghty C code or, even worse, to simply run
>tests with the program!)
It is sound I have never found a failure in the one to one mapping.
Obviously the saving in space is best for small files. The reasin I made
it one to one. Is so that no information leakage. If the file is not one to
one if you compress anad then encyrpt the file. Lets say an enemy gets
the file. He tries a key ( or math reduction of some type) He then exaims
the output file that was produced with the guessed key. He then notices
that when he decompress the file and recompressed the file is not the
same. There fore the key was wrong and he goes on to next key. That
is why the one to one feature is critical. But I bet you haven't the foggest
notion of what I am saying.
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: Where to find
Date: Sun, 22 Aug 1999 14:58:39 GMT
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
(David Hamilton) wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
>
>"karl malbrain" <[EMAIL PROTECTED]> wrote:
>
>>Who said that David was a professional?
>
>I didn't. In my post Message-ID: <[EMAIL PROTECTED]> I
>referred to David A. Scott's UNprofessionalism. You were the first to refer
>to 'professional' in your post Message-ID:
><ehiv3.82$[EMAIL PROTECTED]> when you said 'Stating one's
>intentions is a matter of professional courtesy'. You cut this sentence of
>yours in your post Message-ID: <Ddnv3.395$[EMAIL PROTECTED]>
>when giving my direct response which was 'Admitting one's failures is a
>matter of professional honesty'. Thus you may have given a wrong impression
>to people.
>
>>He doesn't act like one, nor does
>>he describe himself as one.
>
>I don't know whether David A. Scott describes himself as a professional
>cryptographer or not. In fact, I don't know or how he describes himself.
>
>>He either doesn't want to, or is unable to,
>>meet the standards of professional practice here.
>>That's his own SUBJECTIVE
>>determination / OBJECTIVE motivation -- leaving your (unanswered) question
>>dishonest by your own criteria.
>
>I'm not sure I understand what you've written above. Which question of mine
>is dishonest and why? What are my 'own criteria'?
>
Your a very dishonest man and I use that term losely. Bescasue my writting
sucks and I think your an asshole. You feel that you have to tell
beginners that my software program is weak. Well you don't have a fucking
clue as to if is weak. Even Wagner who at first thought it might be weak was
wrong and appeartly accoording to Joe P. had the balls to admit it. But
since you lack the mental ability to test code you have to make judgements
with out any real tests. As if your fucking judgements mean shit. My code
is better than any thing you can code. IF you don't like my style tough shit
but that is no indication that the code is weak. It just shows your a belly
aching asshole with nothing better to do. Than to try to make fun of one poor
in English. But your judgements have nothing to do with scott16u or scott19u.
But I doubt you have the brains to understand this.
>I see that you have also avoided giving the 'branch of advanced learning or
>science' in which you view me as lacking professionalism. Why is this?
>
>
>David Hamilton. Only I give the right to read what I write and PGP allows me
> to make that choice. Use PGP now.
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)
Crossposted-To: comp.lang.clipper,comp.security.misc
Subject: Re: Blowfish algorithm - Is it full proof?
Date: Sun, 22 Aug 1999 15:10:43 GMT
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Dave
Hazelwood) wrote:
>Humm....does this mean that if after encrypting a file with blowfish I
>change a few bytes here and there that it becomes even more secure?
>
> 1. Because even if the key should be compromised or found only I
>know that the 69th byte was changed from 13 to 22 and must be restored
>before the message can be decrypted?
Sorry but if you use Something Fishy or smelly and only change one byte
the only part of file that would be messed up is the blocks right in the area
of where the changed byte occurred. This is because the "blessed" chaining
methods have "error recovery" something left over from the old days before
error correcting protocols for data flow were used. This error recovery
porperty allows the attacker to only look at a small portion of the file to
test if the attacker has the right key. So changing the 69th byte of the
output file would aid little in hiding the complete file.
I wish some of the crypto gods would comment on this stuff. The fact
that they don't should make any reasonable person to realize they
really don't want people to use stong crypto. If one is limited by using
weak crypto you could increase the safety of breaking and use your
method of moding one byte if you compress with my routine and then
reverse the file and compress again as shown on my page. This would
partially make it all or nothing and then would be less subject to the
piecemeal attack if you forced to use a weak AES method.
http://members.xoom.com/ecil/compress.htm
>
>2. Because if the Blowfish algorithm is ever factored my messages are
>still secure?
>
>3. Because even if my message is brute forced it yields garbage?
>
>3. Because it will drive the NSA nuts knowing that everyone is doing
>
>this and every message may be unique?
>
>4. Because it sends a message to Bill Clinton that his new law to
>break into our homes and computers and sniff for passwords is easily
>defeated by criminals but further erodes the privacy of the majority?
>
>Seriously...can the experts out there comment on whether changing
>say a dozen random bytes in a Blowfish encrypted file is a worthwhile
>step to improve security?
or use WPCBC chaining which is hard to program unless you inderstand
scott16u or scott19u
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
------------------------------
** 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
******************************
