Cryptography-Digest Digest #188, Volume #10 Mon, 6 Sep 99 11:13:07 EDT
Contents:
NY Times Article--RSA 512 encryption code cracked (John Bailey)
Re: _NSAKey (JPeschel)
Re: Workshop in Paris on Watermarking and Copyright enforcement (Lars Broecker)
Re: DES cfb stream cypher and "whitening" or initialization (Tom St Denis)
Re: _NSAKey ([EMAIL PROTECTED])
Re: hash function ? ([EMAIL PROTECTED])
Re: point of a cipher (JPeschel)
Re: NSA and MS windows (Alan Braggins)
Re: CryptoAPI (Geoff Thorpe)
Re: point of a cipher (Tom St Denis)
Re: Schneier/Publsied Algorithms (Geoff Thorpe)
Re: point of a cipher (SCOTT19U.ZIP_GUY)
Re: point of a cipher (SCOTT19U.ZIP_GUY)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (John Bailey)
Subject: NY Times Article--RSA 512 encryption code cracked
Date: Mon, 06 Sep 1999 12:01:38 GMT
In this mornings NY Times:
http://www.nytimes.com/library/tech/99/09/biztech/articles/06code.html
quote
The researchers' actual feat was to factor a 155-digit number
into its two component prime factors. The inherent hardness of
factoring, an immensely difficult and time-consuming task for
even the most powerful computers, provides the security for
RSA. Factoring a certain large number associated with an RSA
key enables that key to be cracked
end quote
------------------------------
From: [EMAIL PROTECTED] (JPeschel)
Subject: Re: _NSAKey
Date: 06 Sep 1999 12:27:17 GMT
Stephan Eisvogel <[EMAIL PROTECTED]> writes:
>JPeschel wrote:
>> Well, here's a disassembly of AdvApi32.DLL for everyone's
>> amusement:
>
>You should get a much better disassembler, I hope you can
>find out which one I am talking about.
>
>Microsoft's is not bad to get an idea where a module
>segfaulted, but for deadlisting there's a much better
>alternative.
>
>Regards,
>I.D.Aye
Stephan, neither the disassembly nor the disassembler is mine.
I suppose you could do a deadlisting of the file with WDASM, but it
looks like you're suggesting IDA. I think if someone wanted
to probe AdvApi32.dll, he might be better served by putting his
disassembler on ice and using a system-level debugger. You,
of course, know which one I mean. :-)
Joe
__________________________________________
Joe Peschel
D.O.E. SysWorks
http://members.aol.com/jpeschel/index.htm
__________________________________________
------------------------------
From: Lars Broecker <[EMAIL PROTECTED]>
Subject: Re: Workshop in Paris on Watermarking and Copyright enforcement
Date: Mon, 06 Sep 1999 14:45:28 +0200
Soeren Mors wrote:
<snippiyayeee>
> > As for your statement about "bogus claims, like compression programs
> > that can supposedly compress every file." I think my compression method
> > on "http://members.xoom.ecil/compress.htm" can compress every finite
> > file that is not to large that the operating system can't handle it.
> > But before you get all huffy. It is "one to one". That is every file
> > compresses to a unique file. And every file decompresses to a unique
> > file. However it is does not violate the counting therom since the average
> > compression of a random file actaully makes the output file longer.
> > Also it may seem strange to you but the decompression portion actaully
> > makes the average random file longer too. It just makes the file longer on
> > the average than the compression.
>
> Your use of the word compression is interesting to say the least. I
> wouldn't call it compression if the file actualy got larger.
>
I think what he means is that his compression creates a table or
something of the tokens and their replacement (in order to recreate them
later - just think of a Huffman-tree). And that additional information
lets the file grow. That is true at least for arj and pkzip, at least
the last time I tried compressing already compressed files. But in many
cases the netto growth in size when compressing is negative as desired.
Just my 2 cent
Lars Broecker
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: DES cfb stream cypher and "whitening" or initialization
Date: Mon, 06 Sep 1999 13:07:19 GMT
In article <7qv3ch$4fh$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Cary O'Brien) wrote:
> >
>
> No, not at all.
>
> I want to provide a non-trivial way to protect a data stream that the
> customer can easily implement on his own if he chooses not to allow us
> to put our software/hardware on their lan. This is exactly opposite
> of being 'buzzword' compliant. The idea is to have an open protocol
> so the client can either verify or implement on their own. Perhaps
> the crack about PHBs confused things. I *really* want the customer to
> feel free to build his own side of the link with his own tools. All
> he needs is libdes and a 20 line program to feed the cfb64 routine. I
> know if it were *my* network I'd be a little leery about letting
> someone drop a mystery box in without understanding what was going on.
>
> Plus it needs to be exportable and unencumbered by licencing or
> trade secret issues.
>
> I'm open to constructive suggestions.
Why not use more modern block ciphers? Try Blowfish (www.counterpane.com)
for example. It's simple to code (can be done in under 5 minutes) and has a
larger keyspace.
> >Can I find the name of your company so I can rememeber never to look at it
> >again?
>
> I'm just a part-time contractor, but thanks for the vote of confidence
> none the less.
Sorry but it doesn't seem like you did much research into crypto, there are
about 10 other block ciphers you could use outside of DES (RC5, TEA, XTEA,
ICE, MISTY, most AES ciphers ....)
> >Your real question is moot, why use DES in a NEW application? It makes no
> >sense... why not build 8086 desktops? Cuz they are obsolete.... DES might
> >have been strong 10 years before it was made, but not now...
> >
>
> See above. Or suggest an alternate design.
Use a different algo, that's all.
Tom
--
damn windows... new PGP key!!!
http://people.goplay.com/tomstdenis/key.pgp
(this time I have a backup of the secret key)
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: _NSAKey
Crossposted-To: talk.politics.crypto
Date: 6 Sep 1999 08:38:51 -0400
There have been claims that since the government can get information
other ways, they don't need an extra key for certifying software in
WinNT.
And that is why there are so few cars on the road.
Because folks don't NEED them, they use public transportation.
And why the government is not pressing for access to plain text of
communications.
Because they can get search warrants forcing divulgence of the
information, they don't NEED it.
And why banks don't have to give the IRS customer information on demand,
since the IRS doesn't NEED this. They can always get a court order.
While it may not be necessary ... consider a web site for
terrorists/communists/libertarians/paedophiles or your favourite group
of "evil people" this week. How to gain access to its users' security?
Well, we could track down each user and break into each house and ....
or perhaps, hack the site and add some ActiveX to provide a "patch" to
their OS -- of course, it would have to be signed.
It may not be NECESSARY for the government to have access to the OS at
this level, but it surely would be convenient. It would be nice. It
would be desirable.
The argument that it cannot be a government key because the government
does not *need* such access does not hold water. One would have to show
that this access is not *desired* by the government. I don't think that
can be done.
-=-=-
Let's see ... MicroSoft says the NSAKEY is a "backup."
Backup for what?
The key is used by two entities. MicroSoft (with the private key) for
signing and the user for verifying certificates.
Is it a backup for the user (in case the original key is corrupted)?
Hardly. It would only be useful if MicroSoft signed each certificate
with both keys as a general policy so that the second key could be used.
Further, a backup copy of the primary key (which each has on the
installation disks) serves better.
Is it a backup for MicroSoft? If so, why?
In case they lose the primary key?
Backing up the private primary key would be better.
In case the primary key becomes insecure (the private key becomes
known)? That would only work if the primary key could be revoked and the
secondary key used ... however, CAN the primary key be revoked? If so
will installed software work using the primary key certificate or will
it stop working?
This is a possibility ... if the primary key can be revoked by using the
secondary key it may be a way to disable parts of the OS.
But as a backup for access in case they lose the private primary key?
Hardly.
=====
MicroSoft indicates it was added at the insistence of the government for
export ... and the limitations on export involve limitations on crypto
strength.
MicroSoft claims it is their key (though it is named NSA_KEY) and that
they and only they can sign certificates which it verifies.
There has apparently been no evidence offered for this. It would have
been best had MicroSoft certified their response with this key. If,
indeed the key is an NSA key, it is not likely that the NSA would allow
MS to know the private key. Of course, NSA might be willing to certify
some files for MicroSoft to give the appearance that MicroSoft owns the
key ... but there should be variations (secure servers: user supplied
random data to be certified (after MS checks that this data is not a
routine which would then *have* an MS certificate! but is plain text))
which would offer at least some evidence that MS actually owns (and can
use) this key. MicroSoft did not offer such evidence (and, I still
think, the original response should have been certified by that key ...
it would have been the reasonable thing to do to offer evidence that it
is, indeed, an MS key).
They should offer evidence that they CAN use this key.
---
More likely:
Suppose it IS an MS key (rather than one owned by the NSA) ... if it is
not a "backup" for MS or the user, for whom is it a backup? I would
suggest it is a backup for the NSA even if they do not (yet) own it.
Scenario:
Developing WinNT. Recognition that at some time in the future, under
some law (which may not exist yet) or some pressure, MicroSoft may be
forced to grant access to the OS at the level of allowing the
government to certify routines. What will they then do? Give the
government their key? Hell, no!! Let's be prepared (as all good boy
scouts would be) and prepare a key which we can give to the gov't *if*
it should become necessary or expedient without having to give up our
primary key.
In this scenario ... both those who suspect the worst and those who
trust MicroSoft are right.
The key is a government key ... but not given to the government -yet-
(those with suspicions are correct).
It is, now, a key known only to MicroSoft and the government does not
know it (MicroSoft's response is true).
If this is a "backup" key it is a key to provide certification features
without having to use (or know) the primary, MicroSoft key. As a backup
to the ability to provide certification, this does not make sense (one
could backup the primary key).
As a backup to avoiding the use of the primary key, it makes sense.
MicroSoft *can* use the primary key. As a key which can be given away
without divulging the primary key, it makes sense. MicroSoft indicates
that the key was installed at the request of the government.
If this key is indeed a backup to providing certification authority to
someone to whom the primary key is not to be divulged, what is a
reasonable hypothesis as to who this third party is, even without
knowing the key name?
While it may not (yet) be a "government access" key, it really sounds
like a key prepared for a worst case scenario where MicroSoft *would* be
compelled to grant government access to the OS.
The question then becomes:
Is this good or bad?
Recognizing the the government may have legal authority at some time in
the future to gain access to the OS at the certification level, what
*would* be a prudent action for a company to take?
One would hope the company would not, without the enactment of
legislation requiring it, cede such access. But would it not be prudent
to prepare for the possibility that such legislation might be enacted?
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: hash function ?
Date: Mon, 06 Sep 1999 12:28:05 GMT
In article <[EMAIL PROTECTED]>,
Stefan Hetzl <[EMAIL PROTECTED]> wrote:
> Hi all,
>
> I want to use a passphrase of any length as a key for the blowfish
> algorithm. I think it would be more secure to hash the passphrase
first
> because in a typical passphrase there are probably more alphanumerical
> characters than others, which would make guessing the key easier.
Which
> hash algorithm would be suited best to do this / is the best to use in
> connection with blowfish ?
I personally recommend HAVAL. It is highly configurable and hasn't been
broken yet, unless I'm wrong. <insert contradictory statement here>
Anyway, HAVAL can product hashes of 128, 160, 194, 224, and 256 bits as
well as using 3, 4, or 5 passes to hash the information. It just
depends on your security needs. If you want to get sneaky, you could
have part of your key be the hash size and the number of passes. The
only others I'd recommend are SHA-1 and TIGER.
> I will probably also use this hash algorithm to derive a 32bit seed
for
> a random number generator from a passphrase. Which bits should I use ?
> The first 32, last 32 etc. ?
As far as I know, it doesn't matter. Of course, I'd probably make my
own compression function to get the 32 bits rather than waste a hash.
Casey
>
> Thanks,
>
> Stefan
>
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED] (JPeschel)
Subject: Re: point of a cipher
Date: 06 Sep 1999 13:49:41 GMT
[EMAIL PROTECTED] writes in part:
> How about SIN for a "Scott Intergrated Network"
>I like the sound of that better and it uses a 3 letter
>abreviation so poopular with NSA,FBI,CIA,KGB,NIS, and etc
>types.
And it even spells something!
Joe
__________________________________________
Joe Peschel
D.O.E. SysWorks
http://members.aol.com/jpeschel/index.htm
__________________________________________
------------------------------
From: Alan Braggins <[EMAIL PROTECTED]>
Subject: Re: NSA and MS windows
Date: 06 Sep 1999 14:45:53 +0100
[EMAIL PROTECTED] (Bruce Schneier) writes:
> >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.
Not all implementations that use CryptoAPI have to be "fully MS made
security systems", it's just that their crypto components have to have
been signed by Microsoft (once the supplier has promised not to export
them to us evil furriners).
------------------------------
From: Geoff Thorpe <[EMAIL PROTECTED]>
Subject: Re: CryptoAPI
Date: Mon, 06 Sep 1999 14:57:54 +0100
Hi there,
> To be fair to Microsoft, I am sure that did not have any choice about this.
But they did have a choice about the API, in particular the ability to
retrieve a private key without specifying a passphrase. I believe it's
mentioned on http://www.cs.auckland.ac.nz/~pgut001 somewhere.
I'd use it (CryptoAPI) if I wanted to write a trojan ... but not for
much else.
Cheers,
Geoff
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: point of a cipher
Date: Mon, 06 Sep 1999 13:12:02 GMT
In article <7qveqn$35vo$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (SCOTT19U.ZIP_GUY) wrote:
> In article <7quh4a$pos$[EMAIL PROTECTED]>,
>[EMAIL PROTECTED] (David Wagner) wrote:
> >In article <o1oA3.21146$[EMAIL PROTECTED]>,
> >Richard Parker <[EMAIL PROTECTED]> wrote:
> >> David Scott is using "w-pcbc" as an all-or-nothing transform (AONT).
> >
> >I disagree. An AONT transform is unkeyed, and does not itself provide
> >confidentiality. Rather, David Scott is using "w-pcbc" as a block cipher
> >structure (think of it as an alternative to the Feistel structure).
>
> How can you disagree when ever we start to get technical on my method
> you say that you can't follow the C code since the source is appearently
> encrypted to hard for you. Since this is true based on your last comments
> when the Slide Attack failed against it. How do you know that it is not
> "all or nothing".
Think of
Ci = Pi xor S[Ci-1 xor Pi-1]
(or whatever it is)
as your block cipher, you just happend to be running this in w-pcbc mode.
Your actual cipher though is the line above (or whatever it resembles).
You could just as easily run DES in w-pcbc mode as well.
Tom
--
damn windows... new PGP key!!!
http://people.goplay.com/tomstdenis/key.pgp
(this time I have a backup of the secret key)
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: Geoff Thorpe <[EMAIL PROTECTED]>
Subject: Re: Schneier/Publsied Algorithms
Date: Mon, 06 Sep 1999 15:10:23 +0100
Hi there,
> properly on your machine. Once in memory, the code is easily altered by a trojan
>inserted by Back Orifice or by other surreptitious means. The PC is not
> secure, ergo code running on a PC is not secure. The only secure encryption is
>harware encryption.
Wrong. The above is deduced from the PC being insecure. Make the PC
secure and you don't have a problem, trust potentially insecure hardware
and you do have a problem. Hardware encryption is just software running
a server in a different process on a different OS on a different machine
on a different network interface. If you're running a decent operating
system, then doing the same in a different process under different user
priviledges is just a more convenient method for doing the same job. Now
for acceleration ... then dedicated hardware can start to come in handy
- but it's simply not true that hardware crypto is the only solution to
weakling operating systems.
BTW: Do any hardware crypto vendors actually publish the source code to
their micro-controller OSs? My PC operating system comes with source.
Cheers,
ME
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: point of a cipher
Date: Mon, 06 Sep 1999 15:06:31 GMT
In article <7r0eir$kje$[EMAIL PROTECTED]>, Tom St Denis <[EMAIL PROTECTED]> wrote:
>In article <7qveqn$35vo$[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY) wrote:
>> In article <7quh4a$pos$[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] (David Wagner) wrote:
>> >In article <o1oA3.21146$[EMAIL PROTECTED]>,
>> >Richard Parker <[EMAIL PROTECTED]> wrote:
>> >> David Scott is using "w-pcbc" as an all-or-nothing transform (AONT).
>> >
>> >I disagree. An AONT transform is unkeyed, and does not itself provide
>> >confidentiality. Rather, David Scott is using "w-pcbc" as a block cipher
>> >structure (think of it as an alternative to the Feistel structure).
>>
>> How can you disagree when ever we start to get technical on my method
>> you say that you can't follow the C code since the source is appearently
>> encrypted to hard for you. Since this is true based on your last comments
>> when the Slide Attack failed against it. How do you know that it is not
>> "all or nothing".
>
>Think of
>
>Ci = Pi xor S[Ci-1 xor Pi-1]
>(or whatever it is)
>
>as your block cipher, you just happend to be running this in w-pcbc mode.
>Your actual cipher though is the line above (or whatever it resembles).
>
>You could just as easily run DES in w-pcbc mode as well.
Yes you could easly run any block cipher in the w-pcbc mode.
Tom here is another way to look at it.
If you use DES or any short block cipher and wanted to encrypt
so that you don't change the file length.
And if you send many messages with the same key (salt or pepper them
if it makes you happy) IF the enempy is trying a plaintext attack or has one
set of plaintext and encrypted messages. He has many input output pairs
of data that was used with the cipher. Know he can use these pairs of data
to get the key ( you favoriute approach is the brute force search) or possible
use some whiz bang NSA method to use these pairs of data to magically
create the key. I don't know for sure if the NSA (or CHINCESE since bill gives
them everything) can use this data for the particulare method you choose
but I know from an information point of view that data is all they need and if
they are smart they can break it since it is ALL they need. What I have
said is true for every 3-letter chaining method the CRYPTO GODS have
duped people to use. Maybe they are under pressure from the government
to encourage such poor encryption practices I don't know.
If you sent the same message with W-PCBC not only would the messages
be the some lenght (unless you add random padding) so that adding special
headers to the message as in PGP would be avoided. But even if the enemy
had messaages you sent to me both in encrypted and plain text form. It
is a much harder job to even get any input output paris of data so that it
could use its whiz bang method of breaking DES or whatever.
Let me state it again since you really seldom read what I write.
If you use blessed chaining you supply many input out pairs for the people
who want to read your messages. If you use w-pcbc they have a much harder
time getting the input ouput pairs of data that went with the underlying block
cipher.
Even if the used the Famout Slide Attack on you w-pcbc what are they getting
with all the work. They might gett after many messages if you fo this for them
a few input output pairs for the underlying block cipher. This is a lot of
work. If you use a 3-letter chaining method you give the input out piars of
there choice with only one choosen plain text file. I hope you read and
inderstand what I said.
But before you go off in never never land. Yes this is for a whole file and
not a running stream of live real time data. Unless you buffer the blocks
up and call some fixed length the whole file. And yes it is slower than
the others. But it is not as weak.
Know if one
>
>Tom
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] (SCOTT19U.ZIP_GUY)
Subject: Re: point of a cipher
Date: Mon, 06 Sep 1999 14:33:32 GMT
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
(JPeschel) wrote:
>[EMAIL PROTECTED] (SCOTT19U.ZIP_GUY) writes:
>
>>In article <7quh4a$pos$[EMAIL PROTECTED]>,
>>[EMAIL PROTECTED] (David Wagner) wrote:
>>>In article <o1oA3.21146$[EMAIL PROTECTED]>,
>>>Richard Parker <[EMAIL PROTECTED]> wrote:
>>>> David Scott is using "w-pcbc" as an all-or-nothing transform (AONT).
>>>
>>>I disagree. An AONT transform is unkeyed, and does not itself provide
>>>confidentiality. Rather, David Scott is using "w-pcbc" as a block cipher
>>>structure (think of it as an alternative to the Feistel structure).
>>
>> How can you disagree when ever we start to get technical on my method
>>you say that you can't follow the C code since the source is appearently
>>encrypted to hard for you. Since this is true based on your last comments
>>when the Slide Attack failed against it. How do you know that it is not
>>"all or nothing".
>
>D.S., I think D.W. is right.
>
>I think it's a mistake to call W-PCBC an All-Or-Nothing
>Transform. Such a transform, according to Rivest, is
>unkeyed or, at least, not a secret, and is considered
>a step before encryption.
>
>Rivest presented the "All-Or-Nothing" idea as a way to
>strengthen fixed-length ciphers by increasing the work
>factor by 2^20. The ciphers he had in mind were 56-bit
>DES and ciphers that might be encumbered by export
>restrictions. The idea was to foil a brute-force
>search of the keyspace by forcing an attacker to
>decrypt the entire file and not just the first block
>when testing possible keys.
>
>It's true a brute-force search of the keyspace of
>a scott enciphered file would require decryption of
>the entire file when testing possible keys. The scott
>cipher keyspace, however, is, apparently, so big that
>the W-PCBC doesn't seem at all what Rivest had in mind.
>
>Rivest also contended that an All-or-Nothing Transform
>provided protection against chosen-plaintext attacks.
>An earlier version of scott16 used W-PCBC, but that
>cipher was broken by a chosen-plaintext attack.
Actually the method that Mr Onions exposed was not
W-PCBC if you remember it was the first encryption program
that I put on the net. It handled odd length and even lenth files
different. And Mr Onions was the first to convence me that it
might be wise to make it immune to "choosen file-plaintext
attack". There are at least 2 classes of plain text attacks
when where you get the enemy to slip in a line of text or something
buried in a message. An another where you get the enemy to
encrypt a whole particular file. Mr Onions was of the whole file
type. Most block ciphers that have a small block size and weak
short keys can be attacked by the slipping in of the choosen
fragment of a file. Most ciphers that get broken get broken becasue
of weakness like common streches of plain text in there messages.
Since even the old scott16 treated the file as a whole block even
it appeared immune to thid kind of partial plaintext attack.
>
>So I think it is better to think of W-PCBC (all 17
>passes in scott16x, anyway) not as a mode of
>operation, but as an integral part of the encryption
>mechanism, or, as Wagner suggests, an alternative
>to a Feistel network.
>
>You could call it a Scott Network.
How about SIN for a "Scott Intergrated Network"
I like the sound of that better and it uses a 3 letter
abreviation so poopular with NSA,FBI,CIA,KGB,NIS, and etc
types.
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
------------------------------
** 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
******************************
