Cryptography-Digest Digest #70, Volume #12 Tue, 20 Jun 00 12:13:01 EDT
Contents:
Re: Online Text Encryption ("Dan Coyle")
Re: Random sboxes... real info (Tim Tyler)
Re: S/MIME + Netscape v47 serious problem in symmetric encryption ... (Padgett
0sirius)
Re: Variability of chaining modes of block ciphers (Runu Knips)
Re: Is this a HOAX or RSA is REALLY broken?!? (Runu Knips)
Re: New Hash Function (Runu Knips)
Re: Is this a HOAX or RSA is REALLY broken?!? (Mark Wooding)
Re: New Hash Function (Runu Knips)
Re: XOR versur MOD ("Tony T. Warnock")
Re: small subgroups in Blum Blum Shub (Klaus Pommerening)
Re: Variability of chaining modes of block ciphers (Guy Macon)
Re: MD5 Expansion (Arthur Dardia)
Twofish book (Bruce Schneier)
Re: MD5 Expansion (Mark Wooding)
Re: MD5 Expansion (Mark Wooding)
Re: MD5 Expansion (David Hopwood)
Re: Cryptographic voting (zapzing)
Re: small subgroups in Blum Blum Shub ("Tony T. Warnock")
----------------------------------------------------------------------------
From: "Dan Coyle" <[EMAIL PROTECTED]>
Subject: Re: Online Text Encryption
Date: Tue, 20 Jun 2000 07:15:25 -0500
Thank you for clarifying.
Since the System, Assigns the Salt, wouldn't you have to decrypt the
message, on the same system that you encrypted it on. So that you would get
the same Salt value when you went to decrypt? That would kill the
portability of the message, IE no good to email to someone else with a
different machine. Another way to prevent dictionary attacks then, would be
to, not include the Password, in an encrypted form, in the message.
Dan Coyle
"Trevor L. Jackson, III" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Dan Coyle wrote:
>
> > Salt -
> >
> > "An unnecessarily cute and sadly non-descriptive name for an arbitrary
> > value, unique to a particular computer or installation, prepended to a
> > password before hash authentication. The "salt" acts to complicate
attacks
> > on the password user-identification process by giving the same password
> > different hash results on different systems. Ideally, this would be a
sort
> > of keying for a secure hash. " (source Ritters Dictionary of Technical
> > Cryptography - http://www.io.com/~ritter/GLOSSARY.HTM#Salt)
> >
> > This definition states that a salt is a, machine specific, algorithm for
> > modifying password hashes stored in a message. It does not discuss using
a
> > given amount of time to encrypt the message, so if there is another
> > definition that you would like to show me, please give me an URL or
> > something so that I may see your sources.
>
> The definition you quoted leaves ont a significant purpose of salts. On a
> single system salts confound simple dictionary attacks. A simple
dictionary
> attack proceeds through the dictionary encrypting each word once, and then
> comparing the ciphertext to each of the encrypted passwords. This works
if the
> password is encrypted "bare" because if you and I use the same password
the
> system will store the same ciphertext for each of us.
>
> On a salted system each password is stored with a salt value that is
included in
> the encryption. Since the system assigns each password a distinct salt,
if you
> and I use the same password we'll get distinct ciphertexts. Then the
simple
> dictionary attack will fail. In order to attack a salted system one must
> reencrypt each word of the dictionary with the salt for each password.
This is
> a significantly larger computation budget for the attack. It become
> "encrypt"-bound rather than "compare"-bound.
>
> I'm certain Terry Ritter and most readers are familiar with this usage.
>
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Random sboxes... real info
Reply-To: [EMAIL PROTECTED]
Date: Tue, 20 Jun 2000 12:27:13 GMT
michael <[EMAIL PROTECTED]> wrote:
: Well those 2^128 permutations out of the entire (2^64)!
: permutations are strong with respect to diff and linear
: analysis. They are hardly any random permutation, the
: permutations are *dictated* by the algorithm itself.
This sounds like Tom's point again. I don't think it's right.
The 2^128 permutations are no stronger against the
attacks you mention than random permutations would
typically be - and the former are quite likely to be
weaker than random permutations against something not
yet discovered.
"Random" is used above in the sense of statistically indistinguishable
from a random sequence. The other conceivable meaning would seem to imply
that the permutations are not fixed - a situation which would not yield
a working cypher - and is obviously nonsense.
--
__________ Lotus Artificial Life http://alife.co.uk/ [EMAIL PROTECTED]
|im |yler The Mandala Centre http://mandala.co.uk/ VIPAR GAMMA GUPPY.
------------------------------
From: [EMAIL PROTECTED] (Padgett 0sirius)
Crossposted-To: comp.security.pgp.discuss
Subject: Re: S/MIME + Netscape v47 serious problem in symmetric encryption ...
Date: Tue, 20 Jun 2000 07:35:54
> Anyway, it would be interesting to find out why it keeps reporting
> how to find that it is reporting ONLY and not practically using only 40
>bits encryption ?
Because it is S/MIME v2 which had as a MUST 40 bit symmetric. OTOH S/MIME
v3 (RFC 2630-2634) requires strong encryption matching FIPS 140-1.
A. Padgett Peterson, P.E. CISSP: Cybernetic Psychophysicist
http://www.freivald.org/~padgett/index.html
to avoid antispam use mailto:[EMAIL PROTECTED] PGP 6.5 Public Key Available
------------------------------
Date: Tue, 20 Jun 2000 15:01:02 +0200
From: Runu Knips <[EMAIL PROTECTED]>
Subject: Re: Variability of chaining modes of block ciphers
Mok-Kong Shen wrote:
> The most popular block chaining mode seems to be CBC.
> There is also PBC which chains with plaintext blocks.
> One can also accumulate the previous blocks for doing the
> chaining and use plaintext as well as ciphertext for
> chaining. (I used this in one of my own designs.) By
> combinatorics this gives 8 variants. Obviously one can
> also use modular addition instead of xor and do some
> random rotations if one likes. I think that the variability
> of chaining modes could be advantageousy exploited such
> that the actual chanining mode used in a message has to be
> guessed by the opponent, thus redering his task much more
> difficult.
I don't like that. While ciphertexts have the known property
of having no statistical properties and depend upon all
texts before the actual one, XOR'ing with the previous
plaintext has no such property. Just think about the case
that the plaintext consists of nothing but zero. PBC is much
more like EBC than like CBC.
XOR'ing with both the previous plaintext block and the last
cipherblock is possible but I can't see the big advantage, as
well as using '+' instead of XOR etc.
And using a different chaining method than CBC might confuse
the opponent, but not much more than using a nonstandard
cipher algorithm, isn't it so ?
------------------------------
Date: Tue, 20 Jun 2000 15:02:36 +0200
From: Runu Knips <[EMAIL PROTECTED]>
Subject: Re: Is this a HOAX or RSA is REALLY broken?!?
tomstd wrote:
> [EMAIL PROTECTED] (Mark Wooding) wrote:
> >S. T. L. <[EMAIL PROTECTED]> wrote:
> >> <<The optimists in the field believe that in 5 or 10 years
> >> it will be possible to build a quantum computer that can
> >> factor the number 4 as 2x2.>>
> >>
> >> I believe that 15's already been factored. Now for something
> big,
> >> like 77....
> >
> ><fx: hand in the air> Ooh! Ooh! I can do that one!
>
> Simple 77 = 23 * 9. I am glad I am doing goodly in math.
You're computing in some GF (something), are'nt you ?
------------------------------
Date: Tue, 20 Jun 2000 15:05:53 +0200
From: Runu Knips <[EMAIL PROTECTED]>
Subject: Re: New Hash Function
tomstd wrote:
> >In short: I can't see any way to attack it. :) Why
> >can't you store the loop results with '=' instead of
> >'+=' or remove those ugly rotations ? ;-) However,
> >I would use addition instead of XOR in the
> >initialization of W[] so that parity doesn't slip
> >through.
>
> I can't just store it because it's a feistel and it would be
> degenerative if I did that.
HEY ! That was a joke !!! :))))
> I can't use addition in the W[]
> expansion since I would have to use a primitive trinomial and I
> don't want todo that.
Hmm. I don't understand that.
> I think I could change the "mixing" part at the end of the
> feistel function to addition instead of xor and make it a tad
> less xor'ish...
Yep, that is also an option.
------------------------------
From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: Is this a HOAX or RSA is REALLY broken?!?
Date: 20 Jun 2000 13:12:09 GMT
tomstd <[EMAIL PROTECTED]> wrote:
> Simple 77 = 23 * 9. I am glad I am doing goodly in math.
Good luck in your exams. I've a feeling you might need it if you
answered all of the questions this well... ;-)
-- [mdw]
------------------------------
Date: Tue, 20 Jun 2000 15:15:16 +0200
From: Runu Knips <[EMAIL PROTECTED]>
Subject: Re: New Hash Function
tomstd wrote:
> One observation that I don't like is that in an attack the
> attacker gets five rounds for free since W[0..14] are not
> changed in anyway by the expansion.
5 rounds of 32 is not much, and in fact I think its
a good idea to start with the original data.
------------------------------
From: "Tony T. Warnock" <[EMAIL PROTECTED]>
Subject: Re: XOR versur MOD
Date: Tue, 20 Jun 2000 07:57:47 -0600
Reply-To: [EMAIL PROTECTED]
Mok-Kong Shen wrote:
> "Tony T. Warnock" schrieb:
>
> > The operands are in order, these are the result tables
> >
> > XOR for 2 bits ADD for 2 bits
> > 00 01 10 11 00 01 10 11
> > 01 00 11 10 01 10 11 00
> > 10 11 00 01 10 11 00 01
> > 11 10 01 11 11 00 01 10
> >
> > Each row and each column each table is a permutation of the
> > corresponding row or column of the other table. Both tables are latin
> > squares. For larger bit strings, the tables look even more different
> > from each other.
>
> I see that I misunderstood you. You mean in effect that a+x and a^x
> generate the same set of values. However, I don't yet clearly see what
> (practically essential) implications can be drawn from that. An analogy
> would be comparing x and E(x), where E is a block encryption and
> both x and E(X) generate the same set of values.
The main point is that either XOR, ADD, SUB (or any latin square)
combination of two input streams generates the same set of values in the
output stream. The probability distribution of the output will be flatter
than the distribution of either input stream unless either stream is
uniformly distributed (in which case the output will be uniform) or either
stream is concentrated at one value (in which the output will be a
permutation of the input.) Statistically, all combination methods will be
similar.
------------------------------
From: [EMAIL PROTECTED] (Klaus Pommerening)
Subject: Re: small subgroups in Blum Blum Shub
Date: 20 Jun 2000 14:33:12 GMT
In <[EMAIL PROTECTED]> Terry Ritter wrote:
> The short cycle weakness is a weakness which does not have to exist,
> but which is normally allowed to exist. The fact that this additional
> weakness possibility is not eliminated is sufficient to show that any
> resulting system cannot be "proven secure." End of story.
>
So what do you think of RSA?
There you also have short cycles, and you can't avoid
them, because they come from the plain text, not from the
key. Remember the iterative attack?
[Assume m = plain text, c = cipher text, E = public encryption function]
If c = E(m), then consider the cycle E(c), E(E(c)), E(E(E(c))),
..., until E^s(c) = c. Now m = E^{s-1}(c).
Hey - we have broken *every* public key encryption.
"The fact that this additional weakness possibility is not
eliminated is sufficient to show" ... that asymmetric encryption
cannot be proven secure.
By the way - finding a key for a symmetric128 bit encryption
by pure guessing has a much higher success probability than
running into a cycle for BBS or RSA with 1024 bit modulus.
Therefore symmetric encryption also cannot be proven secure.
End of story.
--
Klaus Pommerening [http://www.Uni-Mainz.DE/~pommeren/]
Institut fuer Medizinische Statistik und Dokumentation
der Johannes-Gutenberg-Universitaet, D-55101 Mainz, Germany
------------------------------
From: [EMAIL PROTECTED] (Guy Macon)
Subject: Re: Variability of chaining modes of block ciphers
Date: 20 Jun 2000 10:51:11 EDT
Runu Knips wrote:
>And using a different chaining method than CBC might confuse
>the opponent, but not much more than using a nonstandard
>cipher algorithm, isn't it so ?
I like the idea that you nassume that your attacker knows everything
except the plaintext and the key, and has more resources and cleverness
than you do. Limiting yourself to improvements that still improve
your security under this standard seemms wiser than adding improvements
that require secrets algorithms, chaining methods, etc (unless the
algorithm, etc is selected by a part of the key not used elsewhere).
------------------------------
From: Arthur Dardia <[EMAIL PROTECTED]>
Subject: Re: MD5 Expansion
Date: Tue, 20 Jun 2000 11:02:42 -0400
Mark Wooding wrote:
> Arthur Dardia <[EMAIL PROTECTED]> wrote:
>
> > A=MD5(M);
> > B=SHA-1(MD5(M));
> > C=TIGER/192(SHA-1(MD5(M)));
> >
> > C would be the final output.
> >
> > How does this increase security, by what percentage, if it does at all?
>
> Not at all. Utterly hopeless.
>
> Find M, M' such that MD5(M) = MD5(M'). This is at most 2^{64} effort;
> maybe less if MD5 gets any more broken than it is already. From there,
> you get identical C outputs.
>
> -- [mdw]
You wouldn't know MD5(M), because you'd only distribute the output of C. So
without MD5(M), how would you know when you hit MD5(M'). No way to check if
they're equal.
--
Arthur Dardia Rensselaer Polytechnic Institute [EMAIL PROTECTED]
PGP 6.5.1 Public Key http://www.webspan.net/~ahdiii/ahdiii.asc
------------------------------
From: Bruce Schneier <[EMAIL PROTECTED]>
Subject: Twofish book
Date: Tue, 20 Jun 2000 10:07:15 -0500
I know nothing of the seller or the auction, but if someone wants a
copy of the Twofish book cheap:
http://cgi.ebay.com/aw-cgi/eBayISAPI.dll?ViewItem&item=359964167
Bruce
**********************************************************************
Bruce Schneier, Counterpane Internet Security, Inc. Phone: 612-823-1098
101 E Minnehaha Parkway, Minneapolis, MN 55419 Fax: 612-823-1590
Free crypto newsletter. See: http://www.counterpane.com
------------------------------
From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: MD5 Expansion
Date: 20 Jun 2000 15:13:26 GMT
Arthur Dardia <[EMAIL PROTECTED]> wrote:
> You wouldn't know MD5(M), because you'd only distribute the output of
> C. So without MD5(M), how would you know when you hit MD5(M'). No
> way to check if they're equal.
There's nothing to stop an adversary from computing MD5 himself. It's
not keyed or anything.
-- [mdw]
------------------------------
From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: MD5 Expansion
Date: 20 Jun 2000 15:19:26 GMT
Mark Wooding <[EMAIL PROTECTED]> wrote:
> Arthur Dardia <[EMAIL PROTECTED]> wrote:
>
> > You wouldn't know MD5(M), because you'd only distribute the output of
> > C. So without MD5(M), how would you know when you hit MD5(M'). No
> > way to check if they're equal.
>
> There's nothing to stop an adversary from computing MD5 himself. It's
> not keyed or anything.
Hmm. Actually, this will only speed things up a constant factor. You
still only need to try 2^{64} preimages before you see a collision in C,
even if you compute the entire function each time.
-- [mdw]
------------------------------
Date: Tue, 20 Jun 2000 05:06:27 +0100
From: David Hopwood <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: MD5 Expansion
=====BEGIN PGP SIGNED MESSAGE=====
tomstd wrote:
> Arthur Dardia <[EMAIL PROTECTED]> wrote:
> >Instead of doing what the original poster came up with. Why
> >can't you just hash the original message with MD5. Use the
> >output as the input to another hash algorithm (say SHA-1), and
> >then to be safe repeat the same thing replacing TIGER/192 for
> >SHA-1.
> >
> >A=MD5(M);
> >B=SHA-1(MD5(M));
> >C=TIGER/192(SHA-1(MD5(M)));
> >
> >C would be the final output.
> >
> >How does this increase security, by what percentage, if it does
> at all?
>
> Let's see the collection of A,B,C forms the new hash output and
> it's 480 bits in length. By the b-day paradox we should find a
> collsion after about 2^240 attempts... that's pretty good.
>
> However, I can find a collision in A with 2^64 work, and a
> collision in SHA with 2^80 work, that's about 2^80 work total
> since after 2^80 trials we are bound to see quite abit of MD5
> collisions.
>
> Again after 2^96 trials to break Tiger we should see quite a bit
> of SHA collisions. So with about 2^96 hash operations we
> should see collisions in all three. That's hardly 2^240.
No, look at the proposal more carefully. A collision for MD5(M) is
automatically a collision for SHA-1(MD5(M)) and Tiger/192(SHA-1(MD5(M)),
so finding such a collision requires on the order of 2^64 attempts, not
2^96.
- --
David Hopwood <[EMAIL PROTECTED]>
PGP public key: http://www.users.zetnet.co.uk/hopwood/public.asc
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01
=====BEGIN PGP SIGNATURE=====
Version: 2.6.3i
Charset: noconv
iQEVAwUBOU7tnzkCAxeYt5gVAQF/vQf/Z80n7IMWpdoxBak1X5UTsGNLekgDiQlD
fQCDG5uXV9N2ENzzJSIIbjSplqj+Heq7p/wPH5ANoUknpSgs7KMrDR0bomMwHRcY
o23XKpj1bK78xtdpOGi1IePSo0zkLDnR+ZPPaMyOuLC5JMrMwShX84gPyzEBYpzu
IvDaNqvVuvtB3grFCN3d33Jzt8Bf26i8RvnRx4BZkGGeRBQHt+uoRYDBL8jB4Dcy
looHQiHgYHoAn2H/FdfVhEVALSGJ/DoD/BzULn+tz/+dIPHDfHJ7DlME5Ob3p4QB
o6lUza/pZllD9s/mBE1KIs1iUiweBHGlxcvWR1s7ddDTj7JzjIFeuw==
=qK0Q
=====END PGP SIGNATURE=====
------------------------------
From: zapzing <[EMAIL PROTECTED]>
Crossposted-To: sci.math
Subject: Re: Cryptographic voting
Date: Tue, 20 Jun 2000 15:48:43 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> In sci.crypt zapzing <[EMAIL PROTECTED]> wrote:
> > In article <[EMAIL PROTECTED]>,
> > [EMAIL PROTECTED] wrote:
> >> Back to crypto voting, I'm going to point out something that is a
> > slight
> >> variation of what has been discussed.
> >>
> >> When you register to vote, which, at least in Florida you must do
> >> in person, you could be issued a key pair. They would fill out
> >> the registration card on paper. You would then go over to a
computer
> >> and get your random key pair, the public key key would be
registered
> >> by the computer as "in use" but your name would not be attached,
> > although
> >> a "registered to voter 193687" could be also issued, with the
193687
> >> just being a number that has no links to a specific individual.
>
> > The real problem would probably be that there would be
> > nothing stopping someone from registering in one place,
> > then going somewhere else and registering there.
>
> The fact that their name was checked off doesn't show an extra vote.
Well if you are going to have a name check
off system you are going to have to deal with the
issues of how do you compile the list initially
and how do you identify people when they are
registering so that they don't register as their
neighbor whom they know sleeps late, and then
go somewhere else and register as themselves.
> Of course, this brings up the question of what happens when I lose
> my key? Oh well, back to the drawing board. :)
Such people simlply do not deserve to vote!
--
If you know about a retail source of
inexpensive DES chips, please let
me know, thanks.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "Tony T. Warnock" <[EMAIL PROTECTED]>
Subject: Re: small subgroups in Blum Blum Shub
Date: Tue, 20 Jun 2000 10:07:42 -0600
Reply-To: [EMAIL PROTECTED]
I think people are missing the point here. It's not that RSA, etc. are
not secure but that the BBS generator using all the BBS bells and
whistles can be proven secure.
------------------------------
** 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
******************************
