Cryptography-Digest Digest #76, Volume #11 Tue, 8 Feb 00 21:13:01 EST
Contents:
Re: Quicken (was Re: Strip Security) (Michael Wojcik)
Re: permission to do crypto research (Jerry Coffin)
Re: permission to do crypto research ("Jeffrey B. Siegal")
A query method for communications ... ("Markku J. Saarelainen")
Re: Compression cannot prevent plaintext recognition (was Re: is signing a
signature with RSA risky?) ("Joseph Ashwood")
Re: permission to do crypto research ("Jeffrey B. Siegal")
Re: Blowfish Question ("Chung W Leong")
Language Challenge 2000 ([EMAIL PROTECTED])
Re: Seeking Information on FRACTAL CRYPTOGRAPHY (Tom St Denis)
Re: Message to SCOTT19U.ZIP_GUY (Tom St Denis)
Re: permission to do crypto research (Bill Unruh)
Re: free C crypto API (Tom St Denis)
Re: DVD crypt Q (Bill Unruh)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Michael Wojcik)
Subject: Re: Quicken (was Re: Strip Security)
Date: 8 Feb 2000 23:38:10 GMT
Reply-To: [EMAIL PROTECTED]
In article <[EMAIL PROTECTED]>, David Hopwood <[EMAIL PROTECTED]>
writes:
> Michael Wojcik wrote:
> > [re Quicken servers configured for stupidly small passwords]
> > There doesn't appear to be any locally stored key, and there's no
> > evidence during account creation that Quicken is gathering entropy
> > for a crypto-secure PRNG. Actually, I can't see any way there could
> > be a hidden key: Quicken can be installed on another computer and
> > the account access enabled from there with only the four-digit
> > passphrase. There's no mechanism for transporting a hidden key.
> Oh dear. Anyone want to bet that this can be broken just by sniffing
> a *single* session and doing an off-line attack? I don't know precisely
> what protocol Quicken uses, but if it's just RSA authenticated by the
> PIN, it won't be secure against this.
I was thinking of older versions of Quicken, which used direct
dial-up to the server, making sniffing rather less likely. (Anyone
with enough money in their checking account to justify tapping
their phone line and recording their Quicken session probably isn't
using Quicken.)
More recent versions of Quicken do indeed use TCP/IP as their
transport, making sniffing attacks much more likely. It's
possible that Quicken is using SSL, but again I don't see any
evidence of it.
> > Hopefully, Quicken servers lock account access after a certain (small)
> > number of access failures, which makes this kind of brute forcing
> > impractical.
> That may not be enough.
No, if the session can be recorded.
I agree completely. Generally speaking, the short passwords required
by some Quicken servers are sooner or later going to be used in an
environment where they're subject to attack. If the session isn't
sniffed, someone else will get hold of the computer and turn on
Winsock tracing or Quicken's own session logging or the like. Access-
failure lockout is only a defense against the most trivial and obvious
brute-forcing.
--
Michael Wojcik [EMAIL PROTECTED]
AAI Development, MERANT (block capitals are a company mandate)
Department of English, Miami University
Pseudoscientific Nonsense Quote o' the Day:
From the scientific standpoint, until these energies are directly
sensed by the evolving perceptions of the individual, via the right
brain, inner-conscious, intuitive faculties, scientists will never
grasp the true workings of the universe's ubiquitous computer system.
-- Noel Huntley
------------------------------
From: Jerry Coffin <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto,misc.int-property,misc.legal.computi
Subject: Re: permission to do crypto research
Date: Tue, 8 Feb 2000 17:51:25 -0700
In article <87q97u$nlp$[EMAIL PROTECTED]>, [EMAIL PROTECTED]
says...
[ ... ]
> You'll just be able to take the digital output of your
> future DVD player, that would normally hook up to your future
> digital TV, plug it into your future computer and save the feed.
"future"? Quite a few DVD players have digital outputs right now.
You don't have to wait for a fast digital input on your computer to
use it for pirating either: it'll feed a current digital VCR.
> Why muck about with decryption software?
Good question...better than you apparently realized.
> Sure: just because it now runs on Windows doesn't mean it wasn't
> _intended_, by its creator, for watching DVDs on Linux.
For that matter, why should one particular company be given a monopoly
over players on Windows? I happen to think the XING player is
disgusting...
--
Later,
Jerry.
The universe is a figment of its own imagination.
------------------------------
From: "Jeffrey B. Siegal" <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto,misc.int-property,misc.legal.computing
Subject: Re: permission to do crypto research
Date: Tue, 08 Feb 2000 16:58:42 -0800
Jerry Coffin wrote:
> For that matter, why should one particular company be given a monopoly
> over players on Windows?
I suspect that even if the DMCA and trade secret arguments fail, there will
still be a patent-based monopoly on DVD players. So this may be a moot point.
------------------------------
From: "Markku J. Saarelainen" <[EMAIL PROTECTED]>
Crossposted-To: alt.politics.org.cia,alt.security,alt.2600
Subject: A query method for communications ...
Date: Wed, 09 Feb 2000 01:04:23 GMT
In the same way as you can use any search functions to find documents at
any web sites such as corporate, government and other sites, you can use
these same search functions to submit specific intelligence to those who
are reviewing any query logs and files. This can be a very handy method,
when you are communicating with embassies and other intelligence
customers and it is quite anonymous. Try it. Actually works great !
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: Compression cannot prevent plaintext recognition (was Re: is signing a
signature with RSA risky?)
Date: Tue, 8 Feb 2000 17:06:49 -0000
The answer is a nice resounding maybe.
If your cipher chaining is based on having both an IV and a
Key going into a cipher seperately (the chaining is actually
built into the cipher, something that to my knowledge is not
the current state of things) then it is possible that doing
such could increase security by a large factor. However if
the cipher takes simply a key which has been altered outside
of the algorithm to accomodate a chaining method then the
answer is no. An attack on the system would simply have to
find the chaining method used and solve at most (for the
chaining methods that come to mind) 2 blocks, invert the
combining function (typically a vigenere cipher) and the key
presents itself, you will have in effect only doubled the
break time, and this is just an initial attack ( < 1 minute
to develop).
Joe
"Terje Mathisen" <[EMAIL PROTECTED]> wrote in
message news:[EMAIL PROTECTED]...
> John Savard wrote:
> > Compression can make plaintext recognition more
difficult.
> >
> > That is all that can be legitimately claimed for it, and
it is enough
> > to make compression worth doing for an additional
reason, and enough
> > to motivate carefully tailoring compression to its
intended
> > application - getting rid of headers and the like.
> >
> > To prevent plaintext recognition, I would suggest, after
compression,
> > a pre-encryption step having these characteristics:
> >
> > - it involves transposing bytes within (large chunks of)
the message,
> >
> > - it has a larger key than that of the "real" encryption
> >
> > - it is not computationally intensive
> >
> > - it produces unbiased output
>
> Would it be possible to simply use something like pkzip on
the input
> data, split the result into <block-size> (128 bits?) and
then reverse
> the order of the blocks, before encrypting them using
chaining?
>
> This would at least get rid of the known zip header,
making a search for
> known plaintext harder, right?
>
> Terje
> --
> - <[EMAIL PROTECTED]>
> Using self-discipline, see
http://www.eiffel.com/discipline
> "almost all programming can be viewed as an exercise in
caching"
------------------------------
From: "Jeffrey B. Siegal" <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto,misc.int-property,misc.legal.computing
Subject: Re: permission to do crypto research
Date: Tue, 08 Feb 2000 17:07:59 -0800
David Wagner wrote:
> Remember, the industry claimed in their legal briefs that the DVD CCA
> "is suffering and will continue to suffer immediate and irreparable harm",
> unless the truth is immediately banned. (They also said, for instance,
> that DeCSS "will likely mean the end of this California business".)
>
> Even if we offer them the benefit of the doubt here, these types of statements
> appear thoroughly insupportable.
Not at all. Although they make reference to the overall motion picture
industry, this particular statement refers to the DVD CCA itself. The DVD CCA
exists specifically for the purpose of controlling restrictive DVD decoding
technology. The uncontrolled availability of such technology most likely
would mean the end of the DVD CCA, at least in its present form.
A better question is why anyone should care.
------------------------------
From: "Chung W Leong" <[EMAIL PROTECTED]>
Subject: Re: Blowfish Question
Date: Tue, 8 Feb 2000 17:20:27 -0800
Thanks for all the replies.
Perfect security is, of course, difficult if not impossible to achieve in a
development environment. Our client's e-commence business changes overtime.
New developers get involved and they all need access to the database.
Encrypting the most sensitive data in the backend just makes it easier for
us to grant access privilege. Instead of guarding both the database and web
server, we took the former out of the equation, which I think makes the
endeavor worthwhile. The fact that the credit card numbers do not travel as
plain-text across any wire should be considered as well...
...on the other hand, it just occur to me that the encryption scheme is
rather futile. Since credit card numbers have far less entropy than the
encryption key, one can just brute-force against that. Hmmm...even
encrypting the cardholder's name doesn't add too much entropy. I mean in a
large database you always have enough people with common enough names.
Hmmm...I guess if the database is compromised, then the users' info is
compromised. Crap.
"Shawn Willden" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Eric Lee Green wrote:
>
> > Shawn Willden wrote:
> > > Chung W Leong wrote:
> > >
> > > > Even if you have control over the original text, analyzing the
resulting
> > > > encrypted text would still yield no information (even or odd,
divisibility,
> > > > the number of 1s and 0s, tendency, attitude, psychological state)
about the
> > > > secret key? What if you have multiple (say 1000) original-encrypted
text
> > > > pairs?
> > > > My firm is currently working on a e-commerce site, where we're
planning to
> > > > encrypt the credit card numbers of customers with Blowfish before
storing
> > > > them into the database, in case the security of the database is
compromised.
> > >
> > > A good way to characterize the assumptions used in cryptanalytic
attacks on
> > > algorithms is as follows:
> > >
> > > Assume that the attacker has full details of the design and
implementation of
> > > the algorithm. Further, assume that the attacker has access to an
"oracle", a
> > > device that will encrypt and decrypt anything the attacker wants,
using a key
> > > that is *not* known to the attacker. Assume that the attacker has the
time,
> > > interest and ability to perform a very large number of computations,
up to, but
> > > not including, 2^n, where n is the key size in bits (i.e. assume that
the
> > > attacker can't mount a brute force attack, but can get close).
> > >
> > > Under those assumptions, the algorithm is weak if:
> > You forgot one other thing: the algorithm is weak if the SYSTEM is weak.
I.e.,
> > if the key can be obtained without the need to "crack" the algorithm.
>
> I'm rather impressed with myself if that's all I forgot :-)
>
> I agree completely. The original poster was only asking about the
algorithm, so my
> response only dealt with the algorithm, but it would have been good to
mention that
> the algorithm is only one small (though important) piece of a system.
>
> > In the previous example of encrypting credit card numbers prior to
> > placing them into the database, this is only reasonable if you assume
that the
> > machine doing the encrypting/decrpyting is not compromised.
>
> Yep. To counter this effectively requires physical and network security
at the
> least. I'd recommend a host security module (HSM) for key storage and
encryption
> operations -- one that allows multiple levels of functionality to be
activated by
> different passphrases, plus careful design of the applications that use
the HSM and
> careful control of the passphrases. On top of that, I'd recommend
thorough audit
> logging and auditing of the system and the logs. And did I mention
physical and
> network security?
>
> Shawn.
>
>
>
>
------------------------------
From: [EMAIL PROTECTED]
Subject: Language Challenge 2000
Date: Tue, 08 Feb 2000 17:30:26 -0800
Language Challenge 2000
The entire onboard software for the Apollo Lunar Landing Mission was
about 10% the size of today's typical word processor -- a huge regress
by any standard. For a measure of progress in scientific software you
are invited to participate in a comparative test by solving a real world
problem in the language of your choice.
Find the optimal initial angle for a trajectory to reach a target at
2000 m to within 0.5 m. The equations of motion are given by,
mx" + Dcos(alfa) = 0
my" + Dsin(alfa) + mg = 0
where
D = .5*Cd*A*rho(y)*v^2 alfa = atan(y'/x')
and rho() is true atmospheric density varying with altitude.
Parameters: m = 20 kg Cd = .3 A = .02 m^2 g = 9.80665 m/s^2
Initial values: x = 0 m y = 0 m v = 180 m/s alfa = 40 deg
Rules: Solution must be general; trial and error methods based on
apriori knowledge of the solution range do not qualify. Feel free to use
external software resources as well as the "Trajectory" example on our
"Application profiles" page as a convenient guideline.
Criteria:
a) Execution time
b) Size of executable
Submit: Executable module (show final angle and distance), main program
text file and indicate the integration and optimization algorithms used.
e.g. Levenberg-Marquardt (netlib). All entries must be received by March
31, 2000.
The best entry in each language will be posted on our site to serve as a
barometer for those pondering what language to choose for their
technical computing. It might also double as a place where flame war
enthusiasts can calibrate their rhetoric against the realities of
feasible solutions. The overall winner will receive:
Compaq Visual Fortran V6.1 -- Professional Edition
Provided courtesy of Compaq
SDX Modeling and Simulation Software V3.0
as recognition for demonstrated skills in crafting the fastest solution
with a smallest footprint.
Questions regarding the contest should be directed to [EMAIL PROTECTED]
with Contest 2000 in the "Subject" line.
===============================================
Modeling * Simulation * Analysis
http://www.sdynamix.com
===============================================
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Seeking Information on FRACTAL CRYPTOGRAPHY
Date: Wed, 09 Feb 2000 01:36:38 GMT
In article <Pine.A41.4.10.10002072018340.61218-
[EMAIL PROTECTED]>,
"M. Hackett" <[EMAIL PROTECTED]> wrote:
>
> I am seeking information on FRACTAL CRYPTOGRAPHY -- patents, programs
and
> / or otherwise available on the Internet.
>
> Send me any links or information that you may find, as I am having
some
> trouble assimilating this info.
>
> MP
>
If I am not mistaken a fractal is simply a object that can self-
represent itself to infinite detail. I.e the mandelbrot.
How do you think this would be applied to crypto? And did you hear
this on star trek?
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Message to SCOTT19U.ZIP_GUY
Date: Wed, 09 Feb 2000 01:41:32 GMT
In article <87q0bu$23lg$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (SCOTT19U.ZIP_GUY) wrote:
> I am sorry I still don't remember the context in which my above
comment was
> written. It may have been in response to someone elses proposal. I
don't have
> an iron clad memmory. However numerous times I have complianed about
the
> weakness designed into the AES systems so that the NSA will be able
to read
> messages encrypted with plain vanilla AES and the weak 3 letter
chaining mods
> that the NSA pushes.
> The above may have been do to some one wanting to use a weak AES
method
> for encryption and yet still add features that almost make it an "all
or
> nothing" encryption system. But I wll try to answer that today even
though
> yesterday I may have given a different anwser. If I was stuck using
AES I
> would first compress a message with my one a one compression program
or
> Matt's bijective arithmetic compression. Than I would use the AES
encryption
> with at least 3 passes using "wrapped PCBC". If I didn't know how to
do the
> wrapped PCBC I would after the first encryption pass use my
uncompress and
> reverse the file then compress again and do another AES encryption
and maybe
> even repeat the last few steps a few times. But one still has to be
very
> careful about how one uses the AES so that the NSA can't solve each
layer
> independently.
> Actually I would not trust AES so at least one of the encryption
passes
> should be done with GVA or scott16u or something else.
Although you have bitched about stuff you don't know, you have yet to
prove ANY of your claims.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (Bill Unruh)
Crossposted-To: talk.politics.crypto,misc.int-property,misc.legal.computi
Subject: Re: permission to do crypto research
Date: 9 Feb 2000 01:59:36 GMT
In <[EMAIL PROTECTED]> lcs Mixmaster Remailer
<[EMAIL PROTECTED]> writes:
]With DeCSS, it is possible to copy DVD movies to ordinary disk or tape
]drives and play them with software players. They could be uploaded to
]the Internet and shared as MP3 songs are shared today. From one disk,
]potentially thousands of digital copies could be made and shared, at
]no cost.
Yes. And? That is adequately prevented by current laws. Should we also
ban the internet because it could be used to create copyright
infringement? Should we ban ftp? or any other "tool".
Copyright is a monopoly granted by the state to certain people with
certain remedies. If those people wish to institute further protections
it is certainly their right by why should society add to their monopoly?
If they are unable or unwilling to shoulder the burden of protecting
their own monopoly why should I as a taxpayer be forced to do it for
them? It is their incompetence which has led to this state. Is the
governments job now to protect big business from their own incompetence?
]Of course, today this is not feasible, because DVD movies are too large
]to be conveniently sent around the net. You can do it, but you have to
]compress them so much that the quality is greatly reduced. But in a few
]years it is likely that storage capacity and bandwidth will increase so
]that much bigger files can be handled. At some point DVD piracy via DeCSS
]and similar tools has the potential to become a very serious problem.
And you could do it even without this. As has been pointed out ad
nausium, this whole business does not prevent DVDs from being copied,
just from being played. The ability to read the whole CDRom into memory
and then play it from memory via a player is already there. The only
thing this protects is the player manufacturers.
]Given the inevitability of increases in bandwidth and storage, isn't
]it reasonable to view DeCSS as a piracy tool?
Given the inevitability of incompentence being found out, isn;t it
reasonable to regard DeCSS as just that?
]BTW, one of the arguments in favor of this view advanced by the plaintiffs
]was the fact that DeCSS is available on Windows, where there are already
]many DVD-playing programs available. Why else would it be designed to
]run on that architecture, other than for piracy, they asked? The claim
The fact that some people ported it to Win is irelevant. That was a
separate issue.
pl
]that DeCSS exists only to allow Linux users to watch movies was demolished
](in the judge's eyes) by this observation! Anyone care to comment?
Either the judge or the defence lawyers were myopic then. The fact that
the tool exists and was developed for linux is not altered by the fact
that someone else then ported that tool to Windows.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: free C crypto API
Date: Wed, 09 Feb 2000 01:45:42 GMT
In article <[EMAIL PROTECTED]>,
Runu Knips <[EMAIL PROTECTED]> wrote:
> Tom St Denis wrote:
> > In article <[EMAIL PROTECTED]>,
> > Runu Knips <[EMAIL PROTECTED]> wrote:
> > > Tom St Denis schrieb:
> > > > In article <862jhk$ohd$[EMAIL PROTECTED]>,
> > > > Greg <[EMAIL PROTECTED]> wrote:
> > > > > > Well I decided to release CB a bit early. I am looking for
> > > > > > comments/suggestions/improvements.
> > > > > > Basically CB is a complete crypto API. It can make/use RSA
crypto,
> > > > > > symmetric crypto, has data compression, a RNG, base64
routines and
> > > > > > more. [...]
> > > > > > All of this is free!!!
> > > > >
> > > > > I downloaded a copy of your stuff and noticed that you did not
> > > > > ask me anything. Where is the server located?
> > > >
> > > > I will not dignify that. I was hoping for real discussion about
> > > > working on CB [i.e bugs or what have not]. This group has some
of
> > the
> > > > smartest people in the world yet they can't stay on task.
> > > > Did you have any troubles building CB on your computer?
> > >
> > > No problems with VC++ 5.0 under Windows. Will check gcc/linux at
> > > home. And I've seen worser cryptographical libaries before.
> > > However, many of this stuff is from other people, plus, for
> > > example, IDEA is patented and can't be used for free. But has
> > > a twofish implementation, too. Very good, so I can drop IDEA
> > > anyway :)
> > >
> > I am glad you like it. Please note that the current version up
there
> > has some bugs in it. Small glitches... I have been working on it
> > locally and plan to upload it again soon. In the mean time you can
> > still look at it and play around.
> >
> > [EMAIL PROTECTED]
>
> Where easy to compile this stuff under Linux. Had to strip
> CR, create an unix makefile and remove 3 includes in idea.h.
Cool, if you can send me the unix makefile I will include it in the
next release. I have this week off so I want to touch it up. I have
been meaning todo this for a bit.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (Bill Unruh)
Crossposted-To: rec.video.dvd.tech
Subject: Re: DVD crypt Q
Date: 9 Feb 2000 02:05:11 GMT
In <[EMAIL PROTECTED]> [EMAIL PROTECTED]
(Troed) writes:
>>2) Why is authentication neccessary? I remember (maybe wrong)
>>someone mentioning that some part of a DVD is not readable until the
>>user authenticate with the drive. Is this true?
Becasue the manufacturers do not want you playing DVDs on anything but
their authorised equipment. And that equipment will only play DVDs
encoded for that equipment (allowing them to release a DVD in the USA
unpolayable in Japan for example)
>>3) Why would the DVD-ROM need decryption key when decryption is done
>>by separate hardware/software? Maybe I am misunderstanding, but if
>>decryption is done by the drive, then wouldn't something like DeCSS be
>>unneccessary?
Because it is encrypted with one single key, but the access of the
player is controlled since that key-- specific to the DVD is encoded
again by the player's key, as I understand it.
------------------------------
** 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
******************************
