Cryptography-Digest Digest #240, Volume #11 Thu, 2 Mar 00 18:13:01 EST
Contents:
Re: OAP-L3 Version 4.2: Updated OverWrite / Delete method ("Joseph Ashwood")
Re: ...but what about my cipher? ([EMAIL PROTECTED])
Re: Crypto.Com, Inc. ([EMAIL PROTECTED])
Re: Passwords secure against dictionary attacks? ("Joseph Ashwood")
Re: Status of alleged *THIRD* key in MS Crypto API ? (Hammer)
Re: Visual C++ Decompiling Service/Software Needed ([EMAIL PROTECTED])
Re: NSA Linux and the GPL (Eric Lee Green)
Re: very tiny algorithm - any better than XOR? (Paul Rubin)
Re: very tiny algorithm - any better than XOR? (Paul Rubin)
Re: Passwords secure against dictionary attacks? ([EMAIL PROTECTED])
----------------------------------------------------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: OAP-L3 Version 4.2: Updated OverWrite / Delete method
Date: Thu, 2 Mar 2000 13:24:37 -0000
Crossposted-To: talk.politics.crypto,alt.privacy
> Then will come the screen savers that scrub
continuously...
I can actually see where that could be useful, especially if
it's combined with a defragmenter. I see it as the next
step, instead if just wiping disks on shutdown or when you
remember you click the button, all you have to do is
remember to leave your computer alone. It could also be made
in a way that would detect bad blocks on the drive.
Basically just a general purpose scandisk/defrag/overwrite
replacement. I've already seen a continuous backup method,
couldn't this be the next part?
Joe
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: ...but what about my cipher?
Date: 2 Mar 2000 21:40:19 GMT
In a previous article, Glenn Larsson <[EMAIL PROTECTED]>
writes:
>Seems like it only rely on a password and a fixed
>key = as weak as the password is.
>
>Hint: Dictionary attack.
The key is actually digested from the password (by a simple mod 2147483543
operation), but the initial IVector is always the same for each session, so,
yes, that is one way of puuting it.
But nothing in the code prevents you from entering a 2^30 character long
passphrase. If you are using my freeware app and the option "sign encrypted
files" the password will simply be insert at the beginning and appended at
the end. In such case brute force would still be quicker than a dictionary
attack on the passphrase. (Unless the attacker exploit the fact that the
initial IVector is the same for each session and passphrase. In such case, an
attacker might extract the passphrase inserted at the beginning relatively
easy.)
----- 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]
Subject: Re: Crypto.Com, Inc.
Date: Thu, 02 Mar 2000 21:49:19 GMT
In article <
89jrld$vns$[EMAIL PROTECTED]>,
David A Molnar <[EMAIL PROTECTED]>
wrote:
> John Savard <[EMAIL PROTECTED]> wrote:
> > It may also be noted that there already does exist a "technology"
> > which provides for _reasonable_ security "on open circuits between two
> > users without the use of a" previously-arranged key...public-key
> > cryptography.
>
> yes, but the quote said "unbreakable." This implies info-theoretic
> security at best, and cluelessness at worst.
>
> -David
>
Hey David, I see that you are at Harvard U.
which is where my dad does research in the
DEAS. When connections like this occur it
reminds me of Ramsey Theory which, as part
of graph theory and combinatorics, should
have some role in cryptology. I don't know
what this role is.
>
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: Passwords secure against dictionary attacks?
Date: Thu, 2 Mar 2000 13:43:08 -0000
Crossposted-To: comp.security.misc,alt.security.pgp
I think your estimate of 16 bits of entropy per word isn't
quite right. Most Americans have a vocabulary of around 5000
words, the same applies for many other countries. That means
that, at best, we can have a reasonable expectation of 8192
words in their vocabulary, or 13 bits. More likely 4096
words for 12 bits. Now, of those words we tend to use only a
few hundred in daily conversation (e.g. obfuscation isn't
used daily), and therefore it is likely that there will be
an extreme bias towards those words for only 8 bits of
entropy per words. This makes the 10 word recommendation at
80 bits, considering varying the space between, people will
again have a rather strong bias, so I don't see any reason
to expect an addition of more than 1.5 bits, the 10 word
recommendation is therefore 93.5 bits, 9 words is 84,
reducing the needed space to 9 words. The rules of course
change if someone makes the effort to use their entire
education, and I would expect that someone whose interest is
in learning words, would have a knowledge approaching that
of an unabridged dictionary of 65K words, or 16 bits per
word, and immediately foiling most dictionary attacks.
I have of course been ignoring capatilization, which by
itself can offer almost 1 bit of entropy per letter. This
can offer a significant increase in security against a
dictionary attack, but can make viewing attacks easier
(keyboard spying).
I guess my point is that you need to identify what your
adversary is capable of. Will she/he have access to the room
you type your password in? Will she/he have enough compute
power to brute force 64 bits of key? Etc.
Joe
------------------------------
From: Hammer <[EMAIL PROTECTED]>
Subject: Re: Status of alleged *THIRD* key in MS Crypto API ?
Date: Thu, 02 Mar 2000 22:03:14 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Francois Grieu) wrote:
> A few weeks ago I read some news on a researcher announcing the
> discovery of a *THIRD* key in the Windows code responsible for
[snip]
>
> What's going on with this story ?
Here is the URL at MS to read their story on it... of course, those of
you with the raging anti-MS leanings and conspiracy theories will
probably only get a good laugh from it.
My guess there are some that are still holed up in their Y2K bunkers
who would scoff at this as well :)
For myself, I buy the story, for numerous reasons.
http://www.microsoft.com/security/bulletins/backdoor.asp
I am usually only a lurker here in sci.crypt, and I have so much
respect for the lads here, and the amazing volume and accuracy of
information I learn from you all. It's priceless to my career. On
this particular topic, though, I'm motivated to express my opinion that
some of the conspiracy theories and outright "wacky" stuff in these
types of threads leaves me ocassionaly confused at some of sci.crypts
brightest minds spending cycles on such things. Can I say that while
still being full of genuine respect for the participants in sci.crypt?
I hope so.
hammer
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Visual C++ Decompiling Service/Software Needed
Date: 2 Mar 2000 22:07:50 GMT
In a previous article, Jerry Coffin <[EMAIL PROTECTED]> writes:
>In article <89leif$f6j$[EMAIL PROTECTED]>,
>[EMAIL PROTECTED] says...
>> In a previous article, <[EMAIL PROTECTED]> writes:
>> >Interesting. Where is "decompiling" software a crime? Europe?
>>
>> Correct, at least in a couple of European contries.
>
>I rather doubt it,
Well, I am certain about the Swedish copyright legislation. The relevant
articles are 26 h § (prohibiting RE unless for bugfix or for acheiving
compatibility) and 53 § (regulation of sentences in case of a criminal law
suite).
>and even if there are, I _really_ doubt they ARE
>enforced, or really even CAN be enforced, at least without causing
>the country in question some serious problems -- there's an EU
>directive that absolutely requires all member countries to allow
>reverse engineering for certain purposes.
Yes, of course: You might use qualified personel to RE for bugfix or
compatibility reasons. But primarily you should contact the copyright owner
and demand that he makes the adjustments himself.
----- 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: Eric Lee Green <[EMAIL PROTECTED]>
Subject: Re: NSA Linux and the GPL
Date: Thu, 02 Mar 2000 22:19:13 GMT
"Douglas A. Gwyn" wrote:
> John Savard wrote:
> > However, the NSA might have wanted the security part to be written
> > from scratch, so that any known flaws in BSD would not be a problem.
>
> Oh, good grief! NSA was one of the very first licensees of UNIX
> source code, and has had various flavors of UNIX, among numerous
> other OSes (including some devised within NSA), for decades. There
> is no particular reason they need to use Linux as opposed to more
> fully developed genuine UNIX-based systems.
I'm a bit late into this communication because I've been moving, but...
Well, actually, there is a reason -- cost. Pure and simple. Linux (or one of
the free BSD's) makes the most cost-effective Internet server in existence. It
is becoming increasingly popular in government for EMAIL servers, in
particular, where Microsoft charges a large amount of money for a less-capable
Exchange Server and the budget situation doesn't allow for the expense of one
of the "real" Unixes.
In addition, UNIX source code is heavily encumbered, legally speaking. This
means that, while the NSA can easily change UNIX source code internally for
their own use, they are generally unable to distribute such changes to other
government agencies which may have need of it (this would require negotiating
separate source code licensing agreements on behalf of those other agencies).
> It may well be that
> one or more individuals or groups within NSA have an interest in
> some uses of Linux, but it's certainly not part of a massive
> corporate strategy to adopt it for most computing.
Agreed. Apparently the NSA is concerned because of their secondary role of
securing government networks in general. There have been a number of
high-profile instances of government web sites being hacked and defaced. This
has occured both with Windows NT and commercial Unixes. The obvious solution
is to come up with a more secure platform that will not be easily 'cracked'.
Linux is quite popular in the ISP community, supports a wide variety of
commodity PC hardware, and its source code and programs compiled from it are
freely distributable (unlike the UNIX source that the NSA licenses). FreeBSD
would also be a good choice, but apparently is not so widely used by
government agencies at the moment.
BTW, I can attest, as a former employee of a company that sold one to the
government, that certain Three Letter Acronym agencies do have Linux Beowulf
clusters. I don't think I should go further than that. I doubt that these
clusters are used for normal operational purposes, however, because a pile of
20 or 30 standard PC's just isn't enough for that... I suspect they are used
by researchers attempting to improve the algorithms being used for various
forms of pattern recognition in audio and visual signals (hmm, cryptic enough?
:-).
> As another poster hinted, no matter how much the security of Linux
> is beefed up, it will not become Multi-Level Secure, and hence its
> security will never be relied upon to act as a barrier between the
> public and classified information. Classified information is
> protected by not being kept in the same places that the public has
> access to.
I would basically agree with you, although the Linux kernel itself has the
'hooks' in it already for 'capabilities', which presumably is one of the
things that made the NSA believe that it could at least be secured against
ordinary 'hackers' who deface web sites. If a process does not inherit the
capability for changing files, it does not matter how many SUID-root programs
have buffer overflows, the process won't change any files. But without the
hardware 'hooks' to enforce such capabilities, hardware that doesn't exist on
any current Linux platform, true MLS capability just isn't going to happen.
Any Unix system running on commodity hardware looks pathetic security-wise
compared to the Multics Level/68, for example, which enforced the
security-level 'ring' system in hardware...
Oh, a couple more things:
1) Linux does have iBCS/2 capability (that is, '386 Unix binary
compatibility), though the compatibility module must be loaded first. I used
this capability to run SCO UNIX database programs prior to Linux becoming
trendy enough to have native ports. Made for a cheap home development system
for the SCO Unix applications that I was writing for work. Note that, if
programs violate the binary standards by referencing proprietary shared
libraries, they're not cross-platform capable... but you already knew that.
2) It is becoming increasingly unwise to differentiate between Linux and
"real" Unix. We currently support a dozen or so Unix platforms here at EST,
and there just isn't much of a difference anymore, unlike a few years back
when we sometimes had to do weird work-arounds around missing features on
Linux. Linux currently lags one to three years behind Unix in certain areas
(64-bit file support on 32-bit platforms, support for the latest NFS and NIS
standards, support for journaling file systems, etc.), and is quite a bit
ahead in others (especially programming tools and graphical user environments
-- commercial Unix lags seriously in these areas, the first thing we have to
do when we go to do a port to a new Unix platform is compile the GNU tools
that we take for granted on Linux). But I doubt that Dennis Ritchie would be
very shocked by the experience of sitting down at a Linux login prompt... his
response would probably be "yeah right, it's just another Unix, what's the big
deal? Why the hype?" (In fact, I think that's what he's basically said on his
web site... and to tell you the truth, after fighting the Linux SCSI layer for
the past two weeks, I'm inclined to agree with him, sigh).
--
Eric Lee Green [EMAIL PROTECTED]
Software Engineer Visit our Web page:
Enhanced Software Technologies, Inc. http://www.estinc.com/
(602) 470-1115 voice (602) 470-1116 fax
------------------------------
From: [EMAIL PROTECTED] (Paul Rubin)
Subject: Re: very tiny algorithm - any better than XOR?
Date: 2 Mar 2000 22:20:44 GMT
In article <89kk5b$aq5$[EMAIL PROTECTED]>,
David A. Wagner <[EMAIL PROTECTED]> wrote:
>Have you looked at GOST or Treyfer? These are remarkably
>good for 8 bit processors. (Treyfer may be exactly what you
>are looking for, because it doesn't require space for any
>S-boxes: it uses existing data in your ROM, whatever you
>may already have in place, code or whatever, as a replacement.)
I've never heard of Treyfer, got a URL?
GOST is actually well suited for 4-bit cpu's,but requires 64 bytes of
S-box data.
------------------------------
From: [EMAIL PROTECTED] (Paul Rubin)
Subject: Re: very tiny algorithm - any better than XOR?
Date: 2 Mar 2000 22:28:17 GMT
In article <89l58e$j1h$[EMAIL PROTECTED]>,
Carl Byington <[EMAIL PROTECTED]> wrote:
>I wish to thank everyone for their suggestions. This will be running on
>an Atmel AT90S8515 <http://www.atmel.com/atmel/acrobat/doc0841.pdf>.
>
>I did look at TEA, but I don't see any way to get that into anything
>like 50 bytes on this processor.
>
>I still need to investigate PIKE, but it seems to use 32 bit operations,
>and this processor only has 8 bit ones, so the code quickly gets large.
As I remember, PIKE uses three LFSR's of differing lengths.
How much RAM do you have available?
Can you say more about your application? I.e. what kind of data do you
want to decrypt, and how often? Would there be a fixed key or do you
have to be able to load ones? Does the key count as part of the 50 bytes?
The Atmels are pretty fast compared to typical cheap 8-bit parts, IIRC.
You might be able to get away with something pretty inefficient if you
only have to decrypt something once in a while.
------------------------------
From: [EMAIL PROTECTED]
Crossposted-To: comp.security.misc,alt.security.pgp,
Subject: Re: Passwords secure against dictionary attacks?
Date: 2 Mar 2000 22:48:47 GMT
If you are programming in Delphi 4, I might have an adequate remedy for this:
I constructed a component that compiles dictionaries out of any plain text
files you feed it with. These dictionaries might then be used to eliminate
plain text redundancy by replacing each word by the ordinal value of the
corresponding entry in the dictionary. You might choose to order the entries
in the dictionary according to their freduency, so that the 255 most common
words get represented by a format token and a one byte code, the next
$FE01-$FF most common entries represented by a format token and a two byte
code, etc.
Pick up a copy (no source unless you pay, note that Swedish legislation
applies ;-)) at http://w1.462.telia.com/~u46205672/FHH.htm
In a previous article, "Joseph Ashwood" <[EMAIL PROTECTED]> writes:
>I think your estimate of 16 bits of entropy per word isn't
>quite right. Most Americans have a vocabulary of around 5000
>words, the same applies for many other countries. That means
>that, at best, we can have a reasonable expectation of 8192
>words in their vocabulary, or 13 bits. More likely 4096
>words for 12 bits. Now, of those words we tend to use only a
>few hundred in daily conversation (e.g. obfuscation isn't
>used daily), and therefore it is likely that there will be
>an extreme bias towards those words for only 8 bits of
>entropy per words. This makes the 10 word recommendation at
>80 bits, considering varying the space between, people will
>again have a rather strong bias, so I don't see any reason
>to expect an addition of more than 1.5 bits, the 10 word
>recommendation is therefore 93.5 bits, 9 words is 84,
>reducing the needed space to 9 words. The rules of course
>change if someone makes the effort to use their entire
>education, and I would expect that someone whose interest is
>in learning words, would have a knowledge approaching that
>of an unabridged dictionary of 65K words, or 16 bits per
>word, and immediately foiling most dictionary attacks.
>
>I have of course been ignoring capatilization, which by
>itself can offer almost 1 bit of entropy per letter. This
>can offer a significant increase in security against a
>dictionary attack, but can make viewing attacks easier
>(keyboard spying).
>
>I guess my point is that you need to identify what your
>adversary is capable of. Will she/he have access to the room
>you type your password in? Will she/he have enough compute
>power to brute force 64 bits of key? Etc.
> Joe
>
>
----- 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
******************************
