Cryptography-Digest Digest #175, Volume #10 Sat, 4 Sep 99 14:13:05 EDT
Contents:
Re: Random bits on a PC (Tim Tyler)
Re: NSA and MS windows (Bruce Schneier)
Re: NSA and MS windows (Bruce Schneier)
Re: SQ Announcement (SCOTT19U.ZIP_GUY)
Re: SQ Announcement ("Kostadin Bajalcaliev")
DES cfb stream cypher and "whitening" or initialization (Cary O'Brien)
Re: Public/Private Encryption Win32 Control? ([EMAIL PROTECTED])
Re: Schneier/Publsied Algorithms (Eric Lee Green)
Re: 512 bit number factored (Terje Mathisen)
Re: IDEA- safe? ([EMAIL PROTECTED])
Re: Random bits on a PC (Mok-Kong Shen)
----------------------------------------------------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Random bits on a PC
Reply-To: [EMAIL PROTECTED]
Date: Sat, 4 Sep 1999 13:19:17 GMT
Bartosz Zoltak <[EMAIL PROTECTED]> wrote:
: So please:
: If you know any methods of testing the generated bits for
: randomness (or - how much randomness is in them) - I would really
: appreciate it.
See Diehard, ENT and other tests for randomness. There's a comprehensive
section of links to sites with tests of randomness at:
http://www.alife.co.uk/links/random/
--
__________
|im |yler The Mandala Centre http://www.mandala.co.uk/ [EMAIL PROTECTED]
Destroy this tagline.
------------------------------
From: [EMAIL PROTECTED] (Bruce Schneier)
Subject: Re: NSA and MS windows
Date: Sat, 04 Sep 1999 13:57:56 GMT
On Sat, 04 Sep 1999 09:33:55 +0300, Red_Blue <[EMAIL PROTECTED]>
wrote:
>Bruce Schneier wrote:
>
>> Suddenly there's a flurry of press activity because someone notices
>> that the second key is called "NSAKEY" in the code. Ah ha! The NSA
>> can sign crypto suites. They can use this ability to drop a Trojaned
>> crypto suite into your computers. Or so the conspiracy theory goes.
>
>First of all, implementations that don't use CryptoAPI are secure from
>this, such as SSL and S/MIME in Communicator, and PGP. So only fully MS
>made security systems are affected because they have two trusted "root"
>keys instead of one. Right?
That is correct.
>The question is what actual methods of attack could be used to exchange
>the current Microsoft RSA Base Provider CSP module used by Explorer or
>Outlook with a weakened one that is signed with a key replaced by the
>attacker? And would this attack be so much more difficult than an attack
>which disables the verification instead of changes one of the two keys,
>that it would constitute a significant increase in actual risk of this
>kind of "weaken-the-crypto-suite-attack"?
Don't know. It's a good question.
If I were going to Trojan a crypto API, I would weaken the random
number generation process. Attacking the algorithms would mean that
the Trojaned operating system could not communicate with non-Trojaned
operating systems. Adding a subliminal channel would be too obvious
if noticed. Putting in a lousy PRNG would be viewed as a mistake made
by the original designers.
Bruce
**********************************************************************
Bruce Schneier, President, Counterpane Systems 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] (Bruce Schneier)
Subject: Re: NSA and MS windows
Date: Sat, 04 Sep 1999 13:58:55 GMT
On Sat, 4 Sep 1999 00:15:13 -0700, "Roger Schlafly"
<[EMAIL PROTECTED]> wrote:
>Bruce Schneier wrote in message <[EMAIL PROTECTED]>...
>>I see two possibilities. One, that the backup key is just as
>>Microsoft says, a backup key. It's called "NSAKEY" for some dumb
>>reason, and that's that.
>
>Maybe. Perhaps someone from the NSA suggested using a
>backup key, and the MS programmers called it the NSA key.
Agreed.
>>Two, that it is actually an NSA key. If the NSA is going to use
>>Microsoft products for classified traffic, they're going to install
>>their own cryptography. They're not going to want to show it to
>>anyone, not even Microsoft. They are going to want to sign their own
>>modules. So the backup key could also be an NSA internal key, so that
>>they could install strong cryptography on Microsoft products for their
>>own internal use.
>
>I doubt it. I can understand NSA not wanting to show its crypto
>module to MS, but it wouldn't have to anyway. If the NSA wants
>a CAPI module signed, all it has to do is to give an MD5 hash
>to MS, and MS returns a signature. Quick, and revealing nothing.
>
>I think this second explanation only makes sense if it is part
>of some NSA scheme to plant bogus CAPI modules somewhere.
>Legitimate modules could be signed in the normal way.
I agree, I think. The NSA would not want Microsoft to see their
classified crypto modules, but they could always send Microsoft the
hash and say "sign this."
Bruce
**********************************************************************
Bruce Schneier, President, Counterpane Systems 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] (SCOTT19U.ZIP_GUY)
Subject: Re: SQ Announcement
Date: Sat, 04 Sep 1999 15:54:08 GMT
In article <7qqooc$[EMAIL PROTECTED]>, "Kostadin Bajalcaliev"
<[EMAIL PROTECTED]> wrote:
>>It certainly sounds like you are tackling the right problems. If we
>>had a theory that could provide proofs of security (or design principles)
>>for RC4-like ciphers, that would be extremely interesting.
>>
>>However, I don't yet understand how the theory you are describing works.
>>Again, this may be just a communications problem.
>
>
>First of all Shanon theory apply to Block Ciphers too, when they are used in
>OFB mode, but as much as I know no one can compute the key (of RC5 for
>example) just having couple of ciphertext blocks. The second thing, there is
>nothnig as "no bounds on our computing power".
>
>About the theory, I let me try again to explain it. Let C(x) is some
>self-mutating stream cipher (RC4 like). The key by definition is unknown,
>the only thing we have is the output sequence. In order to revers a single
>round we need information G. This is the needed quantity of information. On
>other hand we have the information carryed by the output sequence B. B is
>the maximum quantity of information we can destiled from the output sequence
>about the inner state of the generatort. If G>B than the rest G-B is unknow,
>that is the "lost" information that we need to predict because there is no
>other way. And the whole point is how to design a stream cipher so there to
>be enought "lost" information so it can be secure. This theory is how to
>make a cipher to be something as solving system of 6 equants with 7
>unknowns. Here is part of the thesis (which you should read)
>
>===============================
>In all classic books about Cryptography you can find that there is no secure
>algorithm, only they can be more or less complex to break. I am going to
>show that it is possible to design provably secure algorithms. The output
>sequence and all the details about the algorithm are unconditionally
>available to the attacker. Attacker do not know the state of algorithm, his
>objective is to reconstruct generator state so he can produce any further
>output. Because setting the initial state is in fact SC keying, the last
>statement mean that attacker can not know the key. This is the standard
>assumption about security, only unknown is the key, the whole security of
>the algorithm relay on the secrecy of the key.
>
>Classical approach to solve this problem is by making the algorithm to be a
>complex function of transformation, having pairs x, F(x) (just to remained
>that every SC is xk=F(xk-1)) is not enough to reconstruct F in a given
>point. But using only this approach we are always forced to make assumptions
>about security, putting the security of the design on the hardness to solve
>or invert some mathematical construction.
>
>Before I define my idea how to make provably secure SC, here is a little
>illustration story.
>
>Old Puzzle Problem
>
>There is a puzzle, a very old one, and someone is trying to solve it. But
>the bricks are old and damaged, so it is hard to distinguish their forms for
>sure. Two originally different parts are now almost the same and we can not
>do anything to found their original form. We try to predict the original
>form of the bricks but there are so many of them. Also the colors are
>damaged. Some bricks are in better condition and we have a general idea what
>the puzzle was, but we can never say it for sure.
>
>I am using this museum story to introduce the using of the same idea in SC
>design. For example, there is a PRBG with 8 bits output per iteration, if we
>discard one of them we get 7 bit value (I call this �secondary output�), so
>the output sequence constructed does not carry the whole information about
>the generated output values. Having xk=F(xk-1); 8 bit generator, discarding
>the first result is ZYYYYYYY, where Z is the discarded bit. Let Z�XXXXXXX
>and Z��YYYYYYY be two successive values connected by Z�YYYYYYY=F(Z��
>XXXXXXX); but Z� and Z�� are unknown so there 4 different equates and only
>one of them is the true.
>
>0YYYYYYY=F(0XXXXXXX);
>0YYYYYYY=F(1XXXXXXX);
>1YYYYYYY=F(0XXXXXXX);
>1YYYYYYY=F(1XXXXXXX);
>
>It is impossible to mathematically found which is the true one if Z is
>unknown. Prediction can be made but that is equal to the problem of guessing
>the original form of the puzzle brick. If the generator output is 32bit but
>only one bit from each generated value is used to form the output sequence,
>then guessing these 31 missing bits is practically impossible.
>
>This is the �information loss� approach to solve the security problem about
>SC. Because the output available to the attacker does not carry the whole
>information needed to apply some attack he can not do it. He can not do it
>even if he found some efficient approach to break it in its pure form. This
>approach is done using the 4th assumption about randomness from the
>beginning of this thesis.
>==============================
>
There are examples of this in control theroy books. It is like trying to
determine the internal state varables from a very small set of variables
that can be output. Yes at any one step there is not enough information
to guess what the input state is. However given enough time and enough
measurements it usually is possible to recover the state varables and
in this case the KEY. When the situation is such that you can'r recover
the whole key. It means that the whole key was not unique in the
sense that so much information was lost in producing the output that
the part not recovered was not relavent to the resulting bit stream and
is not needed.
Example lets say the genrator is outputing 1,0,1,0,1,0 .... not very random
I know. But lets say after awhile there are ten possible keys that could
do thiis in the original model. The attacker does not know which key was
used. But after this sequence occurs long enough. He knows from his total
knowledge of the system that it is not going to change. IN this case the
attacker can not guess the key. Becasue in this case there is not enough
relavent information to go back to the key. But would should the attecker
go back after a point he can create the next bit with 100% certainy with
out knowing which key it was.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
http://members.xoom.com/ecil/index.htm
NOTE EMAIL address is for SPAMERS
------------------------------
From: "Kostadin Bajalcaliev" <[EMAIL PROTECTED]>
Subject: Re: SQ Announcement
Date: Sat, 4 Sep 1999 17:22:23 +0200
Thank you GOD at least one cleary got the point.
SCOTT19U.ZIP_GUY wrote in message <7qrbqt$194m$[EMAIL PROTECTED]>...
>In article <7qqooc$[EMAIL PROTECTED]>, "Kostadin Bajalcaliev"
<[EMAIL PROTECTED]> wrote:
> There are examples of this in control theroy books. It is like trying to
>determine the internal state varables from a very small set of variables
>that can be output. Yes at any one step there is not enough information
>to guess what the input state is. However given enough time and enough
>measurements it usually is possible to recover the state varables and
>in this case the KEY. When the situation is such that you can'r recover
>the whole key. It means that the whole key was not unique in the
>sense that so much information was lost in producing the output that
>the part not recovered was not relavent to the resulting bit stream and
>is not needed.
>
> Example lets say the genrator is outputing 1,0,1,0,1,0 .... not very
random
>I know. But lets say after awhile there are ten possible keys that could
>do thiis in the original model. The attacker does not know which key was
>used. But after this sequence occurs long enough. He knows from his total
>knowledge of the system that it is not going to change. IN this case the
>attacker can not guess the key. Becasue in this case there is not enough
>relavent information to go back to the key. But would should the attecker
>go back after a point he can create the next bit with 100% certainy with
>out knowing which key it was.
>
>
>
>
>David A. Scott
>--
> SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
> http://www.jim.com/jamesd/Kong/scott19u.zip
> http://members.xoom.com/ecil/index.htm
> NOTE EMAIL address is for SPAMERS
------------------------------
From: [EMAIL PROTECTED] (Cary O'Brien)
Subject: DES cfb stream cypher and "whitening" or initialization
Date: 4 Sep 1999 11:59:53 -0400
I (like probably 10% of the readers) need to encrypt a data stream with a
stream cypher. I want to use des in cfb mode (specifically des_cfb64_encrypt
from libdes). The system will use shared secrets for keys. The problem
is that the packet structure of the underlying data stream would be know
to an attacker (ok, ok, it is ppp). I'm worried that this will provide
the attacker with a known-cleartext attack. Not good.
I propose to insert 4 bytes of "random" data to the beginning of the
cleartext data stream on the encryption side, and drop the first 4 bytes
on the decryption side.
1) Is this worth the effort?
2) Am I being otherwise stupid?
Thanks,
-- cary
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Public/Private Encryption Win32 Control?
Date: Sat, 04 Sep 1999 15:35:09 GMT
In article <7qmtji$kur$[EMAIL PROTECTED]>,
"forq" <[EMAIL PROTECTED]> wrote:
> I suppose I could make external calls to PGP, but I'd rather not, as
> it isn't nearly as elegant, and I'm not even sure I can do that
> from .ASP pages. Why am I using NT & ASP? Well, that isn't my
> choice...
Freeware PGP componant for use with PGP 6.5.1 and ASP.
http://community.wow.net/grt/nsdpgp.html
ASPTODAY has an article (August 2) on using ASP to encrypt
credit card info and email the encrypted data. This uses the DLL.
http://www.asptoday.com/articles/19990802.htm
Componant has five methods:
EncryptFile(cipher,infile,outfile,password)
DecryptFile(infile,outfile,password)
WipeFile(infile)
EncryptFileEx(rcptkeyid,signkeyid,infile,outfile,password)
DecryptFileEx(siginfofile,infile,outfile,password)
parameters:
cipher is an integer that indicates the desired conventional cipher
algorithm. Valid values are 1 (for IDEA), 2 (for CAST5) and 3 (for
3DES).
infile and outfile are strings giving the filenames (including full
path)
for the input and output files.
password is a string giving the conventional password or keyring
passphrase.
siginfofile is a string giving the filename (including full path)
for the file into which the signature verification information will be
written.
rcptkeyid and signkeyid are strings giving the KeyIDs of the recipient
and signing
keys.
Gerard R Thomas
Port of Spain, Trinidad and Tobago
mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED]
PGP Key IDs: RSA:0x9DBCDE7D DH/DSS:0xFF7155A2
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: Eric Lee Green <[EMAIL PROTECTED]>
Subject: Re: Schneier/Publsied Algorithms
Date: Sat, 04 Sep 1999 10:27:02 -0700
"SCOTT19U.ZIP_GUY" wrote:
> >cryptographic strength). My understanding is that the typical criticism
> >of your program is that it's rather slow for the amount of cryptographic
> >strength provided.
> And naturally you belive that with out even trying it. People have
> compared the speed of scott16u to blowfish and it was not that slow.
> The real time hog is the actual seting up of the S-box. But that can
> be done independent of the actaul encryption.
You are correct that I have not run your program. I am a Unix software
developer and do not run Windows. When I'm not running FreeBSD, I'm
usually running Linux. (We also have Sun, DEC, AIX, etc. machines in our
software porting lab, but Linux makes a lot cheaper Unix software
development station so as we've grown we've retired our old workstations
to the lab and gone all-Linux for the workstations).
All that aside, your algorithm would not work for us anyhow because we
must be able to decrypt the outcoming data stream as it comes over the
network, because we are sending the output to different locations and do
not have the necessary storage to buffer it all for future decryption.
This is a case where a traditional block cipher is the right solution
(our application pre-blocks the data in the first place, since the
output devices are block devices).
> >tell RC5 seems to be considered secure). The NSA's choices for finalists
> >seem to be pretty close to what the public community predicted before
> >the finalists were announced.
> >
> >In addition, at least two of the AES candidates are based on prior work,
> >i.e. RC6 is basically a derivative of RC5, and Twofish is a derivative
> >of Blowfish. Both RC5 and Blowfish have been hit on pretty hard, making
> >it unlikely that their derivatives have a weakness that would allow
> >anybody to crack them in significantly less time than is currently
> >conjectured.
> >
>
> I think you greatly underestime the strength of the NSA decrpytion ability.
> As well as there ability to make current research go in the wrong direction.
> They use any and all means to prevent the world from having safe encryption
> The microsoft thing is just the tip of the iceberg.
When it comes to ciphers, I don't think that I'm underestimating them by
much. The problem with ciphers is how to recover either the key or the
message from what is to all appearances random noise. I'm sure the NSA
has methods we don't know about, but even the NSA cannot change the laws
of mathematics, and this is an area that has been intensely studied over
the years since the late 40's -- there's just not much left to suck out
of that husk.
On the other hand, public key encryption (like in the "microsoft thing")
is a fairly new field (and there has been an insinuation that actually
it's an older field, that the NSA had it for years before Shapir et. al.
let the genie out of the bottle), and yes, I agree with you that the NSA
may have methods that significantly compromise the existing schemes. We
just haven't been doing the math in this area for long enough to have a
large degree of confidence, and if the hints about the NSA's past
capabilities are correct, the NSA *has* been doing the math in this area
for a significantly longer time. Schneier may dismiss the possibility
of some quantum leap in mathematics making current public key schemes
insecure, but looking at the slow growth of mathematical knowledge over
the years and how so many "impossible" problems have taken decades or
even in some cases centuries to crack, I have to remind folks that the
field of mathematics operates in generational time, not in Internet time
-- and the NSA has been doing research in this area for a generation.
But then again, for my particular application I don't care much if the
NSA can crack it, as long as random criminals can't crack it. I suspect
that it won't even be operated in encryption mode most of the time,
because most of the data is pretty ordinary stuff that has no real
privacy implications sent over a switched private LAN, and strong
authentication is all that's needed there. A few banks have asked for
encryption capability, but even there the NSA is not the boojum (most of
these banks probably already cooperate with the NSA and give the data
plain-text to the NSA, though none will ever admit it, no more than AT&T
admitted giving all international telegrams to the NSA), random
criminals are, and if it keeps criminals from inserting their own
account numbers into the data as the destination of deposits, and keeps
criminals from sniffing information that can be used for non-crypto
attacks in the "real world", it's done its job.
--
Eric Lee Green http://members.tripod.com/e_l_green
mail: [EMAIL PROTECTED]
^^^^^^^ Burdening Microsoft with SPAM!
------------------------------
From: Terje Mathisen <[EMAIL PROTECTED]>
Subject: Re: 512 bit number factored
Date: Sat, 04 Sep 1999 18:44:10 +0200
[EMAIL PROTECTED] wrote:
> A large number of corporate-bank and even some inter-bank payment links
> use 512 bit RSA (or even symmetric technologies). In value, and probably
> in volume these links eclipse any Internet-based eCommerce. I believe
> S.W.I.F.T.'s keys are longer, but then they move something like USD 9
> trillion/day..
The other Terje is correct, I spent yesterday in a conference with
several UK banks & financial institutions: According to a guy from
Barclays, SWIFT uses 512-bit RSA for all transfers.
:-(
Terje
--
- <[EMAIL PROTECTED]>
Using self-discipline, see http://www.eiffel.com/discipline
"almost all programming can be viewed as an exercise in caching"
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: IDEA- safe?
Date: Sat, 04 Sep 1999 16:36:56 GMT
In article <7qm7vk$3nj$[EMAIL PROTECTED]>,
"Jim Butcher" <[EMAIL PROTECTED]> wrote:
> has anyone heard of a successful cryptanalysis of the IDEA algorithm?
128
> bit key, 64 bit block size
> for that matter Blowfish 256 bit key?
>
> Jim Butcher
> [EMAIL PROTECTED]
>
>
Yes, there has been one successful cryptanalysis of IDEA. There was a
side-channal attack that targetted the fact that the multiplication by
2^16 + 1 was done using an if statement. This was because
multiplication by 0 was a special case. If you find the web page of the
people who one it, I forget who, they have a fix for it.
Casey
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Random bits on a PC
Date: Sat, 04 Sep 1999 18:45:38 +0200
Kostadin Bajalcaliev schrieb:
>
> Try DIEHARD battery of tests.
For people who apply it, it should be noted that a version of Diehard
had certain bugs. I am not sure though of the status at the current
moment of the Diehard package.
M. K. Shen
------------------------------
** 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
******************************
