Cryptography-Digest Digest #784, Volume #10 Wed, 22 Dec 99 19:13:00 EST
Contents:
Re: ElGamal Opinions, Please (Daniel Bleichenbacher)
Re: DES key safety (David Wagner)
Re: MARS (Ken Lamquist)
Re: How do you know if you found a key? (David A Molnar)
Re: NSA and TRUTH (Johnny Bravo)
"Variable size" hash algorithm? (Dan Day)
Re: NSA and TRUTH (Arthur Dardia)
Re: Of one time pads, plaintext attacks, and fantasy ([EMAIL PROTECTED])
Thanks for the recommend! ([EMAIL PROTECTED])
Re: More idiot "security problems" (Dan Day)
Re: "Variable size" hash algorithm? ("Gary")
Re: Of one time pads, plaintext attacks, and fantasy ([EMAIL PROTECTED])
Re: How do you know if you found a key? ("Gary")
Re: More idiot "security problems" (Dan Day)
Re: Of one time pads, plaintext attacks, and fantasy ([EMAIL PROTECTED])
Re: How do you know if you found a key? ("Gary")
Re: How do you know if you found a key? ("Gary")
[OT] Keystrokes monitored/encryption useless (Liyang Hu)
Re: Keystrokes monitored/encryption useless (Liyang Hu)
Re: "Variable size" hash algorithm? (Pelle Evensen)
Re: More idiot "security problems" (Dan Day)
Question about SSL and Java (Greg)
Re: Of one time pads, plaintext attacks, and fantasy (John Savard)
Re: "Variable size" hash algorithm? (John Myre)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Daniel Bleichenbacher)
Subject: Re: ElGamal Opinions, Please
Date: 22 Dec 1999 15:12:38 -0500
[EMAIL PROTECTED] wrote:
> With ElGamal encryption, we have a prime modulus p, and the generator of
> some group g. Let us call q the size of the group generated by g.
>
> Which is better:
>
> A. q = p-1?
> B. q = (p-1)/2, and q is prime?
> C. q is substantially less than p, perhaps 256 bits, and is prime?
>
> In case (A), g generates the entire group of order p-1. However the
> problem is that this will leak the low order bit of people's private keys
> x, by whether y = g^x is a quadratic residue. Furthermore the product
> y^k * M may leak info on whether M is a quadratic residue.
>
> In case (B), g generates the subgroup of all quadratic residues. It no
> longer leaks the low bit of x, however y^k * M will still reveal whether
> M is a quadratic residue.
This can be prevented with a simple old trick.
Choose 1 < M < (p-1)/2
Compute M' = (M|p) * M, (where (|) denotes the Jacobi symbol)
Encrypt M'*y^k.
Then the encryption is semantically secure.
> In case (C), g generates a small subgroup, still large enough to thwart
> discrete log attacks. x and k values will be small and so the arithmetic
> is somewhat faster. However M is probably not in the subgroup and,
> depending on the factorization of (p-1)/q, this could leak a lot of
> information about M.
>
> The leaks about M can be reduced if it is randomized using something like
> Optimal Asymmetric Encryption Padding (or plain old PKCS-1). Normally
> OAEP is used for RSA in order to prevent message-guessing attacks and
> to make sure that there is wrap-around in the exponentiation, neither
> of which is a consideration for ElGamal.
Using OAEP is definitively better than PKCS-1 v.1.5 to prevent chosen-cipher
text attacks. Note that an attacker can take any ElGamal ciphertext
(g^k, M*y^k) and compute (g^k, (c*M)*y^k) without knowing M.
Hence, this is multiplicative property similar to the one in RSA,
and the same method can be used to attack ElGamal with a chosen-ciphertext
attack as can be used to attack RSA.
> However it may be helpful in
> the case of ElGamal in order to prevent information leakage about M.
> Knowing that M is a quadratic residue, or knowing even more information
> based on using a small subgroup, will not provide information about the
> message payload if M is substantially random.
>
> Comments?
I'd strongly recommend to use the IEEE P1363 standard.
(http://grouper.ieee.org/groups/1363/).
Be very careful with RFC 2440 used in GnuPG, since this "standard"
uses old PKCS-1 v.1.5 padding. The security of the ElGamal encryption
there depends on a correct decryption of subsequent message packets.
This is not a very modular approach and using RFC 2440 for anything
other than openpgp might introduce weaknesses.
Daniel Bleichenbacher
Bell Labs
--
Daniel Bleichenbacher
Bell Laboratories
600 Mountain Av.
Murray Hill, NJ 07974
------------------------------
From: [EMAIL PROTECTED] (David Wagner)
Subject: Re: DES key safety
Date: 22 Dec 1999 12:28:22 -0800
In article <83qav7$ped$[EMAIL PROTECTED]>,
Markku-Juhani O. Saarinen <[EMAIL PROTECTED]> wrote:
> I hope that I'm understanding this correctly.. but doesn't it suffice just
> to find collisions in DES ?
>
> Fix the plaintext block and take the new key from previous ciphertext
> (minus the parity bits). Collision search is O(2^(n/2)) and thus the
> overall complexity is around 2^8 * 2^28 = 2^36.
Good point.
I am embarassed that I overlooked this technique.
And it can be done efficiently using van Oorschot and Wiener's
techniques for parallel collision search. Their technique mostly
eliminates the onerous space requirements, and also allows one to
parallelize the attack. I've used their algorithm for a similar
purpose (finding a collision in crypt(3)), and it worked nicely.
------------------------------
From: [EMAIL PROTECTED] (Ken Lamquist)
Subject: Re: MARS
Date: 22 Dec 1999 20:40:07 GMT
Volker Hetzer <[EMAIL PROTECTED]> wrote:
> "William W. Joslin" wrote:
>> Can anyone tell me more about MARS algorithm... I know that it is a
>> finalist as an AES, but, tell me more about it...
> You mean, something that isn't covered in the spec?
> Well, personally I believe (in my VERY humble opinion) that it's the
> most likely winner. Mainly for political reasons. However that is
> pure speculation.
My speculation is that it is one of the less likely winners. RC6,
Rijindael, and Twofish appear to be a bit faster than MARS on general
purpose computers which have good support for integer multiplication
and 32 bit rotates. The performance relative performance of MARS
suffers on machines where these operations are slow. The modified
key schedule decreases the RAM requirements for implementations on low
end smart cards, but the algorithm still requires relatively large ROM
tables.
The NSA was originally scheduled to release its analysis of hardware
implementations six months after the start of round two. Does anyone
know if that is still the schedule? My expectation is that MARS is
not particularly well suited to hardware implementation. It uses
multiplication, and fast multiplication takes a lot of silicon. It
has four different types of rounds, which operate at three different
speeds, making pipelined implementations awkward.
All of the AES finalists are secure as far a we know, but NIST notes
that the complexity of MARS "makes analysis difficult in a restricted
timeframe." Thus if no security flaws are found in any of the candidates
during round two, MARS is likely to be considered to be slightly less
trusted than the other candidates. (Complexity is also an issue for
Twofish, but less so than for MARS.)
MARS offers considerable flexibility in the choice of key lengths,
which is nice but not likely to be a major factor in the competition.
I'm not sure about the politics. IBM is a valuable brand name, but
the submitters of the other finalists are at least as well known among
people who use cryptography. Three of the finalists have been placed
in the public domain, meaning that people are considering using them
in applications now.
My speculation is that the most likely winners are Twofish, Rijindael,
and RC6, in that order. If only one winner is selected, I don't think
it will be Serpent because Serpent is slow on general purpose computers.
NIST might select Serpent as a second winner due to its suitability for
hardware implementation.
Kenneth Almquist
------------------------------
From: David A Molnar <[EMAIL PROTECTED]>
Subject: Re: How do you know if you found a key?
Date: 22 Dec 1999 20:52:29 GMT
Greg <[EMAIL PROTECTED]> wrote:
> I guess this is the part that stumps me. Why would it make a
> significant difference? But if the article explains it, then
> I would just need to know where I can get a copy of that article.
Check Biham's web page : http://www.cs.technion.ac.il/~biham
and he should have a copy up. Oh, here it is :
http://www.cs.technion.ac.il/users/wwwb/cgi-bin/tr-get.cgi/1996/CS/CS0885.ps
The rest of his page is worth looking at too.
Thanks,
-David
------------------------------
From: [EMAIL PROTECTED] (Johnny Bravo)
Subject: Re: NSA and TRUTH
Date: Wed, 22 Dec 1999 16:51:12 GMT
On Wed, 22 Dec 1999 16:21:22 GMT, [EMAIL PROTECTED]
(SCOTT19U.ZIP_GUY) wrote:
>Below is a pointer to something most will enjoy.
Nice link, thanks.
>It also has a fine quote direct from our PRESIDENT.
LOL - "The road to tyranny, we must never forget, begins with the
destruction of the truth."
I guess it depends on what Clinton's definition of "truth" is. :)
Best Wishes,
Johnny Bravo
------------------------------
From: [EMAIL PROTECTED] (Dan Day)
Subject: "Variable size" hash algorithm?
Date: Wed, 22 Dec 1999 22:26:45 GMT
I'm still new to a lot of this, so bear with me if
there's a simple, well-known answer to this question.
I'm looking for a hash algorithm that can easily be
"set" to produce hash values of practically any size.
For example, given M bits of input, I'd like to have
a "general" hash algorithm that can be used to
produce any desired number of bits of output (or at
least up to M bits of output).
Basically, I'm looking for a good "stirring" algorithm,
which can take M bits of input and "stir, shuffle, and reduce"
them to a pseudo-random "N" bits of output, where "N" is
not fixed.
The idea is that it could be used to:
1) Reduce a passphrase of a given size down to
"X" bits, where "X" is no greater than the
number of bits of entropy in the original
passphrase. The X-bit output could then be used
as an X-bit key for encryption, with the confidence
that none of the algorithm's keysize is being "wasted"
with redundant information.
2) Reduce a large volume of data to a smaller (but
still large) volume of "random" data (again, no
larger than the amount of entropy in the original
"seed" data), to be used as a one-time-pad.
3) "Stir" a batch of random bits, to further randomize
it and/or obscure the source material.
Is there such an animal? Or do most cryptographically
useful hash algorithms generally produce a fixed-size output,
without an option to specify the desired output hash size?
--
"How strangely will the Tools of a Tyrant pervert the
plain Meaning of Words!"
--Samuel Adams (1722-1803), letter to John Pitts, January 21, 1776
------------------------------
From: Arthur Dardia <[EMAIL PROTECTED]>
Subject: Re: NSA and TRUTH
Date: Wed, 22 Dec 1999 17:30:59 -0500
I hope the NSA is fun. I hope to intern there throughout college with
their co-op program. Should be fun.
Johnny Bravo wrote:
> On Wed, 22 Dec 1999 16:21:22 GMT, [EMAIL PROTECTED]
> (SCOTT19U.ZIP_GUY) wrote:
>
> >Below is a pointer to something most will enjoy.
>
> Nice link, thanks.
>
> >It also has a fine quote direct from our PRESIDENT.
>
> LOL - "The road to tyranny, we must never forget, begins with the
> destruction of the truth."
>
> I guess it depends on what Clinton's definition of "truth" is. :)
>
> Best Wishes,
> Johnny Bravo
--
Arthur Dardia Wayne Hills High School [EMAIL PROTECTED]
PGP 6.5.1 Public Key http://www.webspan.net/~ahdiii/ahdiii.asc
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Of one time pads, plaintext attacks, and fantasy
Date: Wed, 22 Dec 1999 22:40:47 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> >Am I missing something here? Or was this just one of those convient
> >flights of fancy that make for a good story...if not a technically
> >accurate one?
> >
> That's not a one time pad, it's a pseudo one time pad.
> pseudo random does not equal random. Or as I like to say,
> pseudo one time pads offer pseudo security.
>
> The Riemann-zeta function is a chaotic function.
> Crypto systems based on chaotic functions have
> historically been broken very quickly.
> They generally don't make good random generators
> for non-crypto applications either.
I see what you mean, but I somehow doubt that particular flaw in the RZ
function is what the author was getting at.
>
> >=====
> >PS: As I was typing this message, an idea come to me that I suppose
> >might work.....
xxxxx
> >if not then...
> >4) step forward one character in ciphetext and start over.
> >
> >Sounds REALLY tedious!!
> >
> Well, yes, but tedious is something computers do really well.
> If you only have try 72,057,594,037,927,936 times, then it's
> essential broken given modern technology.
Yeah, but this was supposed to be happening in the waning days of WW II
(though the guy did say he was using a computer he threw together
himself made out of vaccuum tubes).
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED]
Subject: Thanks for the recommend!
Date: Wed, 22 Dec 1999 22:36:26 GMT
In article <83pbtr$k4g$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Paul Rubin) wrote:
> In article <83p7al$kut$[EMAIL PROTECTED]>, <[EMAIL PROTECTED]> wrote:
> >Towards the end of "Cryptonomicon" by Stephenson (interesting
> >novel by the way, anybody know of any others that use crypto as a
plot
> >device??)
>
> There are quite a few. "The Key To Rebecca" (about cryptanalyzing
> a book code to catch a spy) by Ken Follett is a fairly good one.
>
Thanks for the recommendation. Quite a few? How do you find them? I know
there are plenty of "spy" novels and "espionage thrillers", but of the
ones I've read, few really circle around crypto as a major plot device.
Again, thanks!
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (Dan Day)
Subject: Re: More idiot "security problems"
Date: Wed, 22 Dec 1999 22:52:21 GMT
On 17 Dec 1999 19:24:47 GMT, [EMAIL PROTECTED] (Xcott Craver) wrote:
> Well-spotted! Now, can we think of a character who embodies
> all four properties? I've always wanted a good term for
> coders who reinvent square wheels. How about ... well, I've
> exhausted most of today's creative juices. There's got to
> be a million sitcoms where someone gets instant-expert syndrome
> about something he doesn't understand and accidentally creates
> a plotline. Who does that a lot?
Lucy Ricardo? (That's Lucille Ball in "I Love Lucy")
Gilligan?
--
"How strangely will the Tools of a Tyrant pervert the
plain Meaning of Words!"
--Samuel Adams (1722-1803), letter to John Pitts, January 21, 1776
------------------------------
From: "Gary" <[EMAIL PROTECTED]>
Subject: Re: "Variable size" hash algorithm?
Date: Wed, 22 Dec 1999 22:55:42 -0000
If a hash is longer than the output reqd one usually XOR's down to the reqd
bits.
Alternatively you can use a standard cryptographic algorithm such as XTEA
block as a hash function by using the data to be hashed as a key (iterating
for long keys) on a constant value set to the number of 64 bit blocks you
want. (XTEA block is relatively unusual in that it treats all fo the data to
be encrypted as a block).
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Of one time pads, plaintext attacks, and fantasy
Date: Wed, 22 Dec 1999 22:52:47 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Steve K) wrote:
> On Wed, 22 Dec 1999 00:51:35 GMT, [EMAIL PROTECTED] wrote:
>
> >Here's my confusion:
> >Given that it is a random sequence of additives, how could you tell
if a
> >given sequence of ciphertext tranlated back to a given plaintext?
xxxxxxxx
>
> The trick to analyzing such a cipher, is to subtract the known
> plaintext from the ciphertext, and examine the key stream, to try and
> figure out how it was generated.
My point is "how does one *know* a segment of ciphertext matchs a piece
of suspected plaintext?"
Example:
If the ciphertext is
02 03 04 05 06 07
and the suspected plaintext is
AAAA
If you match the first 4 characters, the key stream is 01 02 03 04
(assume A = 01)
On the other hand, if you match it to the next 4 characters, the key
stream is 02 03 04 05. And so on....
And since the key stream is random (or even pseudo-random), its not like
you can just try applying 01 02 03 04 or 02 03 04 05 to other portions
of the ciphertext to see if any meaningful plaintext appears. So, you
don't know which one is "right".
Which led me to the bit of insight I enclosed at the end of my original
post (exhaustively trying ALL combinations and then working backwards to
determine the seed to the function generating the key stream. Which
only works *IF* you know what function to try.)
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "Gary" <[EMAIL PROTECTED]>
Subject: Re: How do you know if you found a key?
Date: Wed, 22 Dec 1999 22:58:23 -0000
Wrong!
Testing all possible of keys will reveal all chargeable credit card numbers.
(Please not credit card header should be removed as well)
------------------------------
From: [EMAIL PROTECTED] (Dan Day)
Subject: Re: More idiot "security problems"
Date: Wed, 22 Dec 1999 23:05:42 GMT
On 19 Dec 1999 00:18:36 GMT, [EMAIL PROTECTED] (Xcott Craver) wrote:
>
> Now, if the program is capable of decrypting the data too,
> then you have a problem.
But I believe that that's the case under discussion here. Eric
was talking about copy-protection schemes, wherein a program keeps
part of itself encrypted or otherwise "locked", but the program
itself knows how to "unlock" itself when it thinks it's running
on an authorized machine.
By definition, it seems to me, such a program "is capable of
decrypting the data" that it needs.
Eric's point is that such a system can always be broken just
by "looking over its shoulder" as it does its dirty work on itself.
--
"How strangely will the Tools of a Tyrant pervert the
plain Meaning of Words!"
--Samuel Adams (1722-1803), letter to John Pitts, January 21, 1776
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Of one time pads, plaintext attacks, and fantasy
Date: Wed, 22 Dec 1999 22:55:22 GMT
In article <83q804$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Guy Macon) wrote:
>
> I see the problem. You don't understand the term "one-time pad".
> If the "random" component is pseudo-random, it isn't a one-time pad.
>
>
How does that substantially alter the problem? (Please see previous
response)
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "Gary" <[EMAIL PROTECTED]>
Subject: Re: How do you know if you found a key?
Date: Wed, 22 Dec 1999 23:09:30 -0000
Ok this would be an attack on the repetiton of XOR but the credit card
company would send a cop to you to help you out with all those tries :).
------------------------------
From: "Gary" <[EMAIL PROTECTED]>
Subject: Re: How do you know if you found a key?
Date: Wed, 22 Dec 1999 23:14:34 -0000
Yep that is a valid attack on the repetitive nature of the XOR.
(Credit card Co's sometimes allow bulk validity checks)
I also forgot to state that the credit card header first few digits should
be removed.
------------------------------
From: Liyang Hu <[EMAIL PROTECTED]>
Subject: [OT] Keystrokes monitored/encryption useless
Date: Wed, 22 Dec 1999 20:51:23 -0000
At 22 Dec 1999 05:05:01 EST, in sci.crypt, Guy Macon
<[EMAIL PROTECTED]> said:
> Liyang Hu wrote:
>
> >Frankly, I'm sick of projects involving PIC's, or any other
> >microcontroller for that matter. Every issue of every damn electronics
> >magazine now has at *least* one project involving one of those. I wish for
> >the old days when electronics required years of experience to get to grips
> >with, and when you could see from the circuit diagram how a certain
> >project worked. Now it's all just programming.
>
> I would suggest that you stop reading sci.crypt and find a newsgroup
> more to you liking. While this newsgroup does touch on nonprogrammable
> electronics, such discussions are usually limited to talking about
> noise sources for creating "random" numbers. The bulk of the posts
> (and the topic of the newsgroup) are about various programmable systems.
> These are mostly personal computers, but doing crypto on a microcontroller,
> mainframe, steam powerd computer (anti-tempest!), etc. would also be
> on topic.
I'm just annoyed at the fact that so called electronics projects involve
waaayy too much programming. I program as well, and have written quite a
lot of stuff, but when I want to do electronics (ie, for fun, not because
I want to do it as a career), I like to do 'real' electronics.
> >Anyway, I doubt I'd learn anything new from this.
>
> Your choice. There is always something to be learned.
True enough, but the project I mentioned woundnt really be a challenge,
and hence, no fun (see below)
> >Apart from that, I dont have much spare time now for electronics anyway,
> >especially seeing as I'm not taking Technology for my A-Levels. Although I
> >have to agree with you - it would have been fun, if I had built it :)
>
> Ah. I see the problem. You are in the mode where your learning is
> constrained to that which gets you grades. A reasonable position for
> one who is in school. Alas, in too many cases the attitude remains
> after graduation, and we see engineers who fail to make the transition
> to transistors, ICs, digital logic, Op amps, microcontrollers, hardware
> description languages, etc. etc. More $$$$ for those of us who keep
> learning new things all of our lives, I suppose.
Umm... I'm taking mathematics at uni. I dont really care about being an
engineer or whatever - I do this (ie, electronics and programming) for
fun, and I'd like to keep it that way for myself.
Anyway, this discussion better stop soon as it's getting way too OT.
--
¸¸,ø¤º°`Liyang Hu/DenseBoy°º¤ø,¸¸,ø¤º°http://www.nerv.cx/`°º¤ø,¸¸
| The subspace W inherits the other 8 properties of V. |
| And there aren't even any property taxes. |
| -- J. MacKay, Mathematics 134b |
------------------------------
From: Liyang Hu <[EMAIL PROTECTED]>
Subject: Re: Keystrokes monitored/encryption useless
Date: Wed, 22 Dec 1999 20:53:44 -0000
At Wed, 22 Dec 1999 11:11:54 -0700, in sci.crypt, John Myre
<[EMAIL PROTECTED]> said:
> Anyway, I don't think we need take Liyang Hu's post as anything more
> than "been there, done that - right now I'm spending my time on other
> stuff".
Well said. Couldn't have summarised it better myself. Thank you :)
Now, lets get back to cryptography...
--
¸¸,ø¤º°`Liyang Hu/DenseBoy°º¤ø,¸¸,ø¤º°http://www.nerv.cx/`°º¤ø,¸¸
| The subspace W inherits the other 8 properties of V. |
| And there aren't even any property taxes. |
| -- J. MacKay, Mathematics 134b |
------------------------------
From: Pelle Evensen <[EMAIL PROTECTED]>
Subject: Re: "Variable size" hash algorithm?
Date: Thu, 23 Dec 1999 00:32:55 +0100
Dan Day wrote:
[snip]
> 2) Reduce a large volume of data to a smaller (but
> still large) volume of "random" data (again, no
> larger than the amount of entropy in the original
> "seed" data), to be used as a one-time-pad.
Why would you want a "large" volume of data as hash? With an algorithm
producing a 160 bit hash it's 50% that you'll get a collision after 2^80
(~2 * 10^24) messages. This is an awful lot. :-)
If that sounds bad, try Tiger or some other algorithm producing a longer,
but not arbitrarily sized, hash.
> 3) "Stir" a batch of random bits, to further randomize
> it and/or obscure the source material.
You can do this with a function with a "short" blocklength, 128 bits.
Keep a pool, keep it separate from the output of the function.
See
http://www.counterpane.com/yarrow-notes.html
http://www.counterpane.com/pseudorandom_number.html
> Is there such an animal? Or do most cryptographically
> useful hash algorithms generally produce a fixed-size output,
> without an option to specify the desired output hash size?
Any "pure" one-way functions I know of produce a "fixed size" output, in the
sense "up to n bits of data", where n is well defined. You *can* of course
combine outputs from one or several functions, chain or mix as much as you
like and thereby end up with a hash of arbitrary length, the question is if
you or anyone else will know what the actual strength of what you've
created is.
/Pell
------------------------------
From: [EMAIL PROTECTED] (Dan Day)
Subject: Re: More idiot "security problems"
Date: Wed, 22 Dec 1999 23:41:12 GMT
On Thu, 16 Dec 1999 20:12:38 -0500, "Trevor Jackson, III" <[EMAIL PROTECTED]>
wrote:
>This problem is rampant, esp with sort(). About a dozen years ago someone, a
>magazine I think, ran a contest for the worst fielded sort routine. Last I heard
>the winner was an O(N^6) algorithm.
Good GOD!
Do you recall what the bone-headed algorithm was? Most "first try" sort
algorithms are O(N^2). A few common "seemed like a good idea at the time"
algorithms are O(N^3). But what on EARTH would generate a O(N^6) runtime??
I literally don't think I could write a sort algorithm that bad if I tried to.
--
"How strangely will the Tools of a Tyrant pervert the
plain Meaning of Words!"
--Samuel Adams (1722-1803), letter to John Pitts, January 21, 1776
------------------------------
From: Greg <[EMAIL PROTECTED]>
Subject: Question about SSL and Java
Date: Wed, 22 Dec 1999 23:42:11 GMT
I am trying to learn about SSL and how it works with Java
scripts on a web server. Please tell me if I am incorrect
with the following assumptions:
The SSL code runs as a layer above the socket software and
runs more like a driver than anything else.
The Java script can manipulate the SSL, but SSL itself is
not written in Java (usually).
This last fact has no impact on the OS platform that Java
runs on.
Is this correct? If not, please help!
--
The only vote that you waste is the one you never wanted to make.
RICO- we were told it was a necessary surrender of our civil liberties.
Asset Forfeiture- the latest inevitable result of RICO.
http://www.ciphermax.com/book
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Of one time pads, plaintext attacks, and fantasy
Date: Wed, 22 Dec 1999 16:49:10 GMT
[EMAIL PROTECTED] wrote, in part:
>My point is "how does one *know* a segment of ciphertext matchs a piece
>of suspected plaintext?"
>Which led me to the bit of insight I enclosed at the end of my original
>post (exhaustively trying ALL combinations and then working backwards to
>determine the seed to the function generating the key stream. Which
>only works *IF* you know what function to try.)
Of course trying to break a cipher is very difficult! But that's not
the same thing as impossible. If the message is short, and the
algorithm unknown, and the probable words not that certain, of course
it's quite possible a solution won't be obtained.
John Savard (jsavard<at>ecn<dot>ab<dot>ca)
http://www.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: John Myre <[EMAIL PROTECTED]>
Subject: Re: "Variable size" hash algorithm?
Date: Wed, 22 Dec 1999 16:52:27 -0700
If a hash algorithm produces "too many" output bits, of
course one can simply discard the extra.
If you want more output, you need additional tools, and
cryptographic analysis of the construction is recommended.
I've seen various ways to do it. Check out Yarrow at
www.counterpane.com for some interesting ideas. Their
basic method is to use the hash output to key a block
encryption algorithm, and use the output of encryption
in OFB mode for as many bits as you need.
My personal favorite is Daemen and Clapp's Panama, which
could easily be used to produce additional output because
it is also designed to be used as a stream cipher. Of course,
taking extra bits out of Panama for a longer hash has no
warranty - it hasn't been cryptanalyzed.
Another common trick is to hash your original data twice
(or more), each time with a slightly different prefix,
or combined in other ways. I don't know how secure any
of that is.
John M.
------------------------------
** 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
******************************
