Cryptography-Digest Digest #188, Volume #11      Wed, 23 Feb 00 17:13:02 EST

Contents:
  Re: NSA Linux and the GPL ("Douglas A. Gwyn")
  Re: Passwords secure against dictionary attacks? ([EMAIL PROTECTED])
  Re: The solution is Open Source! (Paul Schlyter)
  SAC 2000 Call for Papers (Stafford Tavares)
  Re: Question about OTPs (Bryan Olson)
  Re: Passwords secure against dictionary attacks? ("Ken Hagan")
  Re: Processor speeds. ("Clockwork")
  Re: The solution is Open Source! (Mike McCarty)
  Compression in the Real World ([EMAIL PROTECTED])
  Re: Does the NSA have ALL Possible PGP keys? (Mike McCarty)
  Re: Passwords secure against dictionary attacks? (Alun Jones)
  Re: Passwords secure against dictionary attacks? (Peter Berlich)
  Re: Passwords secure against dictionary attacks? (Alan J Rosenthal)

----------------------------------------------------------------------------

From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: NSA Linux and the GPL
Date: Wed, 23 Feb 2000 19:15:21 GMT

"John E. Kuslich" wrote:
> Why is has John Deutch not been arrested and charged with violations
> of the law regarding care of classified information?????????

To what "law" are you referring?  We have laws about espionage and
sedition, but no Official Secrets Act.

I agree that it was a terrible, inexcusable mistake, and should
keep anyone from ever again putting Deutsch in a position of trust,
but I don't see how he can be punished under the law.

------------------------------

From: [EMAIL PROTECTED]
Crossposted-To: comp.security.misc,alt.security.pgp
Subject: Re: Passwords secure against dictionary attacks?
Date: Wed, 23 Feb 2000 19:12:00 GMT

QWERTY offsets are not very secure.  A typcial dictionary
attack interation would go:  1) Dictionary, 2) Reverse Dictionary, 3)
QWERTY Offset Dictionary, 4) Alpha offset Dictionary,

If bullwinkle is in my dictionary, interation number 3 would get you.

I used to use QWERTY offsets.  Not any more.

As to the original posting on concatenating dictionary words.  That too
can be weak.  However, since the concatenation permutations far exceed
the QWERTY offset, I would dare say that concatenation is more secure
than QWERTY.



In article <88vpde$s3c$[EMAIL PROTECTED]>,
  "NutWrench" <[EMAIL PROTECTED]> wrote:
>
> Hi Ilya,
>   One way to have a easily-remembered password that defeats dictionary
based
> attacks is to enter your passphrase, but press the key which is above
and to
> the left or right of the actual key. For example, if your password is
> 'bullwinkle', instead of pressing 'b' press 'h' (above and to the
right).
> The typed text for 'bullwinkle' would then be: 'h8pp39jop4'    :o)
>
> --Nut
>
>


Sent via Deja.com http://www.deja.com/
Before you buy.

------------------------------

From: [EMAIL PROTECTED] (Paul Schlyter)
Subject: Re: The solution is Open Source!
Date: 23 Feb 2000 19:07:45 +0100

In article <MaUs4.71$[EMAIL PROTECTED]>,
John E. Kuslich <[EMAIL PROTECTED]> wrote:
> <[EMAIL PROTECTED]> wrote in message news:88ua13$29b$[EMAIL PROTECTED]...
>> In article <88s99s$lhu$[EMAIL PROTECTED]>,
>>   [EMAIL PROTECTED] wrote:
>>
>> How can we be sure our encryption software has no backdoor?
>>
>> The answer, of course is Open Source. There are several free open source
>> encryption packages available, e.g. the java package by www.cryptix.org.
>> The source code for this is available, so anyone with a basic
>> understanding of programming and math can check the code to make sure
>> there are no secret backdoors or key escrow systems.
>>
>> It's free, and you yourself can ensure it's safe! Goodnight NSA...
> 
> The "answer"  you provide is NOT the answer at all.  It is an illusion.
> 
> Suppose you write open source code and everybody agrees that the source code
> is a pure as the driven snow.
> 
> Now you have to compile the sucker, right?  How do you know that the
> compiler you are using is as pure.
> 
> Ok, so you use an open source compiler, right?
> 
> Now you have to compile THAT sucker, right? Well no, some of it is written
> in assembler so we worry about the assembler.
> 
> So we use an open source assembler. Which was compiled by another compiler,
> so let's see we have to check that compiler also....
> 
> Gees, this is starting to be like work...
 
This is no problem really.  Yes, when developing a compiler, you must
during the devlopement phase some time "bootstrap" it by using some
software tool which isn't open source.  But after that, the compiler
might very well be self-compiling, if a suitable language is used,
e.g. C.  OK, you may need to assemble some parts -- but that assembler
can be written in C and assembler too.  So the combination of C compiler
and assembler will form a self-compiling/assembling system.  Then you
have a true open source compiler -- that is, if your linker, librarian
and loader also are open source.
 
 
> But, suppose, through a super human effort, you manage to convince yourself
> that all the tools you use to compile your open source code are pure,
 
Which is faily easily acheived by a self-compiling compiler.
 
 
> you still have a serious problem:
> 
> You have to execute the compiled code on a machine running an operating
> system.
 
OK; then the OS must be open source too -- like e.g. Linux.
 
 
> This O/S will be multithreaded and multitasking so many other
> processes will be running concurrently (within the limits of the meaning of
> concurrency in the O/S context).  Now, suppose one of the loaded libraries
> your code uses has evil code that breaks your security?
 
OF COURSE you should use only trusted libraries here.... i.e. open source
libraries which have been properly examined and found to be safe.
 
> Take Java for instance.  This over hyped language is supposed to "play in
> it's own sandbox". Baloney.  Turn on a debugger and watch the system calls
> Java makes.  You will see standard system code running all over the place.
 
So then don't use Java..... it's got too many security holes anyway.
For instance, there seem to be no way in Java to make sure you overwrite
a variable with sensitive information (e.g. some secret key) after
that information no longer is needed.  So a security application in
Java can, after execution, leave a lot of sensitive information
floating around in free memory...
 
> Calls are made to Winsock for example.  Now think of the potential for
> security violations here.  A trojan placed in the Winsock dll could send
 
OF COURSE you shouln't use Windoze at all if you want a secure system!!!
 
> your plain text to Zanzibar without your knowledge.
 
Yep -- and then you've got what you deserve....
 
> Open source is good for a lot of things, but it does nothing for security.
 
Open source doesn't do EVERYTHING, that's true.  But you're overly
pessimistic if you claim it does "nothing" for security.  If you run
a system which is 100% open source, and which have been properly
examined in its entirety and found to be safe, don't you think such a
system would be safer than e.g.  Micros~1 Windoze?
 
========================================================================
 
But you have a more severe problem: suppose you use an open source
system, and you've examined the source code and found it to be safe.
But you're not the one who compiles the source -- one of your
employer does, and then hands you the binaries.  How can you be sure
he really compiled that examined source code, and not some other
source code?
 
This is really the major vulnerability of secure systems: at some
point, some person(s) must be trusted to know some sensitive
information about the system.  If these trusted people aren't
trustworthy, then the system may soon become very unsafe....
 
-- 
================================================================
Paul Schlyter,  Swedish Amateur Astronomer's Society (SAAF)
Grev Turegatan 40,  S-114 38 Stockholm,  SWEDEN
e-mail:  [EMAIL PROTECTED]    [EMAIL PROTECTED]   [EMAIL PROTECTED]
WWW:     http://hotel04.ausys.se/pausch    http://welcome.to/pausch

------------------------------

From: Stafford Tavares <[EMAIL PROTECTED]>
Subject: SAC 2000 Call for Papers
Date: Wed, 23 Feb 2000 14:27:41 -0500


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%



                                       CALL FOR PAPERS


SAC 2000

Seventh Annual Workshop on Selected Areas in Cryptography

to be held at:

University of Waterloo
Waterloo, Ontario, Canada

Dates: August 14-15, 2000

Co-Chairs:

Doug Stinson,      University of Waterloo
Stafford Tavares,  Queen's University

Workshop Themes:

1.  Design and analysis of symmetric key cryptosystems.
2.  Primitives for private key cryptography, including
    block and stream ciphers, hash functions and MACs.
3.  Efficient implementations of cryptographic systems
    in public and private key cryptography.
4.  Cryptographic solutions for web/internet security.

Program Committee:

D. Stinson     U. of Waterloo, Canada
S. Tavares     Queen's U., Canada
L. Chen        Motorola, U.S.A.
H. Heys        Memorial U. of Newfoundland, Canada
L. Knudsen     U. of Bergen, Norway
S. Moriai      NTT Labs., Japan
L. O'Connor    IBM Zurich
S. Vaudenay    EPFL, Switzerland
A. Youssef     U. of Waterloo, Canada
R. Zuccherato  Entrust Technologies

Instructions for Authors

Submissions must consist of an extended abstract of at most 15
double-spaced pages, clearly indicating the results achieved,
their significance, and their relation to other work in the area.
Authors can either email one copy of a Postscript file to
[EMAIL PROTECTED] or send ten copies of the extended abstract to

SAC 2000
c/o Stafford Tavares
Department of Elect. and Computer Eng.
Queen's University
Kingston, Ontario K7L 3N6
CANADA

Important Dates:

Submission Deadline          May 1
Notification of Acceptance   June 19
Workshop Dates               August 14-15
Deadline for Proceedings     September 18

Proceedings

It is intended that the Proceedings will be published by
Springer-Verlag in the Lecture Notes in Computer Science
(LNCS) Series. In order to to be included in the Proceedings,
papers must be presented at the Workshop. As in previous years,
the Workshop Record will be available to participants during
the Workshop.

For further information contact:

Doug Stinson, University of Waterloo  [EMAIL PROTECTED]
Stafford Tavares, Queen's University  [EMAIL PROTECTED]

Conference web page:

http://www.cacr.math.uwaterloo.ca/conferences/2000/SAC2000/announcement.html






------------------------------

From: Bryan Olson <[EMAIL PROTECTED]>
Subject: Re: Question about OTPs
Date: Wed, 23 Feb 2000 19:25:03 GMT

[EMAIL PROTECTED] wrote:
> Bryan Olson wrote:
> : [EMAIL PROTECTED] wrote:
[...]
> :> It [The OTP] has about the best possible resistance to
> :> cyphertext-only attack, that's all.
>
> : Not so.  The important property of the OTP is "perfect
> : secrecy", and it maintains this property regardless of the
> : attacker's a priori knowledge about the plaintext.
>
> You /appear/, perhaps, to have misinterpreted my "that's
> all" as "that's the only attack it defends against".

Hmmm, I guess I'm still not clear on what you meant. If you
were limiting "attack" to recovery of information, then
specifying ciphertext-only is wrong.  If you were including
forgery, then the claim of best possible resistance is
false.


> The attacker's knowledge of the plaintext influences his
> ability to forge messages, not what information he can
> glean from their cyphertexts.

With known plaintext he can create forgeries of his
choosing.  With ciphertext, he can create possible/probable
falsifications and with no text at all he can create
existential forgeries.  None of those are close to the best
possible resistance.


--Bryan
--
email: bolson at certicom dot com


Sent via Deja.com http://www.deja.com/
Before you buy.

------------------------------

From: "Ken Hagan" <[EMAIL PROTECTED]>
Crossposted-To: comp.security.misc,alt.security.pgp
Subject: Re: Passwords secure against dictionary attacks?
Date: Wed, 23 Feb 2000 19:34:25 -0000

"Michel Dalle" <[EMAIL PROTECTED]> wrote in message
news:890gia$ej8$[EMAIL PROTECTED]...
> Let's say a 'common' dictionary contains 50.000 words.
>
> So, combining two words would take 2.500.000.000 combinations,
> and inserting some non-alphanumeric character would multiply this
> by 32. Of course, this doesn't take into account size limitations etc,
> but let's say we end up with 80.000.000.000 "words".
>
> So, for a fast PC doing about 50.000 crypts per second, it would
> take about 18 days, 12 hours and 27 minutes to walk through the
> dictionary.
>
> Of course, it might be that you'll be using less than 10.000 words,
> which brings the necessary time to 17 hours and 47 minutes...but
> if you use uppercase first letters too, it would take 4 times longer.
>
> So this password scheme isn't as secure as you might think -
> assuming a "would-be attacker" knows the scheme :)
>
> Or is my reasoning/math wrong here ?
>
> Michel.

Thanks. I agree with your reasoning, but would (naturally) choose
numbers that were more favourable to my case :-)

Allowing six or seven digit telephone numbers, or postcodes, raises the
size of the dictionary to between 100K and 1M words. That pushes the
"crack time" up by a factor of around ten. I might be prepared to change
my password every 180 days if I'm able to build it from fairly memorable
elements in the manner described.



------------------------------

Reply-To: "Clockwork" <[EMAIL PROTECTED]>
From: "Clockwork" <[EMAIL PROTECTED]>
Subject: Re: Processor speeds.
Date: Wed, 23 Feb 2000 19:43:30 GMT

"Mike Rosing" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...

> Getting all the development tools you need puts it past the hobby level
> though, and that's why it's mostly just fun to talk about.

I have tons of experience with console systems...  It isn't difficult to
acquire the knowledge and materials you need to develop the "Super Console
Computer" capable of "wildly" outperforming a PC-based, distributed system
with an identical number of components. Although, I must agree that it would
not be in the realm of the average crypto hobbyist.

Traditionally, the technologies contained in these systems are proprietary
and its secrets are guarded.  In the near future, that will change with the
maturation of the Internet and as consoles take on additional role as a PC.
Additionally, these machines sell as inexpensive toys and entertainment
devices all over the world (in virtually every country).  If you need a
super computer, you have the raw materials at your local toy store :)

Clock




------------------------------

From: [EMAIL PROTECTED] (Mike McCarty)
Subject: Re: The solution is Open Source!
Date: 23 Feb 2000 19:31:48 GMT

In article <MaUs4.71$[EMAIL PROTECTED]>,
John E. Kuslich <[EMAIL PROTECTED]> wrote:
)The "answer"  you provide is NOT the answer at all.  It is an illusion.

[snip program build]

)You have to execute the compiled code on a machine running an operating
)system.  This O/S will be multithreaded and multitasking so many other
)processes will be running concurrently (within the limits of the meaning of
)concurrency in the O/S context).  Now, suppose one of the loaded libraries
)your code uses has evil code that breaks your security?

This is untrue, at least in my case. I use MSDOS on my computers at
home. I have no modem on them. Where is the security breach?

[snip]

)Open source is good for a lot of things, but it does nothing for security.

Your reasoning is flawed.

Mike
-- 
----
char *p="char *p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);}
This message made from 100% recycled bits.
I don't speak for Alcatel      <- They make me say that.

------------------------------

From: [EMAIL PROTECTED]
Subject: Compression in the Real World
Date: Wed, 23 Feb 2000 19:39:39 GMT

There has been a lot of discusion about 1-1 Hufman compression and how
it would increase the entropy before encryption .

Sometimes you need real compressors.  Lets assume I have a 100 page word
document which I want to compress and encrypt.  If I dont compress it it
will take take about an hour to transmit ( 1 page of word doc is 40
KBytes  at 5Kb/s sustained connection ).

Working with large documents,  100-500 pages requires real compressors.

I remember meeting the CEO of an Imaging company in San Jose way back in
the 80īs (forgot the name of the co.  Viacom?...I think it merged with
I2S, Int. Imaging Systems),  he claimed he had a text compression system
with a 100:1 compression ratio...and he was an expert in the field..

And what happened to Compression Labs...they had pretty good imaging
compression technology.


It seems that no real discusion has taken place of encypting large text
files . Emails and small messages are a piece of cake.  If you are an
insurance company or a pharmaceutical company,  and you have to transmit
1000īs of pages then real compression is a must.


Sent via Deja.com http://www.deja.com/
Before you buy.

------------------------------

From: [EMAIL PROTECTED] (Mike McCarty)
Crossposted-To: comp.security.pgp,misc.survivalism
Subject: Re: Does the NSA have ALL Possible PGP keys?
Date: 23 Feb 2000 19:47:44 GMT

In article <890i84$[EMAIL PROTECTED]>, csabine <[EMAIL PROTECTED]> wrote:
)Mmmm
)Lets assume for a moment that tiwolf is correct. The government do know all
)the codes and every bit of conversation that is carried out around the
)world. In this 'tiwolf' universe:
)
)All the mafia warlords have been locked up.
)All the drug dealers have been dealt with.
)80% of 'intents to murder' have have been pre-empted.
)All child pornographers have been exposed.
)Blackmailers have been thrown in jail.
)Extortionists have been ex-communicated.
)etc, etc

No, in this world

        the criminals are in charge of the government and no one has
        any freedom

Come to think of it, this sounds like the world we live in.

-- 
----
char *p="char *p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);}
This message made from 100% recycled bits.
I don't speak for Alcatel      <- They make me say that.

------------------------------

From: [EMAIL PROTECTED] (Alun Jones)
Crossposted-To: comp.security.misc,alt.security.pgp
Subject: Re: Passwords secure against dictionary attacks?
Date: Wed, 23 Feb 2000 21:12:36 GMT

In article <[EMAIL PROTECTED]>, JimD wrote:
> On Wed, 23 Feb 2000 09:09:26 -0000, "Steve Coath" <[EMAIL PROTECTED]> wrote:
> >In a previous job I used to handle some extremely classified material. Our
> >passwords used to be randomly generated for us every week and usually took
> >the form of a jumbled mass of random letters, numbers and characters.
> >You could end of with something such as : Az\\-+.tdhB*
> >Extremely difficult to guess, but also extremely difficult to remember. So
> >everyone used to write them down and keep them in their pockets.
> 
> No wonder the Chinese got hold of your weapons secrets.

Known for their pickpocketing skills, those deviously clever Chinese :-)

Seriously though, this is often a failing of security policies - make your 
security policy unwieldy and difficult to implement, and you run the risk 
that your users will find their own ways to subvert it.  I remember one 
'secured' lab where all occupants shared the same password (for different 
user names) and had written it on a piece of masking tape stuck to the top 
of the monitor.

Alun.
~~~~

--
Texas Imperial Software | Try WFTPD, the Windows FTP Server. Find it
1602 Harvest Moon Place | at web site http://www.wftpd.com or email
Cedar Park TX 78613     | us at [EMAIL PROTECTED]  VISA / MC accepted.
Fax +1 (512) 378 3246   | NT based ISPs, be sure to read details of
Phone +1 (512) 378 3246 | WFTPD Pro, NT service version - $100.
*WFTPD and WFTPD Pro now available as native Alpha versions for NT*

------------------------------

From: Peter Berlich <[EMAIL PROTECTED]>
Crossposted-To: comp.security.misc,alt.security.pgp,comp.security.misc
Subject: Re: Passwords secure against dictionary attacks?
Date: Wed, 23 Feb 2000 23:01:10 +0100

Alun Jones wrote:
> In article <[EMAIL PROTECTED]>, JimD wrote:
>> On Wed, 23 Feb 2000 09:09:26 -0000, "Steve Coath" <[EMAIL PROTECTED]> wrote:
>>> You could end of with something such as : Az\\-+.tdhB*
>>> Extremely difficult to guess, but also extremely difficult to remember. So
>>> everyone used to write them down and keep them in their pockets.
[...]
> Seriously though, this is often a failing of security policies - make your
> security policy unwieldy and difficult to implement, and you run the risk
> that your users will find their own ways to subvert it.  I remember one
> 'secured' lab where all occupants shared the same password (for different
> user names) and had written it on a piece of masking tape stuck to the top
> of the monitor.
Some more examples...
* Sharing Lotus Notes passwords ("But I changed it when I got back")
because user doesn't have delegation privileges (and doesn't want to
bother admin) and doesn't recognize that changing the password doesn't
get you anywhere if the other party had an occasion to copy your id
file.
* Installing local modems to access the internet
* Leave safe open because number lock is too complicated to operate
We're only humans. If the person on the "receiving end" of the security
policy doesn't recognize its benefits *for himself* you'll get nowhere
because adhering to the policy always requires some effort.

Regards
        Peter

------------------------------

Crossposted-To: comp.security.misc,alt.security.pgp
From: [EMAIL PROTECTED] (Alan J Rosenthal)
Subject: Re: Passwords secure against dictionary attacks?
Date: 23 Feb 2000 21:05:07 GMT

Ilya <[EMAIL PROTECTED]> writes:
>I have  been  told that such
>combinations are vulnerable to dictionary attacks.  I think that they are
>not vulnerable to dictionary attacks since the password is not a word, it
>combines two words and is meaningless and can only be brute-forced.

A dictionary attack *is* a brute force attack.  (And if the combined word
were really meaningless, you wouldn't prefer it as a password.)  The question
is how much, um, brutality is required:

"Ken Hagan" <[EMAIL PROTECTED]> writes:
>for the scheme you describe, the closest we could come to
>a "dictionary" is as follows.
>
>1  Take a dictionary with various capitalisations like "hello", "Hello"
>    and "HELLO".
>2  Add "forms" like telephone numbers, car licence plate numbers, dates
>    (in all the common orderings, like MM/DD/YY), ZIP codes etc.
>3  Take some random punctuation characters.
>
>Now, permute all of the above in every way. For an initial dictionary of a
>few thousand "real words", this has now become a dictionary of around
>a billion.

This is the sort of thing the renowned Crack does, and it does not yield
the explosion you anticipate.  The reason it does not is because of the
8-character limit in unix.  This limit size of 8 is, unfortunately,
not limited to unix, but is quite common and in particular I believe that
the limit for SMB passwords is also 8.  As someone (Barry Margolin I think)
pointed out in this thread, concatenating "elephant" and "cake" yields
"elephant", if you have an 8-character limit.

Not only will many of your words not change the string they're concatenated
to (because the left word is of length >= 8), but much more significantly,
only the first few characters of the word end up counting.  For example,
"hello" (your example word) concatenated with "elephantcake" (heh heh)
yields the same password as hello concatenated with "electron", and all the
other words beginning with "ele".  The collapse is actually very significant.

The dictionary does end up large, but much less large than you are expecting.
The attack is feasible.  Given the 8-character limit.

I assume that PGP passphrases, if there is such a thing, are not limited
to 8 characters.  This thread is cross-posted a little wildly and I've
redirected followups (the Followup-To line is a proposal, not an obligation)
to the newsgroup I'm reading it in.

"NutWrench" <[EMAIL PROTECTED]> writes:
>  One way to have a easily-remembered password that defeats dictionary based
>attacks is to enter your passphrase, but press the key which is above and to
>the left or right of the actual key.

Crack will check this too, I believe.  (If not Crack, some other commonly-used
password cracker.)  It's a simple transformation and VERY commonly used.


The way to defeat dictionary attacks is to use random passwords.  And I do
mean random.

------------------------------


** 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
******************************

Reply via email to