Cryptography-Digest Digest #25, Volume #11 Mon, 31 Jan 00 16:13:01 EST
Contents:
Re: How to Annoy the NSA ([EMAIL PROTECTED])
Re: Using blowfish as a one-way hash? (Eric Lee Green)
Re: How to annoy the NSA & break almost any code ([EMAIL PROTECTED])
Re: What is the status of AES? ("Brian Gladman")
Re: How to annoy the NSA & break almost any code (Dave Newton)
Re: Re: How to password protect files on distribution CD ("Bill \"Houdini\" Weiss")
Re: Re: Re: How to password protect files on distribution CD ("Bill \"Houdini\"
Weiss")
Re: Q: DFT ([EMAIL PROTECTED])
Re: XML vs Javabean for B2B (Drew Cutter)
Re: How to password protect files on distribution CD (Johnny Bravo)
Re: Wireless PKI now or later (Vernon Schryver)
Re: How to password protect files on distribution CD (lordcow77)
Re: Is there a practical guide to using crypto? (Steven Siew)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED]
Subject: Re: How to Annoy the NSA
Date: Mon, 31 Jan 2000 18:01:36 GMT
In article <
[EMAIL PROTECTED]
ng.com>,
Jerry Coffin <[EMAIL PROTECTED]> wrote:
> In article <873807$u1f$[EMAIL PROTECTED]>, [EMAIL PROTECTED]
> says...
> > To annoy the NSA start
> > spreading this news. Soon, if not
> > already, it will be possible to
> > build a quantum computer that
> > can solve NP-Complete & #P
> > Complete problems. This
> > computer would thus be able to
> > crack any code except for those
> > encrypted via a one- time pad
> > key cipher or certain types of
> > quantum cryptography.
>
> [ more elided ]
>
> Please look back through the archives of this newsgroup: you'll find
> that quantum computing is not news to regulars here. You'll also find
> that the assertion you've made above has little to do with reality.
>
> Quantum computing can break certain kinds of encryption more quickly
> than conventional computing, but this does not mean all ciphers other
> than a one-time-pad are particularly vulnerable. A quantum computer
> could break RSA (for one example) more quickly than a conventional
> computer, but doubling the size of the key used brings back roughly
> the present level of security. Right now, an RSA key from about 750
> bits on up is reasonably secure -- I prefer 1024 bits, but mostly as a
> matter of principle. If you honestly believe that quantum computing
> will be usable in the relatively near future, this means increasing
> your key to somewhere in the range of 1500 to 2048 bits or so. Many
> people already do that, though it's usually just out of a feeling that
> "bigger is better" rather than any analysis of the chances of a
> quantum computer being put into use anytime soon.
>
> Also note that nobody's figured out ANY way to use a quantum computer
> to attack MANY (if not most) of the ciphers in use today. Just for
> example, if you could postulate that a quantum computer was available
> and ready for use right now, it would make essentially NO difference
> to the security of any of the AES finalist candidates.
>
> --
> Later,
> Jerry.
>
> The universe is a figment of its own imagination.
>
The paper I referred to is news because it is
the only proposal I know of that describes how
to go about building a quantum computer that
consists of BOTH linear and nonlinear gates.
Such a device could probably be made by a
group like MIT's Bose condensate lab. Some or
many of the NSA's codes have depended on the
intractability of NP- Complete problems
which could become vulnerable to this type of
computer.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Eric Lee Green <[EMAIL PROTECTED]>
Subject: Re: Using blowfish as a one-way hash?
Date: Mon, 31 Jan 2000 11:17:56 -0700
ChenNelson wrote:
> In _Applied Cryptography_ Schneier noted that blowfish is not to be
> used as a one-way hash. Why is this so, in CBC mode?
I would presume it is because blowfish only has a 64-bit block size.
It'd be interesting to see whether twofish, with its larger 128-bit block
size, would be useful for this purpose.
--
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]
Subject: Re: How to annoy the NSA & break almost any code
Date: Mon, 31 Jan 2000 18:12:14 GMT
In article <873u8m$d8h$[EMAIL PROTECTED]>,
Tom St Denis <[EMAIL PROTECTED]> wrote:
> In article <8738rg$unb$[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] wrote:
> > You can probably annoy the NSA by spreading
> > this news. Soon, if not already, it will be
> > possible to build a quantum computer that can
> > solve NP- Complete and #P Complete
> > problems. Thus, such a device could decipher
> > any code except for those encrypted via a one-
> > time pad key cipher or possibly certain types
> > of quantum cryptography (both of which are
> > very rarely used). To begin seeing how this
> > might work check out this physics paper:
> > //xxx.lanl.gov/abs/quant-ph/9910073
> >
> > Sent via Deja.com http://www.deja.com/
> > Before you buy.
>
> I already have one made of spare parts from my timer. It's the quantum
> computer that keeps on ticking.
>
> Look, this story has been 'reported' twenty if not more times already
> before. NOBODY GIVES A FUCK!!!
>
> Tom
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
>
This story was not "reported" before and is
new because the paper I referred to describes
the only way I know of to go about building a
quantum computer consisting of BOTH linear
and non-linear gates. The people who don't
"give a fuck" are those who are too ignorant to
understand computability and deciphering.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "Brian Gladman" <[EMAIL PROTECTED]>
Subject: Re: What is the status of AES?
Date: Mon, 31 Jan 2000 18:23:05 -0000
"Sandy Harris" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> [posted and mailed]
>
> [EMAIL PROTECTED] (Ed Pugh) spake thus:
[snip]
> There's data at the Block Cipher Lounge, on pages reporting timing results
> from Brian Gladman and Helger Lipmaa. I've no URLs to hand.
My home page has moved and is now at:
http://www.btinternet.com/~brian.gladman/
I have just put some revised figures up for the Pentium II/III and I hope to
add some figures for ARM soon. My AES second round performance results (and
source code) are available at:
http://www.btinternet.com/~brian.gladman/ /cryptography_technology/aes2/
Brian Gladman
------------------------------
From: Dave Newton <[EMAIL PROTECTED]>
Subject: Re: How to annoy the NSA & break almost any code
Date: Mon, 31 Jan 2000 18:17:02 GMT
[EMAIL PROTECTED] wrote:
> This story was not "reported" before and is
> new because the paper I referred to describes
> the only way I know of to go about building a
---------------------- [we might be on to something here]
> quantum computer consisting of BOTH linear
> and non-linear gates. The people who don't
> "give a fuck" are those who are too ignorant to
> understand computability and deciphering.
Look, all he's saying is that the potential problem-solving of
quantum computing is quite well-known.
d
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "Bill \"Houdini\" Weiss" <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp,comp.security.unix,comp.security
Subject: Re: Re: How to password protect files on distribution CD
Date: Mon, 31 Jan 2000 11:38:29 -0700
Reply-To: [EMAIL PROTECTED]
On Mon, 31 Jan 2000 06:30:15 +0000, Johnny Bravo <[EMAIL PROTECTED]>
wrote in comp.security.unix :
>On Sun, 30 Jan 2000 23:37:14 -0700, "Bill \"Houdini\" Weiss"
><[EMAIL PROTECTED]> wrote:
>
>>I've wondered recently, what is the cost of some decent-speed DES
>>hardware? Because, one would make a hell of a dongle. Have the
>>program call the hardware to do vital parts of the code, and make the
>>hardware fast enough that the calls can be big enough to make the
>>program really fucking cumbersome to use without it.
>
> Unless your software does DES encryption, what would DES chips have to
>do with the software?
You code it to do DES decryption of various parts, maybe. Time-based,
so the various calls can't just be reverse-engineered out of it.
I'm thinking copy-protection by dongle, here.
--
Bill "Houdini" Weiss
--
How To Write Good
32. Don't repeat yourself, or say again what you have said before.
33. Don't be redundant.
------------------------------
From: "Bill \"Houdini\" Weiss" <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp,comp.security.unix,comp.security
Subject: Re: Re: Re: How to password protect files on distribution CD
Date: Mon, 31 Jan 2000 11:39:09 -0700
Reply-To: [EMAIL PROTECTED]
On Mon, 31 Jan 2000 07:12:58 GMT, [EMAIL PROTECTED] (Chris Adams)
wrote in comp.security.unix :
>On Sun, 30 Jan 2000 23:37:14 -0700, Bill \"Houdini\" Weiss <[EMAIL PROTECTED]>
>wrote:
>>I've wondered recently, what is the cost of some decent-speed DES
>>hardware? Because, one would make a hell of a dongle. Have the
>>program call the hardware to do vital parts of the code, and make the
>>hardware fast enough that the calls can be big enough to make the
>>program really fucking cumbersome to use without it. Added to
>
>Or, look at it another way: build a hardware accelerator so that your program
>is not only inseparable from the hardware but faster as well, thus giving your
>*customers* a reason to buy it. Done right, the "dongle" becomes a major
>feature.
Good call. You could do a lot of acceleration on custom hardware.
--
Bill "Houdini" Weiss
--
Bad command. Bad, bad command! Sit! Stay! Staaay..
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Q: DFT
Date: Mon, 31 Jan 2000 18:39:46 GMT
In article <[EMAIL PROTECTED]>,
Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
> Douglas A. Gwyn schrieb:
> >
> > Mok-Kong Shen wrote:
> > > DFT, like all such transforms, has an inverse. However, due to the
> > > unavoidable rounding errors of real computations involved, a
vector
> > > of integers might not get back to exactly the same values. What
> > > techniques can one best employ to obtain an exact inverse?
> >
> > Most cryptologic applications of DFT of which I am aware use a
> > DFT over a finite field, which is an exact operation with an
> > exact inverse.
>
> As far as I understand, one has in general to employ multi-precision
> arithmetics. I would like very much to know whether it is possible
> to say something concerning the relation between a (given)
> employed precision and (certain characterization of) the data in
> computations giving exact inverse of the DFT transform. In particular,
> if one uses the single precision (say with 32 bits on PC), is it
> possible to say that one can do DFT on certain data (i.e. belonging
> to certain specifiable category) and is guaranteed to be able to get
> the exact inverse?
>
> M. K. Shen
>
> M. K. Shen
>
Hi
Douglas Gwyn gave you the correct hint.
You can find something about "DFT on a finite field"
by searching the Web with Altavista for the above phrase.
That's Fourier-like transformation on INTEGER.
But, if you want info about the Fourier Transform
and the errors introduced by limited precision of the
DFT coefficient, you can get'em by searching for
in the field of Digital Signal Processing.
There are many good books:
by Oppenheim & Schafer
by Gold & Rabiner
and many more.
All of them have addressed the problem of the
limited precision of DFT coefficients and the
resulting error in DFT output.
I apologize i can't give you precise references
..but maybe, someone else...
regards
Ferdinando
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
Date: Tue, 01 Feb 2000 14:20:59 -0500
From: Drew Cutter <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: XML vs Javabean for B2B
Ericsson and Nokia . Nokia just sign a deal with BEA for a wap server. I
see where Motorola will have a java based cell phone soon (Javabean ?).
Their is WAP software for palmpilot. WAP will be here in the US either
this year or next.
Baltimore has xml encryption. Certicom has a javabean option for
encryption. It probably too soon.
------------------------------
From: Johnny Bravo <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp,comp.security.unix,comp.security
Subject: Re: How to password protect files on distribution CD
Date: Mon, 31 Jan 2000 15:09:03 +0000
On Mon, 31 Jan 2000 10:51:37 -0700, Eric Lee Green <[EMAIL PROTECTED]>
wrote:
>The problem is that this can be easily "cracked" by crackers in order to strip
>out the license key checking code. Thus don't think this is uncrackable. All
>you're doing is locking your screen door so that people can't just wander in
>and steal things from you. Anybody who really wants to steal your stuff can
>just pull out a big knife (object code debugger), cut your screen out of its
>frame (disassemble your code, put a patch around the license key check part),
>and walk in and steal you blind. Count on this scheme to keep honest people
>honest, not to be a fail-safe anti-theft device.
You make it sound difficult. At some point the program performs a check
of the serial to see if it is correct. Swapping one instruction from "je"
to one "jne"(or vice versa) reverses the results of the check, and the
"super-dooper-secret multiple-level MD5 checksum scattered around the code
so the hackers would need months to sort it out and create a fake key" is
nullified in 5 minutes because any FAKE key becomes an actual key to the
program. Then the only way it would fail is if the user guessed an actual
key, and in that unlikely event, the user just changes a character in the
fake key. Program registered.
Locks keep honest people honest.
Best Wishes,
Johnny Bravo
------------------------------
From: [EMAIL PROTECTED] (Vernon Schryver)
Subject: Re: Wireless PKI now or later
Date: 31 Jan 2000 12:19:19 -0700
In article <[EMAIL PROTECTED]>,
Lassi Hippeläinen <"lahippel$does-not-eat-canned-food"@ieee.org> wrote:
>AFAIK, the WAP developers are thinking seriously about PKI. They are not
>reinventing the wheel....
The consensus among people who know enough technical stuff about the
Internet to talk much in IETF circle seems to be that the WAP developers
are in fact busy re-inventing wheels, and amazingly badly.
Feel free to attribute that to sour grapes from a standards committee
that feels snubbed. That's what I do, but I also find the technical
criticisms of WAP plausible, and think the WAP developers felt snubbed
by existing standards committees that say "why not use our existing
standards X, Y, and Z instead of starting over?" Industry consortia
have often been formed in response to such expressions of enthusiasm
for new ideas from people without a clue about the old ideas. The
resulting consortia often go away and to re-invent the entire universe,
but with properly square wheels to fit their special situations.
See also the recent ad hoc advice for content providers for dealing with
real life WAP clients.
Vernon Schryver [EMAIL PROTECTED]
------------------------------
Subject: Re: How to password protect files on distribution CD
From: lordcow77 <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp,comp.security.unix,comp.security
Date: Mon, 31 Jan 2000 12:39:43 -0800
In article <[EMAIL PROTECTED]>, Johnny
Bravo <[EMAIL PROTECTED]> wrote:
> You make it sound difficult. At some point the program
performs a check
>of the serial to see if it is correct. Swapping one
instruction from "je"
>to one "jne"(or vice versa) reverses the results of the check,
and the
>"super-dooper-secret multiple-level MD5 checksum scattered
around the code
>so the hackers would need months to sort it out and create a
fake key" is
>nullified in 5 minutes because any FAKE key becomes an actual
key to the
>program. Then the only way it would fail is if the user
guessed an actual
>key, and in that unlikely event, the user just changes a
character in the
>fake key. Program registered.
>
The standard approach is easily defeated, but a routine whereby
a valid serial number generates a key stream that decrypts a
function pointer table on the fly will be significantly more
involved to crack that changing the result of a cmp.
* Sent from RemarQ http://www.remarq.com The Internet's Discussion Network *
The fastest and easiest way to search and participate in Usenet - Free!
------------------------------
From: [EMAIL PROTECTED] (Steven Siew)
Subject: Re: Is there a practical guide to using crypto?
Date: 30 Jan 2000 12:25:28 GMT
Reply-To: [EMAIL PROTECTED]
=====BEGIN PGP SIGNED MESSAGE=====
Hash: SHA1
John,
Now you are talking in an intelligent manner. Yes this is a big
problem for cryptography. A big big problem. Here is why.
Most password are less than 10 keystrokes and they consist either of
1) 26 lowercase characters
2) 36 lowercase characters or digits
3) 62 alphanumeric characters
4) 95 printerable chracters
5) 128 official ASCII characters
6) 256 chracters
Assuming the user uses exactly 10 keystrokes. Then for the case of
1) 26^10 is 1.411E14
Comment: This is chicken shit security. Expect it to be broken in a
minute (using 1000 computers)
2) 36^10 is 3.656E15
Comment: This is still bad. Expect it to be broken in 10 minutes
3) 62^10 is 8.393E17
Comment: No good. Expect it to be broken in 4 days.
4) 95^10 is 5.987E19
Comment: Untrustworthy. Expect it to be broken in 300 days.
5) 128^10 is 1.18E21
Comment: Toleratable. Expect it to be broken in 16 years.
6) 256^10 is 1.2E24
Comment: Good! Expect it to be broken in 16000 years.
Now for the BAD news. The above is only true in the best case
situvation where the user choose password at random. Most user don't,
they choose passwords like "bigcat9" or "suckmytoe", unless they use a
good password generator you are looking at case 2 or case 3.
The proper solution is to use passphases like
"There is no way to break into my computer without password" but some
encryption program may not accept spaces in passwords. Or worse the
user made a type and then hit the backspace key. You get the idea.
I hope this make it clearer to you. There is no SIMPLE solution to
preventing password cracking apart from using random generated
passwords with lots of chracters (more than 10).
STeven Siew
In article <[EMAIL PROTECTED]>, JCardinal wrote:
>I'm sorry Douglas, I don't believe I've made myself very clear. I realize
>what your saying about the brute force method and yes it's in the faq and
>I'm quite familiar with the concept.
>
>What I was after, and this may just be my overall ignorance on the subject
>but here goes anyway:
>
>Is it not likely that when a casual user of a hypothetical encryption
>program sits down to encrypt a file, and it requires a 128bit key to encrypt
>something what they are really going to do is enter a password using a 16
>byte or shorter string of ascii or keyboard typeable characters to be used
>as their key?
>
>And if this is so then is it not fairly easy to try every possible key they
>might have typed to generate a password?
>
>Or, is it usual practice to somehow transform that password or act upon it
>so that it's not as simple as what I described.
>
=====BEGIN PGP SIGNATURE=====
Version: GnuPG v1.0.1 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD8DBQE4lC0FXZ8NVwemPIQRAsUHAJ9y5HOvklPW3fkOOY1QsbFFJSyX+QCgjN4m
2dZlyN7rYGjvu3uE5N8VBx8=
=otW4
=====END PGP SIGNATURE=====
------------------------------
** 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
******************************
