Cryptography-Digest Digest #455, Volume #13 Thu, 11 Jan 01 10:13:00 EST
Contents:
Re: rc4 in javascript bug ([EMAIL PROTECTED])
keeping secret keys secret (isaac william oates)
Re: RSA recoverable signature trick (Hans-Peter Baron)
Re: rc4 in javascript bug (Paul Rubin)
Re: keeping secret keys secret (Paul Rubin)
Re: Enigma Emulator for Palm Pilot? (Dave Holland)
Lotus Notes R4.6 http hash ("Sven Wolf")
Re: Enigma Emulator for Palm Pilot? (Steve Roberts)
Re: Stream cipher (Simon Johnson)
Re: Stream cipher (Simon Johnson)
Re: Twofish for dummies ([EMAIL PROTECTED])
Re: Stream cipher (Simon Johnson)
Re: keeping secret keys secret ("Frog2000")
Re: Can someone break this for me? ("Frog2000")
Re: Comparison of ECDLP vs. DLP (DJohn37050)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED]
Subject: Re: rc4 in javascript bug
Date: Thu, 11 Jan 2001 08:45:15 GMT
... so basically, although what's between the two body tags is text
only, highlighting/copying/encapsulating encrypted text in an html file
for decryption doesn't return a string of the same length because not
displayable characters are inserted ... but when I replaced the plain
text with the encrypted text in the html escapsulation, the length was
the same. I was thinking that maybe the ascii values returned by
javascript were not reliable but double encryption with nesting the
cipher returned what I expected, the plain text again.
Sent via Deja.com
http://www.deja.com/
------------------------------
From: isaac william oates <[EMAIL PROTECTED]>
Subject: keeping secret keys secret
Date: Thu, 11 Jan 2001 03:09:23 -0600
Ladies and gentlemen,
I'd like to create a web site for securely storing files and messages.
The dilema that I'm faced with is that I need to store the secret key on
the server and, unless there is a better way, secure that key with the
password. The process that I'm thinking about is this:
1) when a new area is created, a 3DES key (area key) is created.
2) for each user with access, the area key is encrypted with their
password.
3) when a user needs to add or retrieve information, I take their
password, decrypt the area key, and do what I need to.
So my problems are as follows:
(a) I need to authenticate the user first. Can I use MD5 or will that
make it too easy to crack someone's password? Once you've got someone's
password, it's all over.
(b) How long must the user's password be in order to keep the key safe?
(c) What's better, a 112- or 168-bit 3DES key?
(d) Is there a huge flaw here that I'm not seeing?
I don't have much practical experience with cryptography, which probably
doesn't make me the best person to write this software, but I'd like to
have a go at it anyway.
Thanks.
Isaac Oates
------------------------------
Date: Thu, 11 Jan 2001 10:23:37 +0100
From: Hans-Peter Baron <[EMAIL PROTECTED]>
Subject: Re: RSA recoverable signature trick
Mark Currie wrote:
>
> Thank you, I actually remember discovering this problem way back while
> questioning the need for the large padding string in the PKCS signature format.
> I definately will not use this method. However it may still be useful to find a
> neat way around the equal modulii thing in the case where you may want to
> encrypt a signature. Can you think of any problems associated with this
> variation ?
That depends on the signature. If the man-in-the attacker is able to
replace the public key used by the recipient to verify the signature,
you still have the same problem. It really depends on the exact details
of the protocol, and this seems to me to be a weakness.
In cryptography I would always stick with the standard methods. If you
try to invent something on your own, chances are it has some pitfalls.
And with cryptography, these pitfalls can be _very_ hard to spot, even
for "the clever guys".
That's why I think Jakob Jonsson's answer to your question was better
than mine, since he advises on using a more recent padding sceme and
cites the proper papers. The point I was trying to make was, that you
_really_ should use adequate padding for encryption with RSA.
Regards,
Hans-Peter
>
> Mark
>
> In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] says...
> >
> >Mark Currie wrote:
> >>
> >> Hi,
> >>
> >> Years ago someone told be about a trick that you can pull when you want to
> sign
> >> a public key of the same bit order. If you want to perform an RSA private
> key
> >> operation on another RSA public key modulus where both modulii have the same
> >> bit order you have a problem in that the to-be-signed value is one bit too
> >> large. The only methods that I can think of are:
> >>
> >> 1. Send 1024th bit in the clear or,
> >> 2. Clear the 1024th bit always and let the recipient perform at most two
> trial
> >> public key operations using the decrypted modulus.
> >>
> >> The first method is theoretically less secure and requires additional
> >> transmission space to send the troublesome bit with the encrypted modulus.
> The
> >> second method is a bit tedious for the recipient.
> >>
> >> Can anyone think of any other methods ?
> >>
> >> PS: Please don't recommend signing a hash of the public key, I specifically
> >> need a recoverable signature and I don't have too much additional
> transmission
> >> space.
> >
> >I think you shouldn't sign anything without padding. You compromise
> >your security otherwise. In your setup, a man-in-the-middle attack
> >seems to be easy, since the man-in-the-middle can replace your
> >original signature with something invented by him. Since he can
> >be assumed to have the recipients public key, he can decode his
> >invented signature to retrieve his modulus. Since there's no
> >padding, he needs just a few tries to invent a signature which
> >will look like a modulus after decryption.
> >
> >Since a RSA public key consists also of the exponent, and the
> >public exponent is usually something small, why not send two
> >signed packages _with_ padding (e.g. PKCS #1 OAEP), the first
> >containing one part of the modulus, the second package
> >containing the second part of the modulus and the exponent.
> >
> >Or, if you don't send the exponent because it is fixed, why
> >not fix some part of the modulus too and code it accordingly
> >before signing to reduce its size and have space for padding.
> >Or use the fixed part as padding. Fixing just a part of
> >the modulus can be done without compromizing security
> >too much, if the modulus size has some security in "reserve".
> >
> >>
> >> Thanks in advance
> >>
> >> Mark
> >
> >
> >--
> >Mit freundlichen Gr��en,
> >
> >Hans-Peter Baron
> >Senior Software Developer
> >FAKTUM Softwareentwicklung GmbH
> >www.faktum.com
> >Robert-Koch-Str. 50, D-55129 Mainz
> >Postanschrift: Postfach 100262, D-55133 Mainz
> >Tel: +49-6131-583700, Fax: +49-6131-583704
> >
> >******************************************************************************
> *******
> >Wenn diese E-Mail digital signiert ist, dient dies AUSSCHLIESSLICH folgenden
> Zwecken:
> >- Sicherstellen, da� diese E-Mail tats�chlich von mir stammt.
> >- Sicherstellen, da� der Inhalt der E-Mail nicht ver�ndert wurde.
> >Andere Zwecke und Interpretationen werden hiermit AUSDR�CKLICH ausgeschlossen.
> Zur
> >Zeit wird von mir Software zum digitalen Signieren und Verschl�sseln von
> E-Mail
> >entwickelt. Die verwendeten Schl�ssel dienen lediglich zum Testen. Da auch
> andere
> >Zugang zu diesen Schl�sseln haben, k�nnen o.g. Zwecke nicht sicher erf�llt
> werden.
> >******************************************************************************
> *******
------------------------------
From: Paul Rubin <[EMAIL PROTECTED]>
Subject: Re: rc4 in javascript bug
Date: 11 Jan 2001 01:28:20 -0800
[EMAIL PROTECTED] writes:
> ... so basically, although what's between the two body tags is text
> only, highlighting/copying/encapsulating encrypted text in an html file
> for decryption doesn't return a string of the same length because not
> displayable characters are inserted ... but when I replaced the plain
> text with the encrypted text in the html escapsulation, the length was
> the same. I was thinking that maybe the ascii values returned by
> javascript were not reliable but double encryption with nesting the
> cipher returned what I expected, the plain text again.
Yeah. You have to encode the rc4 output somehow, like as hexadecimal,
or URL encoding.
Btw, if you're planning to use that function to encode web pages with
more than a little bit of stuff on them, better do some timings.
You'll be pained to see how slow javascript in a browser is. There's
ways you can tune that code to run faster than the way it's written
now, but if you want decent performance you're going to have to write
an applet.
------------------------------
From: Paul Rubin <[EMAIL PROTECTED]>
Subject: Re: keeping secret keys secret
Date: 11 Jan 2001 01:36:38 -0800
isaac william oates <[EMAIL PROTECTED]> writes:
> I'd like to create a web site for securely storing files and messages.
> The dilema that I'm faced with is that I need to store the secret key on
> the server and, unless there is a better way, secure that key with the
> password. The process that I'm thinking about is this:
>
> 1) when a new area is created, a 3DES key (area key) is created.
> 2) for each user with access, the area key is encrypted with their
> password.
> 3) when a user needs to add or retrieve information, I take their
> password, decrypt the area key, and do what I need to.
> So my problems are as follows:
>
> (a) I need to authenticate the user first. Can I use MD5 or will that
> make it too easy to crack someone's password? Once you've got someone's
> password, it's all over.
Just append a checksum to the area key before encrypting it. If the
person doesn't have the right password, they won't be able to decrypt
the area key.
> (b) How long must the user's password be in order to keep the key safe?
The user's password must be not only long, but RANDOM. It has to have
enough entropy to provide the amount of security needed. Also, you have
to send it through an encrypted channel, but you knew that already.
See www.diceware.com for some info on entropy in passwords. I have a
page (www.nightsong.com/dice.html) that generates 5-word diceware-like
passphrases with about 60 bits of entropy automatically (just use two
of them for 120 bits).
> (c) What's better, a 112- or 168-bit 3DES key?
For what you're doing, it doesn't matter. The weaknesses created by
using passwords as keys overshadow any security difference in the 3DES
key length. But generally 168 bits is considered better.
> (d) Is there a huge flaw here that I'm not seeing?
If the user is sending you their password so you can get the area key,
it means you have access to the plaintext on the server, so why bother
encrypting it? If you're trying to keep the client's data secure
against the server getting compromised, then you must do the
cryptography on the CLIENT, not on the server.
------------------------------
From: Dave Holland <[EMAIL PROTECTED]>
Subject: Re: Enigma Emulator for Palm Pilot?
Date: 11 Jan 2001 10:05:22 +0000 (GMT)
In article <[EMAIL PROTECTED]>,
Rich W. <[EMAIL PROTECTED]> wrote:
> Does anyone know of an Enigma Emulator for the Palm Pilot?
Google search for "palm enigma", first result:
http://www.geocities.com/SiliconValley/Screen/1565/PEnigma.htm
It behaves slightly oddly on my Vx but I'm talking to the author about
why that might be.
Cheers,
Dave
------------------------------
From: "Sven Wolf" <[EMAIL PROTECTED]>
Subject: Lotus Notes R4.6 http hash
Date: Thu, 11 Jan 2001 12:27:21 +0100
Hi,
does anybody know, which algorithm is used to created the
http-password-hash? I thought it was md5, but it seems, that I'm wrong :(
Thanks, Sven
------------------------------
From: [EMAIL PROTECTED] (Steve Roberts)
Subject: Re: Enigma Emulator for Palm Pilot?
Date: Thu, 11 Jan 2001 13:12:27 GMT
Rich W. <[EMAIL PROTECTED]> wrote:
> Does anyone know of an Enigma Emulator for the Palm Pilot?
>
> Thanks,
>
>--
> Rich...
I have one, I have lost the URL from where I got it, but the author
is:
[EMAIL PROTECTED]
It works very nicely. Particularly amusing is the warning not to use
it for serious security!!
Steve Roberts
------------------------------
From: Simon Johnson <[EMAIL PROTECTED]>
Subject: Re: Stream cipher
Date: Thu, 11 Jan 2001 14:03:46 GMT
In article <93j57f$f8e$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (David Wagner) wrote:
> This is an xor of six Vigenere's, each with period about 2^16.
> Thus, with 6 * 2^16 bits of known plaintext, you can break it.
>
> You don't even need to know how each of the six generators work
> (you could replace them with any other scheme with similar period,
> and the attack would still work).
Yeah, i figured as much.... Do you break all the generators
simulatneously or do you kind of 'lock in', and break each generator
in succession until you have them all?
> As a warmup, you could try considering the case where you pick N bits
> at random and repeat them to get an infinite stream, then pick M bits
> at random and repeat them, then output their xor. This is a breakable
> with N+M bits of known plaintext. As an exercise, find the attack.
yeah, thanks. This should be a fun exercise, thanks :)
> If you have trouble, you can consult the following references:
> A. Sinkov, _Elementary Cryptanalysis: A Mathematical approach_.
> B. Tuckerman, ``A study of the Vigenere-Vernam single and multiple
> loop enciphering systems,'' IBM Research Report RC2879, 14 May
> 1970.
>
--
Hi, i'm the signuture virus,
help me spread by copying me into Signiture File
Sent via Deja.com
http://www.deja.com/
------------------------------
From: Simon Johnson <[EMAIL PROTECTED]>
Subject: Re: Stream cipher
Date: Thu, 11 Jan 2001 13:56:20 GMT
In article <[EMAIL PROTECTED]>,
"Paul Pires" <[EMAIL PROTECTED]> wrote:
>
> Simon Johnson <[EMAIL PROTECTED]> wrote in message
> news:93ir3d$ogb$[EMAIL PROTECTED]...
> > This is a low security cipher i have built for seeing how
cryptoanalyis
> > can be applied to stream ciphers. The intented use of this is to
keep
> > out the members of my family from a diary i keep. Rather than use
> > something else, i wanted to have some fun and built a cipher. I've
> > published it here, so you can completly destroy the toy :)
> >
> > This cipher is based on simple maths (some of the maths language
might
> > be off).
> >
> > Basically, i picked six primes close to 16-bits each: 65537, 65539
> > 65543, 65551, 65557, 65563.
> >
> > Now, this cipher is designed to take a 96-bit key. The key is
divided
> > into 16-bit portions. Working from the MSB to the LSB the first 16-
bits
> > are put into the varible, A, the second 16-bits into variable, B,
the
> > third 16-bits into the variable, C and so on..... from A -> F
> >
> > Once this is done, clock the cipher once, and we are ready to start.
> > To clock, do the following simple procedure:
> >
> > a = (a * 7) Mod 65537
> > b = (b * 3) Mod 65539
> > c = (c * 11) Mod 65543
> > d = (d * 13) Mod 65551
> > e = (e * 5) Mod 65557
> > f = (d * 17) Mod 65563
>
> Possible typo? f = (d? Not f= (f ?
Yup
>
> >
> > All the multipliers are meant to be primitive elements in their
> > respective fields. To return a single 'random' bit add the next
step:
> >
> > bit = (a xor b xor c xor d xor e xor f) AND 1
> >
> > Now since all the modulo's are relativly prime then the cycle
length of
> > this construction should be (2^96)-1 bits. But, i feel that this is
its
> > only nice property. It is almost certianly insecure... but i want to
> > see how you attack a stream cipher and this looks like a nice punch
> > bag :).
> >
> > Any offers on how to do it?
>
> First off do you realize that this re-defines the word "Slow"?
>
> It's not a stream cipher cause you don't say how you use the
> "random" bit to encrypt. I assume simple XOR.
>
> Second, right off the bat you have some real bad keys.
> I tried:
>
> a,b,c,d,e,f = 0 and the "random" bit is always zero.
> a,b,c,d,e,f = 65537,65539,65543,65551,65557,65563 Looks like all
ones.
> a,b,c,d,e,f = 1 and it looks about the same.
> a,b,c,d,e,f = 7,3,11,13,5,17 is equivalent to all ones but 1 cycle
shifted.
>
> These are the first four I tried. Maybe I'm unlucky.
>
> Unless I really miss-understood you, this argues against a
> minimum cycle of (2^96)-1.
>
> Doesn't appear to make a "random" stream or that it ciphers.
>
> Maybe I don't understand " All the multipliers are meant
> to be primitive elements in their respective fields."
>
> Did you try it? Run some output through Diehard or
> the human eye?
>
> Paul
>
> >
> > Simon.
> > --
> > Hi, i'm the signuture virus,
> > help me spread by copying me into Signiture File
> >
> >
> > Sent via Deja.com
> > http://www.deja.com/
>
> -----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
> http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
> -----== Over 80,000 Newsgroups - 16 Different Servers! =-----
>
--
Hi, i'm the signuture virus,
help me spread by copying me into Signiture File
Sent via Deja.com
http://www.deja.com/
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Twofish for dummies
Date: Thu, 11 Jan 2001 14:09:31 GMT
> > I am new to cryptography and only a decent C++ programmer.
> > I have read Mr. Schneiers book about the Twofish algorithm and
thought I
> > understood the key schedule (I haven't tried the encryption
algorithm
> yet),
> > so I implemented it. The problem is, that given the test vectors my
code
> > produces a wrong extended key. I tried reading the code by the
designers
> but
> > none of the code seemed familiar to me even after knowing the
design.
afaik, unless you get the galois field maths correct, there are quite a
few problems in implementation.
Mr. Brian Gladmans code at http://www.gladman.uk.net is also available.
regards,
rasane_s
Sent via Deja.com
http://www.deja.com/
------------------------------
From: Simon Johnson <[EMAIL PROTECTED]>
Subject: Re: Stream cipher
Date: Thu, 11 Jan 2001 14:06:15 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
>
> Simon Johnson wrote:
> > Now, this cipher is designed to take a 96-bit key. The key is
divided
> > into 16-bit portions. Working from the MSB to the LSB the first 16-
bits
> > are put into the varible, A, the second 16-bits into variable, B,
the
> > third 16-bits into the variable, C and so on..... from A -> F
> >
> > Once this is done, clock the cipher once, and we are ready to start.
> > To clock, do the following simple procedure:
> >
> > a = (a * 7) Mod 65537
> > b = (b * 3) Mod 65539
> > c = (c * 11) Mod 65543
> > d = (d * 13) Mod 65551
> > e = (e * 5) Mod 65557
> > f = (d * 17) Mod 65563
>
> Is that really supposed to be d * 17 in the last line, or is it f *
17?
> Assuming it is f (d would be even weaker), there is a trivial 2^48
> meet-in-the-middle attack, because the cipher is of the form
> h_K2(g_K1(plaintext)), with K1 and K2 of length only 48 bits.
> There are better attacks, I think, but there is not really much point
> in considering a cipher that falls to a simple meet-in-the-middle
attack
> any further.
Right, i shall try this attack too :)
The problem is i've built this too weak.... It breakable with simple
statsical analysis, which i should have seen anyway :)
Simon.
> - --
> David Hopwood <[EMAIL PROTECTED]>
>
> Home page & PGP public key: http://www.users.zetnet.co.uk/hopwood/
> RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66
15 01
> Nothing in this message is intended to be legally binding. If I
revoke a
> public key but refuse to specify why, it is because the private key
has been
> seized under the Regulation of Investigatory Powers Act; see
www.fipr.org/rip
>
> -----BEGIN PGP SIGNATURE-----
> Version: 2.6.3i
> Charset: noconv
>
> iQEVAwUBOl0zrzkCAxeYt5gVAQGTpAf+NphladNfSNn7I92gOBtkssu6AGvdjZbN
> 5m2/2kXlqbS/7bu81ZVE4Vei8Ul2517dsuEoRPTbSiDTNjG9VhSABgUeQAhXHf5b
> 4BeE8mrFpNGV19ad3Ygxz8vW0pC2oCvj+RAZpwCJW3nBrK3xI8nCz5yulpOHUhm/
> z9WULALz07GRBLr2i5OCIIDwYVTQdtKLqHujSkcgDiK3OgSqkC3jY6p5Zdclwg45
> iNKLQAYoh7k47RD0wAAedB+JnQIO5fgO9u7yGip2fA7SmZD3wHZZlwJ9bIvo0ZyL
> U0B52rOIqHfo18EkBDPZrctqCJkIpG8YzyjEbwaeltvnaoyAld5aLQ==
> =9qVy
> -----END PGP SIGNATURE-----
>
--
Hi, i'm the signuture virus,
help me spread by copying me into Signiture File
Sent via Deja.com
http://www.deja.com/
------------------------------
From: "Frog2000" <[EMAIL PROTECTED]>
Subject: Re: keeping secret keys secret
Date: Thu, 11 Jan 2001 09:29:03 -0500
The standard practice would be to store the keys off the server. Of course,
a good secure encryption system won't hurt, but you run a higher risk
storing the keys on the same server that the ":public" can get at.
--
http://welcome.to/speechsystemsfortheblind
"isaac william oates" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Ladies and gentlemen,
>
> I'd like to create a web site for securely storing files and messages.
> The dilema that I'm faced with is that I need to store the secret key on
> the server and, unless there is a better way, secure that key with the
> password. The process that I'm thinking about is this:
>
> 1) when a new area is created, a 3DES key (area key) is created.
> 2) for each user with access, the area key is encrypted with their
> password.
> 3) when a user needs to add or retrieve information, I take their
> password, decrypt the area key, and do what I need to.
>
> So my problems are as follows:
>
> (a) I need to authenticate the user first. Can I use MD5 or will that
> make it too easy to crack someone's password? Once you've got someone's
> password, it's all over.
> (b) How long must the user's password be in order to keep the key safe?
> (c) What's better, a 112- or 168-bit 3DES key?
> (d) Is there a huge flaw here that I'm not seeing?
>
> I don't have much practical experience with cryptography, which probably
> doesn't make me the best person to write this software, but I'd like to
> have a go at it anyway.
>
> Thanks.
>
> Isaac Oates
>
------------------------------
From: "Frog2000" <[EMAIL PROTECTED]>
Subject: Re: Can someone break this for me?
Date: Thu, 11 Jan 2001 09:32:24 -0500
"Greggy" <[EMAIL PROTECTED]> wrote in message
news:93jiid$bn3$[EMAIL PROTECTED]...
> In article <9F376.1600$[EMAIL PROTECTED]>,
> "Andrew Thomas" <[EMAIL PROTECTED]> wrote:
> > Hello,
> > Could someone please break this code for me:
> >
> > I idieeyooy a�� I�e�eai��!
> > I�e�eai�� � the ia�a�e�oa e�e�e��o� aeeieoaaie� iadi� ia ��ie!
> > I�d��e��o�o� I�e�eai��!
>
> Translated:
>
> * CLASSIFIED: TOP SECRET *
> NOSTRUDOMAS WAS RIGHT - THE VILLAGE IDIOT WAS ELECTED THE KING.
> SINCERILY, G. W. BUSH
Boy, I'll be up all night :)
>
>
>
>
> --
> I prefer my fourth amendment rights over a dope free
> society, even if the latter could actually be achieved.
> Al Gore and the Florida Robes - More than just another rock group;
> a clear and present danger to America's national security.
Dope free society? What are you smoking, and where can I get it :) I thought
Bush was the one that contested the "Gore win." one hour after NBC declared
Gore the winner. The whole thing looked fishy to me. Ever try the new
Sunshine/Chad acid?
--
http://welcome.to/speechsystemsfortheblind
>
>
> Sent via Deja.com
> http://www.deja.com/
------------------------------
From: [EMAIL PROTECTED] (DJohn37050)
Date: 11 Jan 2001 15:03:05 GMT
Subject: Re: Comparison of ECDLP vs. DLP
"Your PPT presentation confirmed my beliefs about RSA and ECC.
Specifically, that RSA is (practically speaking) impossible to verify
the accuracy of the software, where ECC code is more intuitive and
verifiable. This leads to a greater degree of confidence that the
algorithms are working correctly and that security is achieved properly.
The information you presented on RSA keys being less verifiable only
reinforces that feeling."
Great, glad you appreciated them.
Don Johnson
------------------------------
** 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 by posting to sci.crypt.
End of Cryptography-Digest Digest
******************************
