Cryptography-Digest Digest #223, Volume #11 Tue, 29 Feb 00 19:13:02 EST
Contents:
Re: Status of alleged *THIRD* key in MS Crypto API ? (David A. Wagner)
Re: CRC-16 Reverse Algorithm ? (Terry Ritter)
Re: How do I get the key from the passphrase in DES? (David A. Wagner)
Re: NSA Linux and the GPL (David A. Wagner)
Re: CRC-16 Reverse Algorithm ? (David A. Wagner)
Making a small language mistake with the word "Asia" .. you get ("Markku J.
Saarelainen")
Re: Ciphering = deciphering; is this a weakness? ([EMAIL PROTECTED])
Re: IDEA question. (Chris DiTrani)
Re: Can someone break this cipher? (JPeschel)
Some of the best security intelligence books that I have read are : 1. Holy Bible,
2. The Torah, 3. The Koran and 4. Thus Spoke Zarathustra ... it is all about a mind
... my dear love ... (John Underwood)
Re: Passwords secure against dictionary attacks? ("Gordon LaVere")
Re: On jamming interception networks ([EMAIL PROTECTED])
Re: Want to poke holes in this protocol? (Xcott Craver)
Re: Best language for encryption?? ("Adam Durana")
Re: Can someone break this cipher? ([EMAIL PROTECTED])
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (David A. Wagner)
Subject: Re: Status of alleged *THIRD* key in MS Crypto API ?
Date: 29 Feb 2000 13:29:59 -0800
In article <[EMAIL PROTECTED]>,
Stephen Houchen <[EMAIL PROTECTED]> wrote:
> > Naah. See Bruce Schneier's essay on the topic for an example of a more
> > reasoned refutation. (Still, the most extreme claims *were* pretty loony.)
>
> Where can this essay be found?
His Crypto-Gram newsletter. See
http://www.counterpane.com/crypto-gram.html
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: CRC-16 Reverse Algorithm ?
Date: Tue, 29 Feb 2000 22:14:02 GMT
On 29 Feb 2000 12:50:00 -0800, in
<89hbdo$8d9$[EMAIL PROTECTED]>, in sci.crypt
[EMAIL PROTECTED] (David A. Wagner) wrote:
>In article <[EMAIL PROTECTED]>, Terry Ritter <[EMAIL PROTECTED]> wrote:
>> Are you now saying that if, mid operations, the CRC register has some
>> particular state, it will not detect extra 1's? While that may be an
>> interesting idea, it is a completely different issue.
>
>Yup.
>
>But this state I'm describing, in some vague sense that I don't know how
>to put my finger on, feels like "just" a renaming of the all-ones state.
>
>In other words, I *suspect* that, no matter which configuration of CRC you
>use, there will usually be some initial state which doesn't detect leading
>ones. The exact value of that initial state depends on the configuration.
>If you pick one particular configuration, that bad initial state is all-ones;
>if you pick another one, that bad initial state is something else.
>
>But I don't have any evidence for this. These are just squishy, unscientific,
>unproven, groundless guesses.
This just doesn't make any sense to me. We don't pick just any random
initial state for CRC's. In data communications at least, both ends
have to pick the same starting state. In general, that starting state
is all-ones, which does detect both leading zeros and ones.
The first uses of the first-generation 16-bit CRC's were initialized
to all-zeros, so a zeros init might have some support. But I am aware
of no support for a random initialization value.
So even if the guess is true, it simply has nothing to do with real
CRC initialization. It is a theoretical problem which never arises
because we have a standard init value which does not do that.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
From: [EMAIL PROTECTED] (David A. Wagner)
Subject: Re: How do I get the key from the passphrase in DES?
Date: 29 Feb 2000 13:48:12 -0800
In article <[EMAIL PROTECTED]>,
John Savard <[EMAIL PROTECTED]> wrote:
> "Amit IG" <[EMAIL PROTECTED]> wrote, in part:
> >I want to know the technique used for deriving the 64-bit key from an
> >arbitrary length passphrase. The key is then used in DES.
>
> As noted in other replies, there is no standard technique for doing so.
Well, SHA1-hashing the key is quite standard.
> One technique that can be used is as follows:
>
> 1) Append a 1 bit to the end of the pass phrase.
>
> 2) Append as many 0 bits to the end of the pass phrase as required to
> make it 8 more than a multiple of 56 bits in length.
>
> 3) Take the first 64 bits of the result, and subject it repeatedly to
> the following operation, once for each remaining 56 bits in the padded
> pass phrase:
>
> Take the 64 bit value, encrypt it using the 56 bits from the pass
> phrase as the key, and then XOR the 64 bit value used as input to DES
> with the output from this DES encryption.
>
> 4) Convert the 64 bit result to a DES key in standard format by
> replacing the _least significant_ bit of each byte by the value
> required to give that byte odd parity.
Note that this hash is not one-way, in the following sense: if the adversary
learns the resulting DES key in some way, he may be able to figure out your
passphrase more efficiently than you'd expect from it.
(Consider a 120-bit passphrase <P1,P2>: we use K = DES(P1,P2) as our DES key.
But if K is known, we can exhaustively search over the possibilities for P1
-- many fewer than 2^56 possibilities, since this is part of a passphrase --
and then check whether P2' = DES-decrypt(P1,K) looks like a plausible second
half of a passphrase.)
Whether this property is relevant will depend on the application; but a nice
feature of SHA-hashing is that you don't have to worry about whether the
lack of one-wayness introduces any weaknesses, because SHA1 is (believed to
be) one-way.
------------------------------
From: [EMAIL PROTECTED] (David A. Wagner)
Subject: Re: NSA Linux and the GPL
Date: 29 Feb 2000 13:59:24 -0800
In article <[EMAIL PROTECTED]>,
Douglas A. Gwyn <[EMAIL PROTECTED]> wrote:
> But the issue is whether the DCI could be successfully prosecuted
> for "removal" of the classified information, when he is the one
> who is authorized to designate the appropriate storage.
The Inspector General's report
http://www.fas.org/irp/cia/product/ig_deutch.html
discusses this issue in some length, although definitive conclusions
appear to be lacking.
The report also points out (if I understand correctly) that some
of the allegedly violations apparently occurred after Deutch stepped
down as DCI, when presumably he would no longer have authority to
designate appropriate storage.
It also quote some legal types as being skeptical of a related line
of argument (that a DCI cannot be prosecuted because they have authority
to declassify material). It's not clear to me that they came to any
consensus, but here is one example quote from the report that raises
an interesting point on the subject:
``the OPS Legal Advisor said that DoD material and
Top Secret/[the non-CIA controlled compartmented program]
material would not qualify for information a DCI had the
authority to declassify.''
I don't know whether this point is relevant to the issue of who is
authorized to designate appropriate storage, and how.
All in all, the situation appears somewhat murky.
------------------------------
From: [EMAIL PROTECTED] (David A. Wagner)
Subject: Re: CRC-16 Reverse Algorithm ?
Date: 29 Feb 2000 14:07:57 -0800
Ok. It sounds like you are saying that noone ever uses any of the CRC
configurations that could have a problem with the all-ones initialization
state. Good.
Sorry for the confusion. It was my fault. Thanks for explaining.
------------------------------
From: "Markku J. Saarelainen" <[EMAIL PROTECTED]>
Subject: Making a small language mistake with the word "Asia" .. you get
Date: Tue, 29 Feb 2000 22:46:02 GMT
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Ciphering = deciphering; is this a weakness?
Date: 29 Feb 2000 22:48:36 GMT
In a previous article, <[EMAIL PROTECTED]> writes:
>> E(E(m;k) ;k) =3D m
---snip---
>My guess is that the effective key length is maybe cut in half. maybe
someone
>else has other guesses.
Not exactly, but that depends on what you compare with. Mathematically
speaking such ciphers are permutations composed of cycles consistently with a
length of two. You get the number of such permutations (of blocks of bit
length n) by dividing the total number of permutations (of blocks of bit
length n) by 2**(n/2). This does not diminish the cardinality of the set of
theretically possible ciphers as much as a halving of the block size would.
You would e.g. need at least a 1684-bit key to exploit every possible
substitution cipher on 8-bit blocks, and at least a 1556-bit key to exploit
every reciprocal substitution cipher on the same block size.
Note: 1684 is the smallest integer larger than log2(256!), and 1556 is the
smallest integer larger than log2(256!*(2**-128)).
----- Posted via NewsOne.Net: Free Usenet News via the Web -----
----- http://newsone.net/ -- Discussions on every subject. -----
NewsOne.Net prohibits users from posting spam. If this or other posts
made through NewsOne.Net violate posting guidelines, email [EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (Chris DiTrani)
Subject: Re: IDEA question.
Date: Tue, 29 Feb 2000 21:59:33 GMT
On Tue, 29 Feb 2000 20:38:40 GMT, [EMAIL PROTECTED] wrote:
>In article <[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] (Chris DiTrani) wrote:
>> I wrote a little utility to en/decrypt files using IDEA, building the
>> encryption key from a user provided pass phrase. In order to confirm
>> that a file is being decrypted with the correct pass phrase, I encrypt
>> a block containing known (but not secret) data and append it to the
>> file before encrypting the file (so this block is encrypted twice). I
>> can look at the block after decrypting the file to confirm (to some
>> certainty). My question is, am I appreciably weakening the encryption
>> with this approach? Is there a better way?
>>
>What kind of information is in the block of known information that
>you're first encrypting?
>
>csybrandy
>
Currently it's {3, 4, 19, 66}, but I can make it anything.
CD
------------------------------
From: [EMAIL PROTECTED] (JPeschel)
Subject: Re: Can someone break this cipher?
Date: 29 Feb 2000 23:03:26 GMT
[EMAIL PROTECTED] writes, in part:
>In a previous article, <[EMAIL PROTECTED]> writes:
>>If you mean the ciphertext is truly random, I think you
>>have said the thing that cannot be.
>
>I would not say that. It is actually quite simple to generate a truly random
>cipher:
>
>1. Burn a CD-R filled with random data. Use this as a key.
Your key, not the cipher, is truly random.
>3. Now the agent only has to scramble the (presumably short) plain text
>messages he has to send to the home office by xor-ing them with random data
>from the CD-R.
After a message is XORed with the random data from the CD, the message
may look truly random, but it isn't. If the message were truly random, it
could not be decrypted.
Joe
__________________________________________
Joe Peschel
D.O.E. SysWorks
http://members.aol.com/jpeschel/index.htm
__________________________________________
------------------------------
From: John Underwood <[EMAIL PROTECTED]>
Crossposted-To:
alt.politics.org.cia,alt.2600,alt.security,soc.culture.russian,comp.security.misc,alt.security.cointel,fido7.security,comp.security.pgp.discuss
Subject: Some of the best security intelligence books that I have read are : 1. Holy
Bible, 2. The Torah, 3. The Koran and 4. Thus Spoke Zarathustra ... it is all about a
mind ... my dear love ...
Date: Tue, 29 Feb 2000 18:55:44 +0000
On Tue, 29 Feb 2000 at 17:50:00, Markku J. Saarelainen
<[EMAIL PROTECTED]> wrote in comp.security.pgp.discuss:
(Reference: <[EMAIL PROTECTED]>)
>
>
A very good way of ensuring that people don't read what you write it to
put the entire content of your message in the subject header. In this
case, some might think that was a very good thing to do.
--
John Underwood
------------------------------
From: "Gordon LaVere" <[EMAIL PROTECTED]>
Crossposted-To: comp.security.misc,alt.security.pgp
Subject: Re: Passwords secure against dictionary attacks?
Date: Tue, 29 Feb 2000 23:26:35 GMT
Is there a program maybe a hash oprogram that would take my 8 or more letter
plain text pass phrase and give me a suitable. Truly random pass word.
I could remember mary had a little lamb. Then I got " $r9,e>iwlu". IT
would repeat the process
the same each and every time. Hmmmmmm I supose the bad guy could get the
same program and try all
of the words . . How would he know when he hit the right combination ?
Since he world never see
$r9,e>iwlu. Is just my simple mind or could SH-1 do that?
e n t r o p i c <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> On Tue, 22 Feb 2000, Ilya <[EMAIL PROTECTED]> wrote:
>
> >Is it secure to take two words and join them together, such as:
> >
> >crypto/life cyber@machine green-dog Loud!Music
>
> A more secure method is described in the Diceware FAQ:
>
> How can I use Diceware to make up a login password?
>
> One way is to select two words using diceware. Then select a special
> character using the chart below. Then stick the special character
> between the two words instead of a space. Drop characters off the end
> of the second word if the resulting password is too long for your
> computer system. (Most Unix systems limit you to 8 characters, for
> example.)
>
> Example:
>
> base<threw which truncates to the 8 character password base<thr
>
> --
> e n t r o p i c
> on the brink of the dot com generation
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: On jamming interception networks
Date: Tue, 29 Feb 2000 23:19:39 GMT
In article <
[EMAIL PROTECTED]
ing.com>,
Jerry Coffin <[EMAIL PROTECTED]> wrote:
> In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
> says...
>
> [ ... ]
>
> > Certainly, where good targets can be located, it would be a folly
> > to ignore these and instead either look at everything or randomly
> > pick a certain percentage of the whole traffic. Such targets are
> > certainly followed with priority. But besides these definitely
> > interesting targets it is evidently a reasonable strategy to also
> > look at some of the rest materials as long as the resources permit.
> > (Why let machines be idle sometimes and not run to their full
> > capacity?)
>
> Given economic realities, the question is NOT whether you let
> machines sit idle, or use them to look at randomly selected garbage.
> It's whether you can manage to hit the 10% of the most important
> targets, or only 5 or even 1%.
>
You are correct because the NSA, for example,
has a recognized shortage of quality analysis.
They failed to detect ahead of time the
nuclear tests of India and Pakistan and I feel
sorry for them now that they will have to face
the proliferation of fiber optic networks.
> > I am not considering any particular national agency. If anything,
> > I am considering machineries on the scale of the legendary Echelon,
> > which is an multi-national project.
>
> This makes only a little difference: multiplying the budget size by
> 10 or even 100 or 1000 STILL leaves it in the situation of only being
> able to do useful monitoring of quite a small percentage of the most
> important communications.
>
> --
> Later,
> Jerry.
>
> The universe is a figment of its own imagination.
>
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (Xcott Craver)
Subject: Re: Want to poke holes in this protocol?
Date: 29 Feb 2000 23:29:42 GMT
Johan Hoogenboezem <[EMAIL PROTECTED]> wrote:
>Hi Everyone,
>
>Would some of you please help me to poke holes in this scenario?
[protocol]
Yikes!!!
The first attack that comes to mind: an attacker spies on Alice's
transmission, records the whole thing, and then "plays it back" later,
pretending to be Alice. Whatever Alice did during that session is performed
a second time. If Alice made a transfer of funds to Carl, Carl could
reperform the transfer 100 times, take the money and run.
The problem is that the bank has no say in the construction of the
random session key; if both sides generated a random key, the session
key being a hash of their concatenation, this could be avoided.
In fact, with the right analysis of the traffic, Carl could isolate
specific commands. If the symmetric crypto uses chaining throughout
the entire session, however, this is avoided too.
Lemme think about it some more; I'll tell you if I see anything
really dangerous.
>Johan
-Xcott
------------------------------
From: "Adam Durana" <[EMAIL PROTECTED]>
Subject: Re: Best language for encryption??
Date: Tue, 29 Feb 2000 18:50:47 -0500
> Surely, as I eventually work with your algorithm, I will see what you have
> done in C, write it in C myself, and also do it in BASIC. The big
> advantage of how I do things in BASIC is in the GUI I use. I tend to
> convert numbers to compressed strings, and work with them that way, but I
> can set the math to bigger ranges with compiler options.
BASIC is great for learning structured programming, but no one should
consider using it for applications where speed is an issue. I've always
thought of it this way, the easier it is for a human to understand the code
the slower it will run on a computer. If you could program in machine
language your program would be the fastest possible, assuming you know what
you are doing. Now each step you take away from the actual bits, that get
fed to the computer to tell it what to do, the slower the program will run.
Say with C, the compiler has to interpret your code and figure out what you
are doing and convert that into machine language. Since the compiler is a
program its going to follow a certain set of rules, so there might be other
possibilities that the compiler does not choose where it would be faster.
Now take BASIC it is even easier for people to understand that C is, so the
programmer won't be getting down into the finer details of how the program
runs, so BASIC will be even slower than C. I hope you see what I mean. To
make a programing language easy to understand the more things the compiler
has to take care of, so the programmer does not have to be bothered with
those details, and since the compiler follows strict rules, it can not come
up with more optimized ways of doing things. As for dealing with numbers in
'compressed strings', all you are doing is dealing with the data in a
different format, all programmers do this. ie, a long variable in C,
consists of 4 bytes, or you could look at it as a string of length 4.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Can someone break this cipher?
Date: 29 Feb 2000 23:51:52 GMT
In a previous article, <[EMAIL PROTECTED]> writes:
>[EMAIL PROTECTED] writes, in part:
>>1. Burn a CD-R filled with random data. Use this as a key.
>
>Your key, not the cipher, is truly random.
You are wrong. Naturally, I meant that you should use all bytes on the CD in
succesion and each byte only once.
Consequently, for each cipher c and any possible message m of the same length
as c, there will always be a possible key k that match the pair c and m,
namely k = c xor m. This is the maximum degree of entropy that is
theoretically possible.
>After a message is XORed with the random data from the CD, the message
>may look truly random, but it isn't. If the message were truly random, it
>could not be decrypted.
Yes, it could. All you have to do is to generate the random number sequence in
advance, store it and give one copy to each party. It would of course be
impossible to generate the same sequence again, but once you have stored it
you do not have to.
----- Posted via NewsOne.Net: Free Usenet News via the Web -----
----- http://newsone.net/ -- Discussions on every subject. -----
NewsOne.Net prohibits users from posting spam. If this or other posts
made through NewsOne.Net violate posting guidelines, email [EMAIL PROTECTED]
------------------------------
** 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
******************************
