Cryptography-Digest Digest #454, Volume #13 Thu, 11 Jan 01 03:13:01 EST
Contents:
Re: Comparison of ECDLP vs. DLP (Roger Schlafly)
Re: Can someone break this for me? (Greggy)
Re: NSA and Linux Security (Greggy)
Re: NSA and Linux Security (Greggy)
Re: Hash/Message digest vs Signature vs MAC? ("Scott Fluhrer")
Re: xor'd text file - Cryptanalyis of Simple Aperiodic Substitution Systems
(Warning: LONG post) (Bryan Olson)
Re: NSA and Linux Security (Greggy)
Re: Enigma Emulator for Palm Pilot? (Richard Heathfield)
Re: RSA recoverable signature trick (Mark Currie)
Re: RSA recoverable signature trick (Mark Currie)
rc4 in javascript bug ([EMAIL PROTECTED])
Re: rc4 in javascript bug (Paul Rubin)
----------------------------------------------------------------------------
From: Roger Schlafly <[EMAIL PROTECTED]>
Subject: Re: Comparison of ECDLP vs. DLP
Date: Wed, 10 Jan 2001 22:09:40 -0800
Greggy wrote:
> > I see you have to put "theorems" in quotes. They prove something,
> > but they do not prove that RSA-PSS is secure. The security argument
> > is a hand-waive.
> That is what I was trying to get at with my last post - that if you
> base your assumptions on the basic postulates of math, such as "1
> exists, 1+1=2, etc.", then the theorems that can be proven based upon
> those assumptions will be accepted by anyone. How strong are the
> assumptions (the postulates) that underline the theorems being proposed?
Right. If it is a mathematical proof of security, then there is
no dispute. Chances are, whatever the supposed proof for ECDSA
is, it is some other kind of beast.
------------------------------
From: Greggy <[EMAIL PROTECTED]>
Subject: Re: Can someone break this for me?
Date: Thu, 11 Jan 2001 06:07:13 GMT
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
--
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.
Sent via Deja.com
http://www.deja.com/
------------------------------
From: Greggy <[EMAIL PROTECTED]>
Subject: Re: NSA and Linux Security
Date: Thu, 11 Jan 2001 06:10:46 GMT
In article <[EMAIL PROTECTED]>,
"Douglas A. Gwyn" <[EMAIL PROTECTED]> wrote:
> Greggy wrote:
>
> > Fine, but what of Echelon?
>
> It's a word in any reasonable English dictionary,
> denoting a level of military organization.
>
> > It should be the policy of the United States of America never to
enter
> > into secret association with any entity. If a foreign government
> > cannot do business with the United States in the open, then that
should
> > be their problem not ours.
>
> Sources and methods of intelligence production
> often have to be kept secret in order for them to
> work at all.
>
>
It is MY opinion, and I want to stress that I realize (so don't tell me
the obvious) that it would be like being hit with lightning to find
someone who agrees with me on this, that we don't need no stinkin
secrets if it means giving our servants power to conceal anything from
we the people. Pure and simple.
Anyone who tells you they have to keep things secret don't have moral
integrity to rule over you. They only wish to justify hiding their
crimes. In other words, I don't believe your premise as you stated
it. I believe this country could do without secrets. We don't need to
be involved in the black world AT ALL!
--
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.
Sent via Deja.com
http://www.deja.com/
------------------------------
From: Greggy <[EMAIL PROTECTED]>
Subject: Re: NSA and Linux Security
Date: Thu, 11 Jan 2001 06:12:43 GMT
In article <93is7i$e80$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (David Wagner) wrote:
> Douglas A. Gwyn wrote:
> >> Fine, but what of Echelon?
> >
> >It's a word in any reasonable English dictionary,
> >denoting a level of military organization.
>
> No, that's lower-case "echelon". Upper-case "Echelon" is often
> used by NSA-watchers either (1) to refer specifically to a NSA
> interception program that apparently is/was codenamed ECHELON, or
> (2) to refer generally to NSA's worldwide interception capabilities.
> (Be warned that folks often aren't clear about which meaning they
> are using. Moreover, it's not clear whether both meanings are
> identical, or whether ECHELON is just one small part of the NSA's
> total facilities for interception.)
>
> It seems hard to deny the existence of ECHELON, from the evidence
> we have available to us today.
Take it a step further, would you please? It would be misinformative
to deny its existance given the amount of information we have today.
It may actually not exist, but that has become an extremely remote
possibility that to suggest it is like suggesting the sun will not come
up in the morning but only tomorrow.
>
> See, e.g.,
> http://www.gwu.edu/~nsarchiv/NSAEBB/NSAEBB23/09-03.htm
> which shows a memo, obtained by FOIA, telling the commanding
> officer of a military site in Sugar Grove, West Virginia that
> one of his duties is to maintain an ECHELON site.
>
> Or, see the admissions by officials in New Zealand and Australia
> of the existence of Echelon (at least in the sense (2) above,
> if not in the sense (1) as well), and that they cooperate with
> the NSA to operate it.
>
--
I prefer my fourth amendment rights over a dope free
society, even if the latter could actually be achieved.
Sent via Deja.com
http://www.deja.com/
------------------------------
From: "Scott Fluhrer" <[EMAIL PROTECTED]>
Subject: Re: Hash/Message digest vs Signature vs MAC?
Date: Wed, 10 Jan 2001 22:22:45 -0800
Ingmar Grahn <[EMAIL PROTECTED]> wrote in message
news:93hji2$c0i$[EMAIL PROTECTED]...
> Hi!
>
> I'm trying to clear out the concepts of Hash algortithms/message digests,
> Signatures and MACs since they seem to be somewhat correlated. Could
someone
> please correct me where I'm wrong and add comments if suitable:
>
> * A hash algorithm creates a message digest that's different for (almost)
> every possible message. Therefore it should be impossible to create a new
> message m', such that H(m)=H(m'). This ensures noone can tamper with the
> message without us noticing it, right?
Unless, of course, he can also tamper with the hash the receiver compares
against. For example, if Alice sent the message m and the hash H(m), and if
Mallet can intercept it, and replace it with mesage m' and the hash with
H(m'), then Bob will receive m' and H(m'), and everything will check out.
And to correct your terminology, a hash algorithm doesn't produce a digest
that's different for every possible message -- that's impossible if the hash
output is shorter than the message length. What secure hash functions
attempt to do is make it computationally infeasible to find two message m
and m' with m!=m' and H(m)=H(m')
>
> * Now, the signature is basically a message digest created with a hash
> algorithm, that after it's been calculated also has been encrypted with
the
> sender/issuers private key. This is so that for example when used in a
> certificate, one can check out the issuer(by looking in the certificate
> data), and if the issuer is known to the recipient, he already has the
> issuers public key (or can get hold of it). So now he takes the encrypted
> message digest(=signature) that is sent along with the certificate, and
> decrypts it using the issuers public key, and then compare this decrypted
> message digest to the one he can calculate himself (using the actual data
of
> the certificate as input). If they are the same, he knows that the
> certificate is legitimate, and that it hasn't been tampered with.
>
> Is this correct? And are there any other other uses for Signatures?
Well, there are other types of signatures (such as one-time signatures), but
I think you understand the basic concept.
>
> * A MAC is basically a message digest created by a hash algorithm that
apart
> from the message also takes a key as input. So we have
> MAC=HashAlgortithm(K,m). Now, what's the reason for throwing in the key?
Why
> not just calculate the message digest without the key, and then encrypt
the
> whole package (Message+Digest)?
A MAC is an encryption primitive that has the property that, if an attacker
without knowledge of the key is presented with a large sequence of (m,
MAC(K,m)) pairs (for possibly attacker chosen m's), he is unable to compute
a new pair (m', MAC(K,m')) (where m' is not one of the m's already listed)
with nontrivial probability. There's no requirement that a MAC with a
publicly known key have any particular security properties, for example,
that it be a secure hash function.
When doing message authentication, this key provides the authentication.
You saw above how an active attacker can replace (m, HASH(m)) with
(m',HASH(m')). However, if you use a MAC instead, he cannot replace (m,
MAC(K,m)) with (m',MAC(K,m')) because that's exactly what a MAC is designed
to be strong against. And yes, even with encryption, an attacker can
sometimes make precise changes to messages (eg. stream ciphers and "bit
flipping attacks"), and so you idea of appending a HASH and encrypting
wouldn't always work.
--
poncho
------------------------------
From: Bryan Olson <[EMAIL PROTECTED]>
Subject: Re: xor'd text file - Cryptanalyis of Simple Aperiodic Substitution Systems
(Warning: LONG post)
Date: Thu, 11 Jan 2001 06:19:41 GMT
Douglas A. Gwyn wrote:
> Paul Pires wrote:
> > ... To me, It seems that:
> > *if you can make a stream cipher that breaks the locational
relationship
> > between ciphertext, state and plaintext. AND
> > *if you can make a stream cipher that automagically authenticates.
AND
> > *if you can do these things without loosing the speed and simplicity
> > advantages......
> > Then, it might just be interesting.
>
> Genuine stream ciphers (e.g. those long used by government)
> often meet these requirements.
Probably the most popular stream cipher in commercial use,
(and also used by the government), is CBC-mode DES, probably
followed by the other FIPS-approved modes of DES and 3DES.
DES is a block cipher; the modes build a stream cipher from
a block cipher.
--Bryan
Sent via Deja.com
http://www.deja.com/
------------------------------
From: Greggy <[EMAIL PROTECTED]>
Subject: Re: NSA and Linux Security
Date: Thu, 11 Jan 2001 06:20:05 GMT
> > Simon Johnson <[EMAIL PROTECTED]> wrote:
> >> Since this role doesn't exist in the same capacity
> >> as before, they must be forced to do other work.
>
> >What on earth could you possibly point to as the basis for your
> >statement?
>
> How about the computer you're using to connect to the Internet?
No, he said:
Prehaps the NSA have been forced to shift there policy somewhat due to
the possibilitity of having their funding cut. In the times of the cold
war, the NSA needed to be a secret agency which did secret things.
Since this role doesn't exist in the same capacity as before, they must
be forced to do other work.
As I read his statement, he suggested that the secretiveness of the NSA
went the way of the cold war. His statement had nothing to do with my
computer, nor did I question your view. I questioned how he could say
that the NSA is losing secretiveness when clearly they are darker than
ever. The NSA is alive and VERY WELL as they continue to eat away at
the bill of rights, since there is no soviet union to eat away at any
longer. It may be that they are just trying to refine their art for
the next war, or perhaps they are just looking to keep their jobs and
are trying to convince congress that we are the new enemy of the state.
Take your pick, but reality is, they are dark and they have chosen we
the people to be their next target.
--
I prefer my fourth amendment rights over a dope free
society, even if the latter could actually be achieved.
Sent via Deja.com
http://www.deja.com/
------------------------------
Date: Thu, 11 Jan 2001 07:01:54 +0000
From: Richard Heathfield <[EMAIL PROTECTED]>
Subject: Re: Enigma Emulator for Palm Pilot?
"Rich W." wrote:
>
> Does anyone know of an Enigma Emulator for the Palm Pilot?
Given sufficient interest and a decent spec, I'd be happy to write one.
--
Richard Heathfield
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton
------------------------------
Subject: Re: RSA recoverable signature trick
From: [EMAIL PROTECTED] (Mark Currie)
Date: 11 Jan 2001 07:12:12 GMT
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 ?
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.
>******************************************************************************
*******
------------------------------
Subject: Re: RSA recoverable signature trick
From: [EMAIL PROTECTED] (Mark Currie)
Date: 11 Jan 2001 07:25:36 GMT
In article <93eva0$30v6$[EMAIL PROTECTED]>, [EMAIL PROTECTED] says...
>
>"Hans-Peter Baron" <[EMAIL PROTECTED]> wrote:
>> 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".
>
>Arjen Lenstra has written a paper on the subject, "Generating RSA Moduli
>with a Predetermined Portion" (presented at ASIACRYPT'98, don't know if the
>paper is available online). There is also a heuristic security discussion
>in the paper. I would recommend applying RSA-PSS-R to the modulus; let the
>predetermined part of the modulus be non-recoverable from the signature (it
>can be agreed on in advance), and let the remaining part be recoverable.
>RSA-PSS-R is described in the draft IEEE P1363a (IFSSR with EMSR3), see
>http://grouper.ieee.org/groups/1363/ (finding out how to get the password
>needed to download the document is a stimulating exercise...).
>
Thank you for your help, a predetermined portion of the modulus would give me
enough redundancy but I don't want to impose on the key generation. I have
basically decided not to use this method now anyway.
>The most significant bit and the least significant bit in a modulus are
>always 1; the first bit is 1, because otherwise the modulus wouldn't be
>large enough; the last bit is 1 because any RSA modulus is odd.
>
Of course this is the simple trick that I was looking for. Thank you once
again, this could still be useful in the case where you might wish to perform a
public key operation on a signature.
Mark
------------------------------
From: [EMAIL PROTECTED]
Subject: rc4 in javascript bug
Date: Thu, 11 Jan 2001 07:43:01 GMT
Hi there !
I adapted the rc4 to javascript but it seems to have a bug. Although
encypting the same string twice by nesting the cipher function call
returns the plain text without any problems, it seems that encrypting
it once, copying the encrypted text and having it decrypted fails to
decrypt some characters.
Basically, I encapsulated the encrypted text in a html file and the
encrypted text is the body of the html file. I load in the html reader
file the encrypted text in an invisible floating frame and get the
encrypted text through the document object model, submit it to my rc4
function along with the key.
cipher(text,key) is the rc4 algorithm in my javascript implementation
cipher(cipher(text,key),key) returns the plain text back
cipher(plaintext,key)>display encrypted text, highlight and copy into
an html file>cipher(encryptedtext,key) doesn't return correct plain text
<script>
<!--
function cipher(source,key){
var state=new Array();
var outp="";
for (i=0;i<256;i++){
state[i]=i;
};
var j=0;
for (i=0;i<256;i++){
j=(j+state[i]+key.charCodeAt(i%key.length))%256;
swap("state[i]","state[j]");
};
i=0,j=0;
for (k=0;k<source.length;k++){
i=(i+1)%256;
j=(j+state[i])%256
swap("state[i]","state[j]");
outp+=String.fromCharCode(source.charCodeAt(k)^state[(state[i]
+state[j])%256]);
};
function swap(item1,item2){
eval("var temp="+item1);
eval(item1+"="+item2);
eval(item2+"="+temp);
};
return outp;
};
/-->
</script>
What do you thing might be wrong ? I need to escape before encryption
and then unescape after decryption when encrypting html code but I want
to sort this for plain text only, encypting html is easy after that.
Thanks.
Sent via Deja.com
http://www.deja.com/
------------------------------
From: Paul Rubin <[EMAIL PROTECTED]>
Subject: Re: rc4 in javascript bug
Date: 11 Jan 2001 00:03:14 -0800
[EMAIL PROTECTED] writes:
> I adapted the rc4 to javascript but it seems to have a bug. Although
> encypting the same string twice by nesting the cipher function call
> returns the plain text without any problems, it seems that encrypting
> it once, copying the encrypted text and having it decrypted fails to
> decrypt some characters.
How are you copying the encrypted text? Remember that the output is
full of non-printing characters, so if you're trying to cut and paste
it, that may be garbling it up.
------------------------------
** 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
******************************
