Cryptography-Digest Digest #135, Volume #12 Thu, 29 Jun 00 10:13:00 EDT
Contents:
Re: Dynamical Cryptography algorithm (Sylvain Martinez)
Re: searching for a special GUI crypto tool ("Collin Addy")
Re: Algo's with no easy attacks? (David P Jablon)
Re: Dynamical Cryptography algorithm (Simon Johnson)
Re: Algo's with no easy attacks? (David P Jablon)
AOL & InterTrust (Lieven Trappeniers)
Re: Key agreement in GSM phones (Paul Schlyter)
Re: Diffie Hellman Primes : Speed Tradeoff Q (Anton Stiglic)
Re: Idea or 3DES ([EMAIL PROTECTED])
Re: Surrendering Keys, I think not. (jkauffman)
Re: Another chaining mode ("Scott Fluhrer")
----------------------------------------------------------------------------
From: Sylvain Martinez <[EMAIL PROTECTED]>
Subject: Re: Dynamical Cryptography algorithm
Date: Thu, 29 Jun 2000 11:09:52 GMT
In article <[EMAIL PROTECTED]>,
Simon Johnson <[EMAIL PROTECTED]> wrote:
> Could u publish this analysis aswell please?
I could publish the analysis of the previous version but it would be a
bit irrelevant...
For the new version I've only got my analysis, it's only on paper so
I'll post it as soon as I've got on my computer.
At the mean time, the technical documentation is the best way to find
out if BUGS is good or not...
Cheers,
Sylvain.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "Collin Addy" <[EMAIL PROTECTED]>
Subject: Re: searching for a special GUI crypto tool
Date: Thu, 29 Jun 2000 12:52:42 +0100
Thierry,
I would definitely recommend CoolFish v2.12 by Compsci
at http://www.compsci.co.uk/fish/coolfish.exe - I use it myself
for mailing my friends all the time.
I understand that it uses 448-bit Blowfish, so should be more
than secure enough, but above all it's simple, and a good-looking
little program. It accepts text and file attachments a bit like an email
client but is standalone a bit like WinZip. It will either encrypt to
text for sending as email text or to file for general-purpose encryption,
but it's really best for mailing.
It doesn't have Explorer extensions at the moment though, but
that's actually something I have suggested to them so who knows...!
-Col-
"TL" <[EMAIL PROTECTED]> wrote in message news:8jb7qd$k$[EMAIL PROTECTED]...
>
> I'm searching for a special GUI crypto tool.
> The aim is just to hide my private infos, when sending
> email attachments thru the net, or even progs I made.
>
> What I consider :
> - it must work under all 32-bit Windows (win9x, nt4, w2k),
> accepting LFN or multiple files' extension
> - encrypting many files at once, and either getting the
> same number of source files or (according to user's wish) only
> a merged one
> - coding many folders in recursive mode, such as compressing
> when crypting, would be a plus
> - (de)crypting may be invoke by a right-clic under EXPLORER,
> if possible (instead of launching the appropriate tool in Menu Start)
> - password must never be visible (remplaced by asterisks)
> - possibility to definitively remove the source data when crypting
> - english menus is the minimum (but french one would be OK too!)
> - (de)crypting a 1Mb folder mustn't take more than 10 seconds
> or so (on a P2-400MHz basis)
> - poor password must be rejected (too short or evident ones)
> - most of keyboard characters must be accepted.
> - no backdoor (quick glance to programmers or hackers/crackers,
> but do I have to write this? We all know what crypting risks are!)
> - at last but not the least : the product must be freeware,
> shareware, cardware or so (CRESUS has left us!)
>
> Some downloaded binairies I like the most :
> - PUFFER http://www.briggsoft.com/puffer.htm
> - CRYPTO http://www.gregorybraun.com/crypto.html
> - HARDCRYPT http://www.alternetive.asso.fr/securite/jcutils.htm
>
> For those who like to crypt with WinZip, it has been proved to be
> poorly protected (or with a long phrase, may be?)
>
> Nothing to do with paranoia, but when looking inside the crypted files
> with an hex-editor (header, or so), someone may easily deduice the
> used crypting tool and have the correspounding antidote...
> To be considered!
>
> Thanks for those of you who have constructive comments,
> or even better : URL's of matching softs such as indicated above,
> on this NG or directly via my email.
>
> ______________________________________________________________________
> [Thierry]
>
------------------------------
From: [EMAIL PROTECTED] (David P Jablon)
Subject: Re: Algo's with no easy attacks?
Date: Thu, 29 Jun 2000 11:56:12 GMT
In article <[EMAIL PROTECTED]>,
Eric Lee Green <[EMAIL PROTECTED]> wrote:
>For example, one early version of Windows NT password handling sent an
>encrypted version of the password across the network to the NT server, which
>the NT server then compared against its own copy of the password and then said
>"Okay, this guy has permission to log in to me." The problem was that there
>was no "salt" value mixed in with the password.
The much bigger problem with this is that password crackable data is
revealed to unauthorized parties. The lack of salt just made it easier.
All hash-based protocols, salted or unsalted, are a horribly poor
practice today, given what we know can be done with protocols like
SPEKE, EKE, SRP, and many others. SSL is better than nothing,
but only *if* you can trust the user to authenticate the server.
>... For
>example, Microsoft's next version of the Windows NT password handling was also
>insecure, despite using all of the above components. It took yet another try
>before they finally got it right.
Except that there is no indication that they have "finally got it right".
Zero-knowledge protocols prevent any leakage of the password in as
many cases as possible. I see no evidence that they've considered all
the known network attacks that modern protocols are designed to defend
against, or used such protocols. www.IntegritySciences.com has
discussion of the methods that do (and do not) work.
>This is a good example of what happens when the software system's designer is
>not aware of the attacks against a protocol, and is why protocol design is the
>next frontier in cryptography. We have secure ciphers. Now we need secure
>protocols to tie them together. There has been some work done in this area,
>such as SSL, but it is by no means as cut-and-dried as the current
>state-of-the-art in ciphers --
Absolutely. In the roughly 10-year-old history of strong
password-based protocols, the structure of known working methods
have been shown to be intimately related to the underlying cryptosystem
in some very subtle ways.
So, inventing your own password-protocol is definitely not recommended,
until one reads about earlier successes and failures.
======================================================
David P. Jablon
Integrity Sciences, Inc.
[EMAIL PROTECTED]
<http://www.IntegritySciences.com>
------------------------------
Subject: Re: Dynamical Cryptography algorithm
From: Simon Johnson <[EMAIL PROTECTED]>
Date: Thu, 29 Jun 2000 04:57:56 -0700
Sylvain Martinez <[EMAIL PROTECTED]> wrote:
>
>> > Sorry I am not familiar with blowfish and thought it was
the case.
>>
>> Then perhaps you ought to become more sure of your facts
before > >
>> claiming
>> such things? It's not exactly difficult.
>
>I ought to do so in the futur indeed...
>
>> > What I try to say is that:
>>
>> Ahh. You don't want to answer the question.
>
>??
>
>[...]
>>
>> Symmetric systems are constructed from the sorts of
operations which
>> are
>> commonly found on general-purpose computers, such as XOR,
addition,
>> shifts and rotates, and table lookups.
>>
>> So, I'll ask my question again: why is your system different
from
>> these?
>
>It uses the same ingredients but not the same receipes...
>Ok then it is not different...
>
>> There is mathematical theory which can analyse various
operations, and
>> we can describe all of these ciphers in mathematical ways.
Yours
>> cannot
>> be an exception to this.
>
>I agree !
>I never meant to say so.
>But the way This algorithm has been *designed* is not based on
maths
>
>> > If the different ciphers you talk about are not using
complex maths
>> > then BUGS is like them.
>>
>> Why don't you have a look at them, and get back to me, eh?
Read
>> literature about how ciphers have been analysed, constructed,
broken
>> and
>> repaired. Then you'll really be in a position to design
ciphers and
>> describe to us without looking like an idiot because you're
talking
>> about things you don't understand.
>
>Why are you so agressive ?
>I could hit back but I am not interested into this, I am
interested in
>cryptography. I think I should open a new thread on the
following
>subject: "Why a lot of people on Usenet need to be really
insulting, is
>it because that make them feel better ?"
>For god sake ! I just post a small article ! I don't pretend I
am good
>at anything, that I know cryptography, etc ...
>I am an amateur willing to learn ! this is why I have done that
and I
>just try now to speak with experienced cryptographer !
>
>Anyway. This is not the aim of my post, and I know how this
will (badly)
>evolve. Please email me if you've got a problem and we could
speak about
>that. Otherwise your comments are welcome.
>
>Regards,
>Sylvain.
>
>--
>---
>Unix security administrator
>BUGS crypto project: http://www.bcrypt.com
>http://www.encryptsolutions.com
>
>
>Sent via Deja.com http://www.deja.com/
>Before you buy.
>
I agree with you.
Chill fokes, lighten up :o)
===========================================================
Got questions? Get answers over the phone at Keen.com.
Up to 100 minutes free!
http://www.keen.com
------------------------------
From: [EMAIL PROTECTED] (David P Jablon)
Subject: Re: Algo's with no easy attacks?
Date: Thu, 29 Jun 2000 12:11:31 GMT
In article <[EMAIL PROTECTED]>,
Eric Lee Green <[EMAIL PROTECTED]> wrote:
> For example, one early version of Windows NT password handling sent an
> encrypted version of the password across the network to the NT server, which
> the NT server then compared against its own copy of the password and then said
> "Okay, this guy has permission to log in to me." The problem was that there
> was no "salt" value mixed in with the password.
The much bigger problem is that password crackable data is
revealed to unauthorized parties. The lack of salt just made it easier.
All hash-based protocols, salted or unsalted, are a horribly poor
practice today, given what we know can be done with protocols like
SPEKE, EKE, SRP, and many others. SSL is better than nothing,
but only *if* you can trust the user to authenticate the server.
> ... For
> example, Microsoft's next version of the Windows NT password handling was also
> insecure, despite using all of the above components. It took yet another try
> before they finally got it right.
Except that there's no indication that they have "finally got it right".
Zero-knowledge protocols prevent any leakage of the password in as
many cases as possible. I see no evidence that they've considered all
known network attacks that modern protocols are designed to defend
against, or used any such protocols. www.IntegritySciences.com has
discussion of the methods that do (and do not) work.
> This is a good example of what happens when the software system's designer is
> not aware of the attacks against a protocol, and is why protocol design is the
> next frontier in cryptography. We have secure ciphers. Now we need secure
> protocols to tie them together. There has been some work done in this area,
> such as SSL, but it is by no means as cut-and-dried as the current
> state-of-the-art in ciphers --
Absolutely. In the roughly 10-year-old history of strong
password-based protocols, the structure of known working methods
have been shown to be intimately related to the underlying cryptosystem
in some very subtle ways.
So, inventing your own password-protocol is definitely not recommended,
until one reads about earlier successes and failures.
But before you blindly trust in even a standard protocol like SSL/TLS,
you must still understand the threat model in which the
protocol is used. For example, sending a password through an
SSL tunnel defends against eavesdroppers, but it doesn't stop the
party at the other end from getting it. Zero-knowledge methods do.
So you'll want to think about cases were the user
can't or won't authenticate the server, or if you're worried
about occasional server-based attacks.
Another good case to study is how SSL addresses credit card fraud.
Does it prevent fraud or reduce merchant liability? Does it prevent
other misuse of these valuable, but sensitive reusable credentials?
======================================================
David P. Jablon
Integrity Sciences, Inc.
[EMAIL PROTECTED]
<http://www.IntegritySciences.com>
------------------------------
From: Lieven Trappeniers <[EMAIL PROTECTED]>
Crossposted-To: alt.security,comp.security.misc
Subject: AOL & InterTrust
Date: Thu, 29 Jun 2000 15:06:24 +0200
Recently, AOL and InterTrust technologies anounced an agreement for
distributing and managing electronic books, music, video, ...
InterTrust will provide the digital rights management (DRM) technology.
However, their description of the DRM technology
(http://www.InterTrust.com/) is extremely vague and contains some
snake-oil signs, using flashy new notions that are not specified.
"A new computing technology is required to address ..."
"Protected information ... is encrypted and stored in a format called a
DigiBox container. Once in a DigiBox container, the information can flow
across unsecured networks ... . Information in a DigiBox container
remains protected ..."
"protected processing environments on PC's"
Does anybody know about the underlying scenario's, encryption
algorithms, ... ?
I had no response to my enquiry at their website.
Thanks,
Lieven.
------------------------------
From: [EMAIL PROTECTED] (Paul Schlyter)
Subject: Re: Key agreement in GSM phones
Date: 29 Jun 2000 13:34:26 +0200
In article <[EMAIL PROTECTED]>,
Arturo <[EMAIL PROTECTED]=NOSPAM> wrote:
>On Mon, 26 Jun 2000 13:18:24 +0200, Gerard Tel <[EMAIL PROTECTED]> wrote:
>
>>
>>Two questions on GSM protection, left after reading Biryukov/Shamir/
>>Wagner's account on breaking the A5/1 stream cipher:
>> 1. What protocol is used by the two parties to agree on the
>> 64 bit keys used?
>> 2. Is the encryption used ONLY on the ether link (between base and
>> mobile) or is the data also encrypted during transportation over
>> the fiber network?
>>
>>Gerard Tel
>>http://www.cs.uu.nl/~gerard/
>
> A technical paper describing the GSM algorithms in full will be much
>appreciated.
You won't find that, for two reasons:
1. They are secret, thus any such paper will be secret too
2. They are operator dependent, i.e. different operator can, and do,
use different algorithms.
There are some info on some of these algorithms though, on URL's already
posted here. Or you could do a web search om "GSM" or "A3/A8" and see
what you find.
A third option is of course to seek employment in some mobile phone
operator company, and try to find a position there which will give you
access to these secret algorithms.
As with most other secret algorithms, one can assume that these
algorithms are weak: by making them secret, one ensures that they are
not thoroughly examined by the cryptographic community.
--
================================================================
Paul Schlyter, Swedish Amateur Astronomer's Society (SAAF)
Grev Turegatan 40, S-114 38 Stockholm, SWEDEN
e-mail: pausch at saaf dot se or paul.schlyter at ausys dot se
WWW: http://hotel04.ausys.se/pausch http://welcome.to/pausch
------------------------------
From: Anton Stiglic <[EMAIL PROTECTED]>
Subject: Re: Diffie Hellman Primes : Speed Tradeoff Q
Date: Thu, 29 Jun 2000 09:48:47 -0400
[EMAIL PROTECTED] wrote:
>
> I'm implementing Diffie-Hellman for a client-server product. I
> understand that in an ideal world, a new shared p and g are chosen for
> each session. Generating the key pair is easy, but coming up with a
> large (1024 or 2048 bit) p every time is prohibitively slow when we're
> talking about potentially 100's of new sessions per hour.
>
> Of the following options, which would the friends of sci.crypt
> recommend?
>
> 1. Generate a new smaller prime (say, 128 bit) for each new session.
>
> 2. Choose randomly from a pool of 50 or so large (2048 bit) primes that
> are hard-coded into the client and server... Assume that evil genius X
> has access to this list of primes.
>
> 3. Why not just use the same extra-huge prime every time? Or change it
> once a week when I take out the trash?
There is nothing wrong with choosing one big 1024 bit prime as a public
parameter,
and keeping it for a month, or even a year. That's what most systems
do (you
don't want to keep it for 10 years though...).
What you want is a "kosherized" prime, a prime that has some sort of
proof
that it wasn't generated maliciously. OAKLEY's RFC suggests such primes
in it's appendix (they have a multiple of Pi in the middle, that's the
kosherization).
If you want a hand made kosher strong prime, you can do the following
(based on the idea
described in DSA prime number generation).
x <- random,
q <- Hash(x),
verify that q is prime,
verify that 2q + 1 is prime,
verify whatever else you want on q and 2q + 1,
return x, q, p:= 2q+1.
Here, the fact that you got q from a hash of something serves as
kosherization.
Anton
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Idea or 3DES
Date: Thu, 29 Jun 2000 13:42:58 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (JPeschel) wrote:
> "Trevor L. Jackson, III" [EMAIL PROTECTED] writes:
>
> >There is insufficient evidence to distinguish inability from
> >unwillingness.
>
> After writing:
> "The case would not have been made, and PRZ indicted, if the USG was
> unwilling. The appropriate explanation for a dropped case is
inability."
>
> just a little semi-paranoid thought,
what if the USG, in fact, did find a weakness that might lead to
eventual cracking of the ciphers, wouldn't they want people (e.g. the
drug dealers using pgp,) to continue to use them, and so, intentionally
dropped the case because of 'inexpediency' of prosecuting it, but after
leading people to believe that it was secure enough to be a threat that
warranted USG attention?
vedaal
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: jkauffman <[EMAIL PROTECTED]>
Subject: Re: Surrendering Keys, I think not.
Date: Thu, 29 Jun 2000 06:49:49 -0700
Consider the following scheme:
I want to send message M to someone. I design a piece of
crypto software which operates as follows:
First it generates a OTP. It encrypts M with the OTP O to
produce ciphertext C. It then asks the user to supply an
innocuous message M' and generates a fake OTP O' such that
O'(C) = M'. O and O' are concatenated in some format and
encrypted with standard PKC, the resulting ciphertext C'
being sent along with C. At the receiving end the software
recovers C, O and O' and the user stores C in their machine
and O and O' somewhere else physically secure (e.g. floppy
disk). C' is then destroyed completely (this is very
important).
Now when the police demand the key, you can give them O' and
they have no way of knowing that it isn't O. Not only this
but you can produce the encryption software to prove that
this is the mechanism that you always use for encryption.
The obvious flaw in the plan is that if the police get hold
of C' then they can demand your private key and break the
whole system. However, if everyone did this then there is no
way that the police can keep a record of every C' sent
across the net. They would therefore have to specifically
target comms between two parties, having prior knowledge
that these two parties are engaged in criminal activities.
This kind of solves two problems at once. On the one hand it
means that if they put their minds to it the police can
intercept and decrypt criminal messages, which is a good
thing. On the other hand if you're not a criminal they can't
just turn up at your house and demand the keys to your
encrypted messages.
* Sent from AltaVista http://www.altavista.com Where you can also find related Web
Pages, Images, Audios, Videos, News, and Shopping. Smart is Beautiful
------------------------------
From: "Scott Fluhrer" <[EMAIL PROTECTED]>
Subject: Re: Another chaining mode
Date: Thu, 29 Jun 2000 06:51:32 -0700
Mark Wooding <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Runu Knips <[EMAIL PROTECTED]> wrote:
> > Mark Wooding wrote:
> > > Runu Knips <[EMAIL PROTECTED]> wrote:
> > > > I had another idea about chaining modes. Instead of using the
> > > > block cipher as a blackbox, one could parameterize it with
> > > > the last block,
> > >
> > > This sounds like an excellent way to make chosen plaintext attacks
more
> > > effective! Choosing values which get inserted into the middle of a
> > > cipher seems much more useful than merely adjusting what gets put in
at
> > > the top and looking at what comes out the bottom. ;-)
> > >
> > > I wholeheartedly approve. <fx: gleefully rubs hands together>
> >
> > Hmm good point. :)
>
> Maybe this an appropriate point to mention a possible chaining mode I
> thought up a while ago. It's not very practical, and I don't actually
> recommend its use. It halves the speed of a block cipher, and works
> best on ciphers with a large block size. It also propagates errors
> rather effectively (which probably isn't a good thing). Let's call it
> half-block chaining (HBC).
>
> We split the plaintext and ciphertext blocks into two halves, and I'll
> write (x', y') = E_k(x, y) to denote that the result of encrypting the
> plaintext half-pair (x, y) is (x', y').
>
> Let the plaintext to be encrypted be x_0, x_1, ... Choose a half-width
> initialization vector y_0. We then define the ciphertext z_0, z_1,
> ... and the remaining y_i by the simple relation:
>
> (z_i, y_{i+1}) = E_k(x_i, y_i) i >= 0
>
> Clearly, we need to decrypt *backwards* to get this to actually work
> properly.
>
> I can't see that this weakens the cipher in any particularly meaningful
> way: after all, any known- or chosen-plaintext attack translates
> immediately into a similar attack against the underlying cipher. Even
> so, I don't think doing silly things with chaining modes is a good idea.
One weakness: suppose the plaintext had stereotypical sequences of plaintext
blocks, where the exact same sequence of plaintext blocks occur at various
points. Let us also call the blocksize of the underlying block cipher N.
Then, a particular sequence of plaintext block will correspond to 2**(N/2)
potential ciphertext sequences (depending on the 2**(N/2) half-blocks coming
in). This implies (by the birthday paradox, and assuming that the
half-block coming in behaves as random) that the attacker would need
2**(N/4) such sequences in the plaintext (either scattered throughout
messages encrypted with the same key, or in a single large message) before
he can notice a duplicate sequence in the ciphertext, and will be able to
deduce a duplication in the plaintext.
With DES, this gives 2**16, which is probably not enough. For AES, this is
2**32, which is (IMHO) borderline. And, yes, as you observed, this works
best on ciphers with large block size.
--
poncho
------------------------------
** 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
******************************
