Cryptography-Digest Digest #808, Volume #10 Wed, 29 Dec 99 17:13:01 EST
Contents:
Re: HD encryption passphrase cracked! (Keith A Monahan)
Re: AES wise? (Boaz Lopez)
Re: Employing digits of pi (Mok-Kong Shen)
Re: Secure Delete Not Smart ("Trevor Jackson, III")
Question. ("Mark")
Re: Attacks on a PKI (David A Molnar)
Password question. ("Elgo.")
Re: Secure Delete Not Smart (Donald Haines)
Re: Homophones (Mok-Kong Shen)
Re: Attacks on a PKI (Paul Rubin)
Re: AES wise? (SCOTT19U.ZIP_GUY)
Re: Diffie-Hellman (Eric Lee Green)
Re: Cryptography in Tom Clancy (Eric Lee Green)
Re: Attacks on a PKI (David A Molnar)
Re: Attacks on a PKI ("Lyal Collins")
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Keith A Monahan)
Subject: Re: HD encryption passphrase cracked!
Date: 29 Dec 1999 20:18:00 GMT
Hey,
NFN NMI L. ([EMAIL PROTECTED]) wrote:
: "Secure Deletion of Magnetic Media", Peter Gutmann. Good reading. I have the
: URL somewhere.
It's http://www.uncwil.edu/Ed/INSTRUCT/burt/edn416/secure_del.html here.
: By the way, now that it doesn't matter, what WAS the passphrase? :-D
I did contemplate posting it as most people would probably get a kick
out of it and would understand why it took so long. However, if someone
managed to get ahold of the ciphertext say awhile back, they could now
use the key. Sorry! :)
: S. "Deleted" L.
Keith
P.S. I forget where I've your email address before.
------------------------------
From: Boaz Lopez <[EMAIL PROTECTED]>
Subject: Re: AES wise?
Date: Wed, 29 Dec 1999 12:36:20 -1000
Anonymous wrote:
>
> Hi,
>
> Two thoughts:
> 1) Given the record of Blowfish having no attacks against the full
> algorithm, why do none of the AES candidates use fully key-dependant
> S-boxes? Is it because it is tough to make an f-function fully bijective
> that way, or is it just cumbersome to prove protection against differential
> analysis, or what?
Yes, the S-boxes would not be studied much before
they are used. Weak S-boxs may occur. The S-boxes for
Twofish were evaluated for many differential situations
and are clear of any weaknesses for the differentials
that were evaluated. Key dependent S-boxes would probably
not be carefully analysed bore they are used for
encryption.
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Employing digits of pi
Date: Wed, 29 Dec 1999 21:52:18 +0100
CLSV wrote:
>
> Mok-Kong Shen wrote:
>
> > You need not have to obtain the offsets 'directly' from your key bits.
> > For example, your key could be a seed to a PRNG that generates
> > a very long sequence of bits to give large offset values.
>
> Why don't use those bits instead?
> This is going to be a very costly
> procedure.
I was answering to your critique that, in order to address the remote
parts of pi, one would need a very long key. If you don't have
any problems to get these long keys, then everything is o.k. and
you can forget what I wrote for solving the problem you raised.
Otherwise I have shown a method with which you can adequately index
into the digit sequence of pi even if you only have a relatively
short key. Using a seed to a common type of PRNG to generate random
number sequences is scarcely considered to be computationally
expensive (to my knowledge till present).
> > I have difficulty of understanding here due to my poor knowledge. For
> > I couldn't yet link 'side channel attack' with 'higher computational
> > cost'. Could you please explain a bit more?
>
> Depending on the key you chose your algorithm takes
> longer to calculate the digits of Pi, so a timing
> attack could be feasable if the algorithm is embeded
> in say a web server.
Sorry that I don't consider all conceivable type of use of my
proposed scheme. Certainly there can be conceivable situations
where it is not appropriate or even disastrous for the user.
Nevertheless I personally tend to consider the use you mentioned to
be a fairly extraordinary one. The normal situation I use to
consider is that two communication partners each sitting at their
working place with a computer to do all the computations for
encryption/decryption and sending messages via the internet. I
believe this is the typical environment where secret messages,
in the narrow sense at least, get processed.
By the way, could you please give a definition of your 'side channel
attack'? I rather have doubt that I have catched that from the
context of the paragraph above. Thanks.
M. K. Shen
M. K. Shen
------------------------------
Date: Wed, 29 Dec 1999 15:52:53 -0500
From: "Trevor Jackson, III" <[EMAIL PROTECTED]>
Crossposted-To: alt.privacy
Subject: Re: Secure Delete Not Smart
Mark D wrote:
> Guy Macon wrote:
> >
> > In article <84b21n$[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Frank Gifford)
>wrote:
> >
> > >All this stuff about overwriting files assumes that the drive is working
> > >properly. Suppose that after you had put your top secret formula for
> > >Coca-Cola on your hard drive, it started to go bad. The read/write head,
> > >being a physical device, starts to drift away from the proper track and now
> > >it is a little more to the outside than it used to be. Now when you write
> > >data, it's writing a little towards one side of the track, but the other
> > >side of the track still contains your Coca-Cola formula.
> >
> > Minor correction; modern drives do not depend on mechanical tolerances.
> > They servo to the center of the track. Everything else you said is 100%
> > correct, because servos can go bad and be off to one side of the track.
>
> So here's your solution: burn all your information to cd, and if you
> want to 'secure delete' it, you just smash the cd. Since they're only
> about a buck a piece, it would be fairly inexpensive.
And fruitless. Recovering a smashed CD would be no trouble given the right optical
equipment.
It might be better to "reburn" the CD several times with data that forced every bit
into the
burned state. This may be a research topic for a paper equivalent to the one analyzing
megnetic media and semiconductor RAM.
------------------------------
From: "Mark" <[EMAIL PROTECTED]>
Subject: Question.
Date: Wed, 29 Dec 1999 21:49:08 +0100
I
------------------------------
From: David A Molnar <[EMAIL PROTECTED]>
Subject: Re: Attacks on a PKI
Date: 29 Dec 1999 20:45:34 GMT
Greg <[EMAIL PROTECTED]> wrote:
> there was a long list of CAs. I imagine that IE goes to those
> web sites and verifies a cert.
As I understand it, IE has the public keys of all those CAs in a database
on disk. When it needs to verify a cert, IE uses the local copy of the
CA key the cert claims to be associated with to check if the cert has been
signed by that CA. No communication with the CA is necessary.
The benefits are are at least twofold :
1) The CA does not need to be online, so less traffic and less
load on CA's web server.
2) The attack you describe does not exist; since IE does not
go to the CA's web site, there is no way for an adversary to
set him up as a man in the middle between IE and the CA for
a single transaction.
What _is_ possible is that your copy of IE is compromised, and that
the CA keys are all replaced by evil keys. Plus it is possible for
a user to add new CA keys to IE. You need to convince him to do this
somehow, but then you'd be OK.
Both of those attacks require a little more work than just setting
up as a man in the middle, though.
As for emulating a CA -- www.openca.org :-)
Thanks,
-David Molnar
------------------------------
From: "Elgo." <[EMAIL PROTECTED]>
Subject: Password question.
Date: Wed, 29 Dec 1999 22:01:51 +0100
Hi,
I'm curious as to which password algorithm might be in use. I'm new to this,
and I don't have a huge amount of info.
I have a small program that calls an API to encipher the password value. The
password value can be up to 32 characters.
I've noticed that if you encipher a clear text of zero to eight characters,
you get back exactly eight characters of cipher text. If you encipher
between nine and 32 characters (inclusive) you get back exactly 32
characters of cipher text.
I believe the algorithm dates back to the early eighties (ruling out,say,
RC4).
I've read about "salt", the system I'm dealing with doesn't seem to use
this. I say that because I've enciphered the same clear text value on more
than one machine (running the same crypto system) and I always get the same
cipher text.
Does this ring any bells?
Elgo.
------------------------------
From: Donald Haines <[EMAIL PROTECTED]>
Crossposted-To: alt.privacy
Subject: Re: Secure Delete Not Smart
Date: Wed, 29 Dec 1999 15:49:05 -0500
"Trevor Jackson, III" wrote:
And fruitless. Recovering a smashed CD would be no trouble given the right optical
equipment.
>
> It might be better to "reburn" the CD several times with data that forced every bit
>into the
> burned state. This may be a research topic for a paper equivalent to the one
>analyzing
> megnetic media and semiconductor RAM.
But the "reburning" of the CD probably won't completely obliterate what was there
before and a
hole burned twice is different from a hole burned once. Note that the CD option does
not address
the problem of the file probably having been stored on the hard drive during it's
creation.
.
Easier to toss the CD in a fire and that way you know for sure.
Don Haines
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Homophones
Date: Wed, 29 Dec 1999 22:31:17 +0100
wtshaw wrote:
>
> There is no doubt that you can get security in a hurry with a fairly
> lowtech algorithm. There are so many options that one could get lost in
> thinking about them. As to whether a good system can result depends more
> on the experience that might be put into such things. I've done widely
> varied systems as I have explored some of these I see; others would see
> different options.
My point was that, since one can restrict oneself to an alphabet
size of 32 but normally use a space of 256, there is opportunity
of employing homophones 'for free' and so, even in case a homophone
component adds not very much to the total security, it is still worth
while to consider its use, since it costs almost nothing in my view
(it certainly could do no harm).
>From what you wrote I believe you have much knowledge and experience
in homophones. If you were not under NDA and could find time to write
something on that, I think many would be interested to read your
article and discuss with you.
M. K. Shen
------------------------------
From: [EMAIL PROTECTED] (Paul Rubin)
Subject: Re: Attacks on a PKI
Date: 29 Dec 1999 21:37:35 GMT
In article <84damo$u5j$[EMAIL PROTECTED]>, Greg <[EMAIL PROTECTED]> wrote:
>I was looking at the SSL protocol yesterday and read about how
>the man in the middle attack was foiled by a certificate. And
>I asked the question of this news group how IE validates a cert
>that a server issues to the client (IE)? Someone responded and
>I searched the "internet options" dialog tab and sure enough,
>there was a long list of CAs. I imagine that IE goes to those
>web sites and verifies a cert.
You don't understand what a CA is. Certificates don't work anything
like the way you're imagining. The certificate check is done totally
inside the browser. The CA can be completely offline. Try surfing
around www.verisign.com or www.thawte.com and reading some of the
tutorials at those sites.
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: AES wise?
Date: Wed, 29 Dec 1999 22:32:18 GMT
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
(Anonymous) wrote:
>Hi,
>
>Two thoughts:
> 1) Given the record of Blowfish having no attacks against the full
>algorithm, why do none of the AES candidates use fully key-dependant
>S-boxes? Is it because it is tough to make an f-function fully bijective
>that way, or is it just cumbersome to prove protection against differential
>analysis, or what? (NSA seems to dislike random, unknown S-boxes) Ok,
>Twofish uses S-boxes, however from only half the key. Are there any
>little-known attacks (that someone can reference) against Blowfish because
>of the random S-boxes?
> 2) It would seem that creating only one algorithm for ALL purposes for
>ALL implementations is a little silly. Others posting to this group have
>asked "why not choose more than one winner." That is not what I am saying. I
>say that the AES goal is flawed: Why did NIST not just call for two
>algorithms? (One for high security, and one for implementations where
>resources are low.) Even just two versions of the same algorithm?
They want only one so the NSA can easily break it.
Large key dependent S boxes are to hard for the NSA to break so
that may be why they are not in wide use. If you want a large S-box
take a look at scott19u.zip I am sure there are not many larger.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website NOT FOR WIMPS
http://members.xoom.com/ecil/index.htm
Scott rejected paper for the ACM
http://members.xoom.com/ecil/dspaper.htm
Scott famous Compression Page WIMPS allowed
http://members.xoom.com/ecil/compress.htm
**NOTE EMAIL address is for SPAMERS***
I leave you with this final thought from President Bill Clinton:
"The road to tyranny, we must never forget, begins with the destruction of the
truth."
------------------------------
From: Eric Lee Green <[EMAIL PROTECTED]>
Subject: Re: Diffie-Hellman
Date: Wed, 29 Dec 1999 14:48:32 -0700
Daniel Roethlisberger wrote:
>
> Trying to understand Diffie-Hellman in order to implement it, I stumbled
> across the following sentence in Applied Cryptography: "... agree on a large
> prime, n and g, such that g is primitive mod n". Now my English is no good
> when it comes to mathematical terms. What does _primitive_ exactly mean? If
> n is the large prime, what is g? As it says later on in the chapter, g can
> be chosen as small as possible (ie. a one-digit number), and doesn't even
> have to be primitive. But I am still puzzled what primitive means,
> mathematically.
"primitive mod n" is defined earlier in the book in the section on math theory
that you skipped over when you went directly to the section on Diffie-Hellman
(grin).
If you lok on the next page, there's even a caveat about g -- i.e., that it's
not absolutely necessary that it be primitive, as long as it generates a large
enough subgroup. In actuality, it's easiest to have 2 be the 'g' and then
search for a large n. In fact, if you look at the OpenSSL source code,
somebody has already done that for you!
--
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: Eric Lee Green <[EMAIL PROTECTED]>
Subject: Re: Cryptography in Tom Clancy
Date: Wed, 29 Dec 1999 14:52:53 -0700
John Savard wrote:
> But the purpose of a novel is to entertain, so a few technical
> implausibilities, as long as they help to advance the plot, are not to
> be concerned about. (In fact, of course, I would expect that the
> STU-III would not be that "close" to being breakable that even the NSA
> could do so a decade hence; that would be irresponsible underdesign.)
An aquaintance who was once in the Air Force commented that their encryption
machines were almost as old as the B-52 bombers that they were flying.
I'm sure those antiques have been retired by now, but the point is that the
armed forces aren't always using the "latest and greatest", and that it takes
years between the time new technology is developed, and the time it is
deployed. It would not surprise me if the NSA was capable of breaking Air
Force encryption today that was done ten years ago on twenty-year-old
encrption machines.
--
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: David A Molnar <[EMAIL PROTECTED]>
Subject: Re: Attacks on a PKI
Date: 29 Dec 1999 21:32:49 GMT
Sorry, I should not have been so brief. Part of my point is that
the "supposed purpose of the PKI" is not always clear. If you are
using a key which is certified by a PKI, you may assume that the
key is "good enough" for whatever situation you need, just because
it's part of a PKI.
Now if you and the PKI have different notions of what "good enough" means
-- say, you think "good enough" includes being "not too weak" and the PKI
just thinks "good enough" means "we looked at his Vermont driver's
license" -- then you will be in trouble. Maybe it is your own fault
for not studying PKI statements carefully, but that will be hard to
take after someone repudiates a key and the PKI says it's not their
problem.
Put another way, how do you know that you and the PKI have the same notion
of an "authentic" key? and how weird does your application need to be
before you should worry that the PKI doesn't think about keys the
way you do?
-David
Greg <[EMAIL PROTECTED]> wrote:
>> Registering easily-factored or other low-quality keys with the PKI. If
>> ppl confuse verifying identity with verifying "key quality" (and how
> many
>> do ? ), then can undermine confidence in the PKI and public key crypto
>> in general. Solution seems to be to certify the public keys...
> This is not an attack on the PKI, but on the key. The PKI
> would still be just as valid or invalid identifying who the
> faulty key belongs to. That is the supposed purpose of the
> PKI.
------------------------------
From: "Lyal Collins" <[EMAIL PROTECTED]>
Subject: Re: Attacks on a PKI
Date: Thu, 30 Dec 1999 09:02:50 +1100
Centralised PIN/password checking has one advantage in that there is only
one verification process to trust. Smartcard are essentially a version of
this - although the smartcards are distributed, they alll use a trustable,
not-trivially subverted process.
Of course users may write down passwords, or be over-sighted etc - nothing
stops these issues, although biometrics may, one day.
In distributed password checking (al la PKI models), every recipient must
rely on the originator's processes and security controls. Since so few of
use (myself included) are competent to be 100% effective all the time on
security management, large scale PKI systems will fall apart some time after
launch.
How fast they fall apart depends on a number of variables - every users
attention to detail and instructions, the framework and implementation
details etc.
Having said the foregoing, AADS on a Smartcard with a PIN entry device is as
good an option as any for ecommerce - while standard flavour PKI is not.
lyal
Anne & Lynn Wheeler wrote in message ...
>
>"Lyal Collins" <[EMAIL PROTECTED]> writes:
>
>> Authentication of individuals using PKI is about as strong as the
passwords
>> they use to control access to their priate key.
>>
>> Why not stick to passwords and integrity checking databases, for
>> non-ecommerce uses?
>>
>> Lyal
>
>strictly shared secret based systems tend to have the shared secret in
>a lot more places and have a lot simpler exploit modes ... shared
>secrets can be be attacked with social engineering (i.e. call the
>person and tell them you are bank examiner and need to test the bank's
>security & ask them for their bank account number and their mother's
>maiden name ... or call and tell them you are the ISP security
>manager and need to test their login account).
>
>Account Authority Digital Signature (AADS) public key ... eliminates
>those exploit modes, preserves existing authentication business
>processes and establishes the basis for parameterized risk management.
>
>In the paramemterized risk management portion ... the AADS public
>protocol and processes can be the same across a wide-range of business
>processes & requirements ... but the risk parameters are adjusted
>based on the integrity level of the environment housing the private
>key and doing the digital signing (simple example is credit limit and
>transaction authorization are different whether the private key is a
>PC housing with password access ... or a seperate 140-3 smartcard with
>both PIN and biometrics).
>
>This is easily generalized to authentication infrastructure ... using
>the same infrastructure for things like financial transactions, web
>access, & ISP login (straight-forward RADIUS enhancement) ... all
>sharing the same technology infrastructure and level of integrity
>adjusted to meet the requirements of the business.
>
>--
>--
>Anne & Lynn Wheeler | [EMAIL PROTECTED], [EMAIL PROTECTED]
> http://www.garlic.com/~lynn/ http://www.adcomsys.net/lynn/
------------------------------
** 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
******************************
