Cryptography-Digest Digest #243, Volume #12 Tue, 18 Jul 00 12:13:01 EDT
Contents:
Re: WSJ Article on Mexico / Encryption (Arturo)
Re: MD2 (Mark Wooding)
Re: Win2000 Encryption ("Adam Pridmore")
Re: "standalone" java implementation of blowfish or twofish (Paul Rubin)
Re: "standalone" java implementation of blowfish or twofish (Runu Knips)
Re: "standalone" java implementation of blowfish or twofish (Paul Rubin)
CHES 2000 Program (Christof Paar)
Re: Question Regarding Encrypting CD-ROM -RW Disks (Daniel James)
Re: "standalone" java implementation of blowfish or twofish ("Gregory Stark")
Re: Carnivore and Man-in-the-middle (phil hunt)
Re: Good free stream cipher ? (Mok-Kong Shen)
Re: Crypto analyze tool. (JPeschel)
Re: Crypto analyze tool. ([EMAIL PROTECTED])
Re: Crypto analyze tool. (Jim Gillogly)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED]=NOSPAM (Arturo)
Subject: Re: WSJ Article on Mexico / Encryption
Date: Tue, 18 Jul 2000 09:20:37 GMT
On Fri, 14 Jul 2000 12:30:03 +0200 (CEST), Nomen Nescio <[EMAIL PROTECTED]>
wrote:
>Did anyone catch the front page of the Wall Street Journal
>yesterday (7-13-2000). They mentioned in a follow up article
>that the 'leftist' party had cracked the encryption on a report
>that had come into their hands from the ruling party detailing
>who got paid off in some bailout.
>
>There had been an earlier article, several weeks ago that the
>decryption was being attempted.
>
>Does anyone know any more details about this?
I saw two papers about it at cryptome (http://cryptome.org)
------------------------------
From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: MD2
Date: 18 Jul 2000 10:22:04 GMT
Daniel Leonard <[EMAIL PROTECTED]> wrote:
> Does anyone have any papers or links related to the MD2 message digest
> algorithms.
>
> I know about RFC 1319, so do not send this link. I am looking for critics
> and attacks.
A squint at David Hopwood's SCAN site[1] hauls up the following
references:
[Def, Impl, Test] Burt Kaliski,
"The MD2 Message-Digest Algorithm,"
RFC 1319, April 1992.
[Inf] Bruce Schneier,
"Section 18.6 MD2,"
Applied Cryptography, Second Edition, John Wiley & Sons, 1996.
[An] RSA Laboratories Security Bulletin #4,
ftp://ftp.rsa.com/pub/pdfs/bulletn4.pdf
[An] N. Rogier, P. Chauvaud,
"The compression function of MD2 is not collision-free,"
Workshop record, 2nd Workshop on Selected Areas in Cryptography (SAC
'95), Ottowa, Canada, May 18-19 1995.
The RSA bulletin isn't ever-so interesting, if memory serves.
[1] http://www.users.zetnet.co.uk/hopwood/crypto/scan/intro.html -- very
useful.
-- [mdw]
------------------------------
From: "Adam Pridmore" <[EMAIL PROTECTED]>
Subject: Re: Win2000 Encryption
Date: Tue, 18 Jul 2000 11:29:11 +0100
"Volker Hetzer" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Mack wrote:
> >
> > Greg [EMAIL PROTECTED] wrote:
>
> > >And what is more odd is that there is no password provided to me.
> >
> > Should be the same as the password for your user name.
> You mean Win2000 stores the password in a retrievable form???
>
This again is a security setting in Win2k (retrievable/non-retrievable
passwords).
So I don't know quite what it uses for encryption if they are stored
as some kind of hash.
------------------------------
From: [EMAIL PROTECTED] (Paul Rubin)
Crossposted-To: comp.lang.java.security,comp.security.misc
Subject: Re: "standalone" java implementation of blowfish or twofish
Date: 18 Jul 2000 10:51:01 GMT
In article <[EMAIL PROTECTED]>, Runu Knips <[EMAIL PROTECTED]> wrote:
>[EMAIL PROTECTED] wrote:
>> Does anyone know where I could locate a *small" java program which
>> implements CBC and some kind of padding? Any hints or links would be
>> greatly appreciated.
>
>But implementing CBC is absolutely trivial ??? The only problem is
>to get a good IV, but Java has some buildin classes for
>cryptographically strong random (even if the main requirement for
>IV's is their uniqueness, not their randomness).
IV's don't have to be cryptographically strong--there just has to be
not much chance of using the same one twice. In a browser applet,
taking the current date/time and hashing it with the client IP address
and stuff like that should be good enough.
Generating *keys* has to be cryptographically strong. If you have to
generate keys on the client side in the applet, I don't know any
really satisfactory ways to do it.
------------------------------
Date: Tue, 18 Jul 2000 13:20:35 +0200
From: Runu Knips <[EMAIL PROTECTED]>
Crossposted-To: comp.lang.java.security,comp.security.misc
Subject: Re: "standalone" java implementation of blowfish or twofish
Paul Rubin wrote:
> In article <[EMAIL PROTECTED]>, Runu Knips <[EMAIL PROTECTED]> wrote:
> >[EMAIL PROTECTED] wrote:
> >> Does anyone know where I could locate a *small" java program which
> >> implements CBC and some kind of padding? Any hints or links would be
> >> greatly appreciated.
> >
> >But implementing CBC is absolutely trivial ??? The only problem is
> >to get a good IV, but Java has some buildin classes for
> >cryptographically strong random (even if the main requirement for
> >IV's is their uniqueness, not their randomness).
>
> IV's don't have to be cryptographically strong--there just has to be
> not much chance of using the same one twice.
Thats what I've said.
But because you can't know what other programs, possibly on other hosts,
have used iv's before using an unpredictable random source is IMHO the
best choice.
> In a browser applet, taking the current date/time and hashing it with
> the client IP address and stuff like that should be good enough.
Yep thats not too bad, either.
> Generating *keys* has to be cryptographically strong. If you have to
> generate keys on the client side in the applet, I don't know any
> really satisfactory ways to do it.
As I already said, AFAIK there are java classes which already offer
that.
------------------------------
From: [EMAIL PROTECTED] (Paul Rubin)
Crossposted-To: comp.lang.java.security,comp.security.misc
Subject: Re: "standalone" java implementation of blowfish or twofish
Date: 18 Jul 2000 11:41:01 GMT
In article <[EMAIL PROTECTED]>, Runu Knips <[EMAIL PROTECTED]> wrote:
>> Generating *keys* has to be cryptographically strong. If you have to
>> generate keys on the client side in the applet, I don't know any
>> really satisfactory ways to do it.
>
>As I already said, AFAIK there are java classes which already offer
>that.
There's the SecureRandom class, but it's very slow and I'm skeptical
of its security. You can do stuff like ask the user to type random
characters or wave the mouse around on the screen, but that's a pain
in the neck for the user. Do you know of something else?
------------------------------
From: Christof Paar <[EMAIL PROTECTED]>
Crossposted-To: comp.arch.arithmetic,comp.arch.fpga
Subject: CHES 2000 Program
Date: Tue, 18 Jul 2000 07:30:15 -0400
PRELIMINARY SCHEDULE
CHES 2000
=======================================================
Workshop on Cryptographic Hardware and Embedded Systems
Worcester Polytechnic Institute
Worcester, Massachusetts, August 17-18, 2000
http://ece.wpi.edu/Research/crypt/ches
for registration information, check CHES web site above
=======================================================
=============== WEDNESDAY, AUGUST 16th ==============
5:00 - 10:00 pm REGISTRATION AND RECEPTION
Atwater Kent Building, WPI
(Shuttle Service will be provided between WPI and the Crowne Plaza Hotel)
=============== THURSDAY, AUGUST 17th ===============
7:00 - 8:45 am REGISTRATION AND CONTINENTAL BREAKFAST
Atwater Kent Building, WPI
(Shuttle Service will be provided between WPI and the Crowne Plaza Hotel)
8:45 - 9:15 am WELCOME
Welcome by Jack Carney (Provost, WPI)
Introductory remarks by Cetin Koc and Christof Paar
9:15 - 9:55 am INVITED TALK
Alfred Menezes, University of Waterloo, Canada
Elliptic curve cryptography in constrained environments.
9:55 - 10:55 am IMPLEMENTATION OF ELLIPTIC CURVE CRYPTOSYSTEMS
S. Okada, N. Torii, K. Ito, and M. Takenaka.
Implementation of elliptic curve cryptographic coprocessor over GF(2^m) on FPGA.
G. Orlando and C. Paar.
A high-performance reconfigurable elliptic curve processor for GF(2^m).
J. W. Chung, S. S. Gyoo, and L. P. Joong.
Fast implementation of elliptic curve defined over GF(p^m) on CalmRISC with
MAC2424 coprocessor.
10:55 - 11:15 am BREAK
11:15 - 12:35 pm POWER AND TIMING ANALYSIS ATTACKS
A. Shamir.
Protecting smart cards from passive power analysis with detached power supplies.
R. Mayer-Sommer.
Smartly analyzing the simplicity and the power of simple power analysis on
Smartcards.
M. A. Hasan.
Power analysis attacks and algorithmic approaches to their countermeasures for
Koblitz curve cryptosystems.
W. Schindler.
A timing attack against RSA with the Chinese Remainder Theorem.
12:35 - 2:00 pm LUNCH
2:00 - 3:20 pm HARDWARE IMPLEMENTATION OF BLOCK CIPHERS
A. Dandalis, V. K. Prasanna, and J. D. P. Rolim.
A comparative study of performance of AES final candidates using FPGAs.
C. Patterson.
A dynamic FPGA implementation of the Serpent Block Cipher.
S. Trimberger, R. Pang, and A. Singh.
A 12 Gbps DES Encryptor/Decryptor core in an FPGA.
H. Leitold, W. Mayerwieser, U. Payer, K. C. Posch, R. Posch, and J.
Wolkerstorfer.
A 155 Mbps triple-DES network encryptor.
3:20 - 3:40 pm BREAK
3:40 - 5:00 pm HARDWARE ARCHITECTURES
J. Goodman and A. Chandrakasan.
An energy efficient reconfigurable public-key cryptography processor
architecture.
J. Groszschaedl.
High speed RSA hardware based on dynamic true single phase clocked logic.
C. Walter.
Data integrity in hardware for modular arithmetic.
T. Kato, S. Ito, J. Anzai, and N. Matsuzaki.
A design for modular exponentiation coprocessor in mobile telecommunication
terminals.
6:00 - 9:00 pm BANQUET
=============== FRIDAY, AUGUST 18TH ==============
8:00 - 9:00 am REGISTRATION AND CONTINENTAL BREAKFAST
Atwater Kent Building, WPI
(Shuttle Service will be provided between WPI and the Crowne Plaza Hotel)
9:00 - 9:40 am INVITED TALK
David Naccache, Gemplus, France.
How to explain side channel leakage to your kids.
9:40 - 10:40 am POWER ANALYSIS ATTACKS
J.-S. Coron and L. Goubin.
On Boolean and arithmetic masking against differential power analysis.
T. S. Messerges.
Using second-order power analysis to attack DPA resistant software.
C. Clavier, J.-S. Coron, and N. Dabbous.
Differential power analysis in the presence of hardware countermeasures.
10:40 - 11:00 am BREAK
11:00 - 12:00 pm ARITHMETIC ARCHITECTURES
H. Wu.
Montgomery multiplier and squarer in GF(2^m).
E. Savas, A. F. Tenca, and C. K. Koc.
A scalable and unified multiplier architecture for finite fields GF(p) and
GF(2^m).
G. Hachez and J.-J. Quisquater.
Montgomery exponentiation with no final subtraction: Improved results.
12:00 - 1:30 pm LUNCH
1:30 - 2:10 pm PHYSICAL SECURITY AND CRYPTANLYSIS
S. H. Weingart.
Physical security devices for computer subsystems: A survey of attacks and
defenses.
T. Pornin and J. Stern.
Software-Hardware Trade-offs: application to A5/1 Cryptanalysis.
2:10 - 2:50 pm NEW SCHEMES AND ALGORITHMS
J. Hoffstein and J. Silverman.
MiniPASS: Authentication and digital signatures in a constrained environment.
M. Joye, P. Paillier, and S. Vaudenay.
Efficient generation of prime numbers.
------------------------------
From: Daniel James <[EMAIL PROTECTED]>
Subject: Re: Question Regarding Encrypting CD-ROM -RW Disks
Date: Tue, 18 Jul 2000 12:54:32 +0100
Reply-To: [EMAIL PROTECTED]
In article <[EMAIL PROTECTED]>, wrote:
> My question is, given the nature of CDs, which, I understand, is not a
> magnetic medium, can these encryption programmes be used with them in
> the same way that they can be with diskettes, etc? Are there any
> problems in using these forms of encryption with CDs that are
> different than with the older media?
Now, I'm not familiar with the programs you mention (except PGP, of course),
and I don't know how you use them with magnetic media. It may be that what
you're doing now is to write the data in clear onto a diskette and then to
encrypt the data in situ on the diskette; you won't be able to work that way
with a CD because once the clear data is written you can't change it (sorry
if this is obvious).
However there's nothing inherently different about CD media that prevents you
from storing encrypted data on the disk. You should be able to encrypt your
data, compress it, jumble it up in any way you like, and then write it to
CD-R or CD-RW without problems. The important thing is that you must prepare
an encrypted CD image on your hard disk and then burn that image onto the CD,
you can't copy the data to CD and then encrypt it.
Cheers,
Daniel.
------------------------------
From: "Gregory Stark" <[EMAIL PROTECTED]>
Crossposted-To: comp.lang.java.security,comp.security.misc
Subject: Re: "standalone" java implementation of blowfish or twofish
Date: Tue, 18 Jul 2000 08:29:26 -0400
Check out http://www.acme.com/java/software/Package-Acme.Crypto.html and see
if it meets your needs.
--
Greg Stark, Chief Security Architect
Ethentica, Inc.
100 North Pointe Drive
Lake Forest, CA 92630
[EMAIL PROTECTED]
www.ethentica.com
<[EMAIL PROTECTED]> wrote in message news:8l18c6$bt2$[EMAIL PROTECTED]...
> Hello,
>
> I am writng a java applet which will be able to encrypt files
> either using blowfish or twofish. I have found (through
> counterpane.com) java implementations of both encryption algorithms,
> and would like to use them in my applet.
>
> However, the implementations are raw in the sense that no padding or
> CBC is applied. I need to have this added functionality, and am
> looking for a complete "standalone" java implementation of padding and
> CBC which I can use with the encryption algorithms.
>
> I cannot use a complete library such as "cryptix" because the code
> needs to be embedded in an applet and hence needs a small footprint,
> but cryptix is a very large package.
>
> Does anyone know where I could locate a *small" java program which
> implements CBC and some kind of padding? Any hints or links would be
> greatly appreciated.
>
> many thanks
>
> Bruce Sams
>
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
------------------------------
From: [EMAIL PROTECTED] (phil hunt)
Subject: Re: Carnivore and Man-in-the-middle
Date: Tue, 18 Jul 2000 15:25:47 +0100
Reply-To: [EMAIL PROTECTED]
On Tue, 18 Jul 2000 10:40:03 +0200 (CEST), Nomen Nescio <[EMAIL PROTECTED]> wrote:
>>> As most of you already know, the FBI has announced its intention to
>>> install the "Carnivore" packet-sniffing system in every ISP's data path,
>>> such that all traffic passing through that ISP can be sniffed by some
>>> Carnivore system. The stated purpose of this system is to snoop on the
>>> contents of suspected criminals' emails when permitted by judicial
>>> wiretap order.
>>
>> As I understand it, they intend to place it at particular ISPs when
>> they have a court order to intercept mail.
>
>I wonder if an ISP so-tagged would have the cojones to post a notice to
>that effect on its home page. Probably not. The feds would simple slap
>a gag-order on it similar to Britian's RIP.
>
>And so another Orwellian shoe drops. Ours is the last generation that will
>even have a memory of what privacy used to be.
Perhaps. IMO it's more likely that our generation will be the first to
know total freedom of speech.
--
***** Phil Hunt ***** send email to [EMAIL PROTECTED] *****
Moore's Law: hardware speed doubles every 18 months
Gates' Law: software speed halves every 18 months
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Good free stream cipher ?
Date: Tue, 18 Jul 2000 17:08:12 +0200
Runu Knips wrote:
> I'm looking for a good & free stream cipher algorithm.
> Does anybody have a suggestion ?
A number of the stream ciphers described in Schneier's book are free.
Whether such published ciphers, block or stream, are good, is in general
a tricky question in my humble view. Some gurus will give their advices.
But you have to believe them to some extent, I presume.
M. K. Shen
------------------------------
From: [EMAIL PROTECTED] (JPeschel)
Subject: Re: Crypto analyze tool.
Date: 18 Jul 2000 14:57:59 GMT
Raddum [EMAIL PROTECTED] writes:
>JPeschel wrote:
>
>> "Joseph Ashwood" [EMAIL PROTECTED] writes, in part:
>>
>> > Just to give you
>> >some idea of the complexities of analysis of ciphers, judging them on
>rounds
>> >doesn't work (RSA is secure with 1 round, DES takes several), you can't
>> >judge them on size (a Vigenere cipher can be gigabytes in size and still
>be
>> >weak...
>>
>> What do you mean by "a Vigenere cipher can be gigabytes in size:" the
>> Vigenere key? How do you propose breaking a Viggy that uses a key
>> of that size?
>
>Known plaintext attack?
Yeah, that should do it. I was wondering, however, whether
Ashwood thought a Vigenere with such a huge key was
vulnerable to a ciphertext-only attack.
Joe
__________________________________________
Joe Peschel
D.O.E. SysWorks
http://members.aol.com/jpeschel/index.htm
__________________________________________
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Crypto analyze tool.
Date: Tue, 18 Jul 2000 15:15:33 GMT
Hi again,
This was not suppose to be a analyze tool that decides whatever a
cipher is secure or not. Just a tool to provide an input/output based
analyze method that can be applied on different ciphers. The method
itself decides what output should be provided and if it is a batch or a
statistic tool with a single output.
This could later be expanded to also be able to provide output on other
events in the ciphers. Output after each round in a blockcipher. I
haven't thought that far yet.
Maybe my description was not the best. But thanks for the interesting
words.
/ foo
In article <#XeyijE8$GA.399@cpmsnbbsa08>,
"Joseph Ashwood" <[EMAIL PROTECTED]> wrote:
> Right now that idea isn't doable effectively. What you want to do is
> effectively equivalent to "Review this artwork for me" this is due to
the
> fact that cryptography isn't a true science yet, we haven't even
proven
> whether or not you can actually have a secure cipher whose key is
smaller
> than the document it's protecting.
>
> As for what fucntions should be in a tool, how about a function called
> howBadIsMySnakeOil(encryptFunc, decryptFunc, KeySize, minInputValue,
> maxInputValue, minOutputValue, maxOutputValue), because the
likelihood that
> someone who has to use a tool of modern knowledge to analyze their
cipher is
> severely unlikely to find anything anywhere near secure. Just to give
you
> some idea of the complexities of analysis of ciphers, judging them on
rounds
> doesn't work (RSA is secure with 1 round, DES takes several), you
can't
> judge them on size (a Vigenere cipher can be gigabytes in size and
still be
> weak, 3DES operates on 64-bit blocks with a 168-bit key), you can't
judge
> them on type of round (Feistels can be as weak as a home brew,
homebrews can
> actually be strong round types), on resistance against attacks (each
attack
> has to be custom tailored), on brute-forcability (the gigabyte+
Vigenere
> would certainly not be bruteforcable), on the final operation (RC4
uses XOR
> on the output of the pRNG, so does a vigenere). There are actually
many of
> us working on just this problem, what constitutes a secure cipher, I'm
> hoping that sometime within the next decade I can find a
qualification that
> was not previously known, but my odds aren't that great. Once we know
all
> the qualities that go into making a cipher strong, we'll be able to
build
> such a program, until then there's no point in even trying.
> Joe
>
> <[EMAIL PROTECTED]> wrote in message
> news:8kvtun$dkg$[EMAIL PROTECTED]...
> > Hi tekkies.
> >
> > I'm just wondering if there is a tool for working with symmetric
> > ciphers on the web. If you have any knowledge of one please mail me.
> >
> > The reason i ask is that I have an idea about building a 'studio'
tool
> > for analyzing different symmetric ciphers. You could have some API
to
> > make it possible for users to develop ciphers as external modules
and
> > also make analyze methods like external modules.
> >
> > This is just in the idea stage but please mail me if you have any
ideas
> > of what functions would be desired in such a tool.
> >
> > / foo
> >
> >
> > Sent via Deja.com http://www.deja.com/
> > Before you buy.
>
>
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Jim Gillogly <[EMAIL PROTECTED]>
Subject: Re: Crypto analyze tool.
Date: Tue, 18 Jul 2000 16:05:08 +0000
JPeschel wrote:
>
> Raddum [EMAIL PROTECTED] writes:
> >JPeschel wrote:
> >
> >> "Joseph Ashwood" [EMAIL PROTECTED] writes, in part:
> >>> (a Vigenere cipher can be gigabytes in size and still be weak...
> >>
> >> What do you mean by "a Vigenere cipher can be gigabytes in size:" the
> >> Vigenere key? How do you propose breaking a Viggy that uses a key
> >> of that size?
> >
> >Known plaintext attack?
>
> Yeah, that should do it. I was wondering, however, whether
> Ashwood thought a Vigenere with such a huge key was
> vulnerable to a ciphertext-only attack.
I do. If a 1-gig Vig key is coherent (e.g. a GB of Usenet postings),
then a Vig message up to 1 gig long is solved as a running key. If it's
not coherent, then a 2-gig encrypted Vig is the equivalent of a 2-time
pad. It gets increasingly easier with a 3-gig, 4-gig etc. message.
You wouldn't try dealing with the whole thing at once: simply
grab the first few dozen bytes of each gig to work with.
--
Jim Gillogly
Hevensday, 25 Afterlithe S.R. 2000, 15:59
12.19.7.6.19, 13 Cauac 2 Xul, Fourth Lord of Night
------------------------------
** 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
******************************
