Cryptography-Digest Digest #298, Volume #12 Thu, 27 Jul 00 10:13:00 EDT
Contents:
Re: The Purple Cipher (World War II) (Charles Blair)
Re: What is DES3mCBCMACi64pPKCS5? (Mark Wooding)
Re: Selecting cipher - which one to use? (Charles Blair)
Re: What is DES3mCBCMACi64pPKCS5? (Mark Wooding)
Re: Selecting cipher - which one to use? (Mark Wooding)
BassOmatic symmetric block cipher, any help ? (jungle)
Re: Random Appearance (Mok-Kong Shen)
Re: Proving continued possession of a file (Andru Luvisi)
Question: MS CryptoAPI CryptDeriveKey from pw ([EMAIL PROTECTED])
Re: How is the security of Outlook Express encryption ? (Guy Macon)
Re: How is the security of Outlook Express encryption ? (Guy Macon)
Re: R: CD destruction (Guy Macon)
Re: Elliptic Curves encryption (DJohn37050)
Re: Selecting cipher - which one to use? (Eric Lee Green)
Re: How is the security of Outlook Express encryption ? (jungle)
----------------------------------------------------------------------------
Subject: Re: The Purple Cipher (World War II)
From: [EMAIL PROTECTED] (Charles Blair)
Date: Thu, 27 Jul 2000 12:24:06 GMT
I am curious about the comparison between purple and enigma. Were
the techniques for breaking similar? Were the projects done completely
independently of one another? Is it possible to say which break was
intellectually more difficult?
------------------------------
From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: What is DES3mCBCMACi64pPKCS5?
Date: 27 Jul 2000 12:27:02 GMT
Paul Rubin <[EMAIL PROTECTED]> wrote:
> I'm using a cryptography module that supports an encryption mode
> called Mech_DES3mCBCMACi64pPKCS5. You give it a plaintext buffer and
> it pads it to a multiple of 8 bytes using PKCS5, encrypts it in 3DES
> CBC mode and adds a MAC. I understand about 3des/CBC and PKCS5 but am
> not sure of how the MAC is supposed to be computed, and I'm trying to
> code an interoperable implementation.
The CBCMAC mechanism applies PKCS5 padding, and then gives you the last
block of the ciphertext you'd have got if you'd done encryption rather
than MACing.
-- [mdw]
------------------------------
Subject: Re: Selecting cipher - which one to use?
From: [EMAIL PROTECTED] (Charles Blair)
Date: Thu, 27 Jul 2000 12:26:30 GMT
Everybody in this thread seems against IDEA. However, it is an
essential component of PGP, at least version 2.6.x. Should PGP
users be worried?
------------------------------
From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: What is DES3mCBCMACi64pPKCS5?
Date: 27 Jul 2000 12:32:46 GMT
Paul Rubin <[EMAIL PROTECTED]> wrote:
> I'm using a cryptography module that supports an encryption mode
> called Mech_DES3mCBCMACi64pPKCS5. You give it a plaintext buffer and
> it pads it to a multiple of 8 bytes using PKCS5, encrypts it in 3DES
> CBC mode and adds a MAC. I understand about 3des/CBC and PKCS5 but
> am not sure of how the MAC is supposed to be computed, and I'm trying
> to code an interoperable implementation.
It simply applies PKCS5 padding, does CBC encryption with the IV you
gave it (or makes one up for you if you didn't give it an IV) and then
gives you back the last 64-bit block of the ciphertext.
Some authorities recommend further encrypting the CBC-MAC result. The
module you're trying to use doesn't do that.
-- [mdw]
------------------------------
From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: Selecting cipher - which one to use?
Date: 27 Jul 2000 12:37:54 GMT
Charles Blair <[EMAIL PROTECTED]> wrote:
> Everybody in this thread seems against IDEA. However, it is an
> essential component of PGP, at least version 2.6.x. Should PGP
> users be worried?
The problems with IDEA are:
* It's slow. PGP users don't really have to care about this, unless
they're encrypting really big things.
* It's patented. However, Ascom Tech AG (the owners of the patent)
will grant licences for noncommercial use. The PGP licence for the
no-cost version requires noncommercial use anyway, so that's not a
problem. This patent is the reason that GnuPG doesn't implement
IDEA, however.
* There are much better ciphers available now, such as all of the
other ones which have been mentioned, in terms of both security
margin and performance.
Phil Zimmerman seems to get warm fuzzy feelings about different ciphers
from me. He had one about IDEA, and he claims to have one about
CAST128. While there's nothing really wrong about either of these from
a security point of view, I get much warmer and fuzzier feelings about
Blowfish and Serpent.
-- [mdw]
------------------------------
From: jungle <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp
Subject: BassOmatic symmetric block cipher, any help ?
Date: Thu, 27 Jul 2000 08:40:35 -0400
any help on the BassOmatic symmetric block cipher ?
it has been used with 256 byte [ ??? ] block size for the plaintext and the
ciphertext ...
the key size of up to 256 bytes [ ??? ] was used to & CFB mode ...
I have difficulties to find any info & reviews about it ...
has it been compromised ?
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Random Appearance
Date: Thu, 27 Jul 2000 14:52:25 +0200
Future Beacon wrote:
> On Wed, 26 Jul 2000, Mok-Kong Shen wrote:
>
> > ........ You analyze a sentence and get its structure. For example,
> > the sentence is 'John plays football'. The structure is noun-verb-object.
> > What do you do in this case?
>
> Compress and encrypt at this point.
>
> > In the scheme I indicated, 'John' is
> > mapped to a corresponding set of other nouns, say, {Mary, cat, .....},
> > and similarly for the other two words. So the transform could turn out
> > to be e.g. 'Mary hears music'.
>
> The connection between "John plays football" and "Mary hears music"
> must be obliterated by the encryption and disguise mechanism that
> intervenes.
Why? If you are the opponent and get the one sentence, how do you
come to the other? Of course, the scheme is a fairly bad form of using
code books. If you send lots of messages with that, then it could soon
become insecure.
> > In order to obtain such sufficiently
> > natural transforms, the domain of discourse has obviously to be very
> > limited and even then it is not a easy task. That is what I meant in
> > my previous follow-up. Now could you show how you would
> > operate with my example sentence to get a transform that looks
> > natural according to your scheme?
>
> There have been mistakes in my attempt to give actual algorithms.
> That has confused matters. I should give the overall scheme first:
>
> To send, write the plain text, compress it, encrypt it, disguise it,
> and send it.
>
> The receiver must undo the disguise, decode the random-like cipher
> text, decompress it, and read it.
>
> Under the assumption that the disguise is apparent text, I believe
> that the disguise phase will make the message longer. This is what
> motivates the compression phase. I believe that common compression
> schemes do not compress enough. This motivates using the same sort
> of grammatical tools that seem needed for the disguise.
>
> pt --> compressed pt --> ct --> disguised ct
>
> In the phase that converts ciphertext to disguised ciphertext, an
> algorithm must be found that makes all of the choices necessary to
> constructing correct sentences (let's tackle the relatedness later).
> The sentence structure (Si) must be chosen on the basis of some of
> the bits in the cipher text. This might produce a sentence worth of
> parts of speech. More of the ciphertext bits must be used to select
> words that fit the parts of speech.
If the process of producing the ciphertext is any good, then you
get things that appear to be very random, i.e. there shouldn't be
ANY structure remaining to be discernible. Hence from that you are
unlikely to find good and sufficiently efficient ways to (bijectively)
translate into high quality natural language sentences that appear to
be naturally connected to one another, i.e. without causing any
suspicion of the opponent who intercepts the message. It is
certainly conceivable that one maps, say, each binray value of an
8 bit group (0-255) into a large set of English sentences. Given a
sequence of bytes, one then chooses a sequence of corresponding
sentences that appear to be naturally connected. But I am afraid
that such a system is very hard to implement and has a high
expansion factor in terms of message volume. It would certainly
require quite a lot of linguistic extertise in its design.
> I have not taken the matter much farther than this. I am merely
> optimistic.
>
> I believe that the sender and the receiver need to share a list of
> words that are organized, in some way, by part of speech. I believe
> that common grammar needs to be modified in order to solve all of
> the problems. I believe that the sentence structures in the plain
> text should have no relationship to the sentence structures in the
> disguise. I don't have much more.
Sentence structures don't hurt much generally in my humble view.
After all, there aren't very many typical sentence sturctures in normal
discourses. By keeping the stuctures, the task of getting good
transforms become easier. If you unconditionally want variations,
you could optionally map a simple sturcture to a more complicated
one by including elements that are redudant (dummy). But this not
only incurs more work but also renders the more complicated
stuctures either not available for the plaintext or be subjected to
certain constraints or special treatment when plaintext having these
sturctures are to be processed.
M. K. Shen
------------------------------
From: Andru Luvisi <[EMAIL PROTECTED]>
Subject: Re: Proving continued possession of a file
Date: 27 Jul 2000 05:42:24 -0700
[EMAIL PROTECTED] writes:
[snip]
> I don't think it will. Bob can just store the two numbers:
>
> k_1 = x_1 * x_2 * x3 * ... mod n
> k_2 = ((x_1)^1) * ((x_2)^2) * ((x_3)^3) * ... mod n
>
> Then, when Alice gives him b*r and i*r, he returns:
>
> ((k_1)^(b*r)) * ((k_2)^(i*r)) mod n
Well darn.
An interesting proof which may effect this:
If f(g(a,b)) = g(f(a), f(b)), then the same goes for f^-1.
f^-1(g(a,b)) = f^-1(g(f(f^-1(a)), f(f^-1(b))))
= f^-1(f(g(f^-1(a), f^-1(b)))) = g(f^-1(a), f^-1(b))
My goal was to try and create an f_1 and f_2 such that f_1 distributed
over g, but f_2 did not, however Bob would only know how to compute
f(x) = f_1(f_2(x)), where f_2 was exponentiation by changing values,
and f_1 was exponentiation by r, and g was multiplication. I think
the idea may still have merit, but I'm not sure how to salvage it at
this point.
Ideas?
Thanks,
Andru
--
Andru Luvisi, Programmer/Analyst
------------------------------
From: [EMAIL PROTECTED]
Subject: Question: MS CryptoAPI CryptDeriveKey from pw
Date: Thu, 27 Jul 2000 13:12:24 GMT
Hello, I am using CryptDeriveKey and passing in a handle to a hasher
that was loaded with a password. This is the method described in MSDN
to create a symmetric key based on a password.
for example
CryptCreateHash - make a new hash handle - hHash
CryptHashData - input the password and hash it once
CryptDeriveKey - pass in hHash and get a new key handle
based on the hash
This all works fine except I have to make the exact same key with
another vendors toolkit.
Does anyone know what CryptDeriveKey does ?
Does it hash the data for some fixed number of rounds ? (usually
once is not enough)
What part of the hash result goes in the key ?
Is it PKCS#5 compatible or something else ?
The method I know of for deriving a key from a password is to
add a salt value to a password and hash it N times.
Then a portion of the resulting hash is used as the acutal
key, the amount used depends on the length of the key.
In this case I was using a sha1 hash (20 bytes) and a 64 bit
DES key.
thanks
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (Guy Macon)
Subject: Re: How is the security of Outlook Express encryption ?
Date: 27 Jul 2000 09:44:23 EDT
Donald L. Nash wrote:
>
>
>In article <8ln7o1$q7g$[EMAIL PROTECTED]>, "???"
><[EMAIL PROTECTED]> wrote:
>
>>Actually, I want to know which encryption algorithm and what key lenghth
>>are used by Outlook Express.
>
>It depends. OE uses the Cryptographic API ("CAPI") provided by Windows,
>and CAPI is modular. The algorithm and key size used depend on the
>modules installed and on what the application asks for. I think the
>default is either 40-bit or 56-bit DES and 512-bit RSA, but it has been
>a long time since I looked at CAPI so I'm not positive about that. I
>just remember that the default is pretty weak.
>
>But Greg makes a good point: CAPI can be subverted by inserting a DLL
>between the CAPI DLL and the application, which would allow the
>attacker's DLL to intercept all the plaintext and do anything it wants
>to it. This requires that the attacker be able to install DLLs on your
>system, but with all the security holes in Internet Explorer how hard
>can that be? This isn't an indictment against CAPI per se, but is yet
>another illustration that the weakest link determines the strength of
>the chain.
...and if anyone doubts this, go to [ http://grc.com ] and click on
"Shields up!" to see how many holes are open on your own system.
------------------------------
From: [EMAIL PROTECTED] (Guy Macon)
Subject: Re: How is the security of Outlook Express encryption ?
Date: 27 Jul 2000 09:46:51 EDT
S�bastien SAUVAGE wrote:
>
>
>[EMAIL PROTECTED] (???) wrote in
><8lp1gs$f7r$[EMAIL PROTECTED]>:
>
>>
>> How about PGP ? Does it suffer form the attack of DLL interception ?
>>
>
>Every single program (Windows Explorer, Outlook, PGP, your browser,
>your very own firewall, your antivirus, games...) can be hooked.
>
>This is not PGP or Outlook specific.
Almost correct, but not quite. I have systems with ROMDOS and other
systems with Embedded NT in EPROM. Those can't be hooked.
------------------------------
From: [EMAIL PROTECTED] (Guy Macon)
Subject: Re: R: CD destruction
Date: 27 Jul 2000 09:50:37 EDT
Greg wrote:
>
>> This may well be an unsound idea, but the last time I had to
>> destroy a CD-R I just nuked it in the microwave.
>
>Well, if you don't have a solvent, a fire place lit already, or
>a power tool, I guess a microwave would make a decent improvision
>for when the ninja clad swat team is jumping through your door.
>
>Toilets just won't cut it for CDs...
>
>Microwaves are really cheap and abundant these days. But I would
>recommend a Microwave sitting next to your PC on an uninterruptable
>power supply - in case the swat team cut the power to your house
>before making entry.
>
>Just a thought...
>
Or you could just use encryption and be safe even if you aren't home
when they show up with the battering ram.
------------------------------
From: [EMAIL PROTECTED] (DJohn37050)
Subject: Re: Elliptic Curves encryption
Date: 27 Jul 2000 14:02:43 GMT
Also, ECC CAN be used to transfer/encrypt data/keys. Think of ECC and RSA
having the "same" public key magic potential; the differences lie in the
externals, size of keys, ease and performance of operations, etc.
Don Johnson
------------------------------
From: Eric Lee Green <[EMAIL PROTECTED]>
Subject: Re: Selecting cipher - which one to use?
Date: Thu, 27 Jul 2000 14:07:28 GMT
Mok-Kong Shen wrote:
> Runu Knips wrote:
> > (a) Don't use IDEA. It uses only 64-bit blocks, uses multiplications and
> > even
> > worse it is PATENTED and you'll have to pay (much !) money for using
> > it.
>
> I understand what you said except 'multiplications'. What's inherently
> wrong with using multiplications? Thanks.
Err, that they're slower than additions and shifts on most smaller
processors? Given that we don't know the application of the cipher, this
may or may not be an important factor.
For example, if the cipher must be implemented on a typical 8-bit
microcontroller, these puppies usually either don't have multiply
instructions, or have very SLOW multiply instructions (i.e., done in
microcode rather than in hardware and taking upwards of 50 cycles to
complete in some cases). Obviously a cipher which uses multiply heavy
isn't going to be very efficient, as vs. add/subtract/shift (which take
only a few cycles).
Finally, for the lady wanting a suggestion for a cipher, I would
recommend that a) she go by the AES contest page at
http://www.nist.gov/aes, I personally like TwoFish due to its ability to
either be fast or compact depending upon the situation but others will
suggest other ciphers, and b) I *STRONGLY* suggest that her company
contract a real cryptography expert to do the job, because her questions
showed a lack of knowledge of the field which will be disasterous for
the deployed system. Cryptography is easy to do, but hard to do
correctly. It takes a certain demented world-view to be good at building
cryptosystems, a world-view where everybody is an attacker trying to
find some way to hijack your data or insert new false data, and you must
be as capable of envisioning ways to do this as the best of the
attackers out there, including Three Letter Agency ones. Or at least
contract with one of these guys to look at your system design before you
start coding, because it is very easy to have a broken system (broken as
in "obviously broken to any practitioner in the crypto area at casual
glance") that looks perfectly good to a (non-demented) programmer. See
Microsoft's very public woes in that area (
http://www.counterpane.com/labs.html has a good listing of that). And
Microsoft has some very good programmers (despite my anti-Microsoft
bias, every Microsoft programmer I've ever met has been a top-notch
programmer), but Microsoft was arrogant, did not get a crypto expert to
review their design, and it was broken, and broken badly, and their
first fix was broken badly too (took them two tries to get it "right",
and even now many disagree that they have it "right", as one
correspondent said to me in private EMAIL, "any modern authentication
system that relies on passing salted hashes around is succeptible to
dictionary attacks and fundamentally defective"). The point being that
even the smartest of programmers can be ridiculously inept in the crypto
arena if he doesn't have the background and the demented world-view
needed to be good at it. Cryptosystems design is a field for paranoids,
not for normal well-adjusted people :-).
--
Eric Lee Green There is No Conspiracy
[EMAIL PROTECTED] http://www.badtux.org
------------------------------
From: jungle <[EMAIL PROTECTED]>
Subject: Re: How is the security of Outlook Express encryption ?
Date: Thu, 27 Jul 2000 10:07:53 -0400
yes, your "chipmunks" to can be hooked ...
Guy Macon wrote:
> S�bastien SAUVAGE wrote:
> >[EMAIL PROTECTED] (???) wrote in
> ><8lp1gs$f7r$[EMAIL PROTECTED]>:
> >> How about PGP ? Does it suffer form the attack of DLL interception ?
> >Every single program (Windows Explorer, Outlook, PGP, your browser,
> >your very own firewall, your antivirus, games...) can be hooked.
> >
> >This is not PGP or Outlook specific.
>
> Almost correct, but not quite. I have systems with ROMDOS and other
> systems with Embedded NT in EPROM. Those can't be hooked.
"Almost correct, but not quite." repeating your words ...
replicate "your systems" in software, than hook them with easy ...
yes, your "chipmunks" to can be hooked ...
the problem is not where is your software
but is your system PHYSICALLY SAFE & SECURE ...
------------------------------
** 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
******************************
