Cryptography-Digest Digest #214, Volume #11      Mon, 28 Feb 00 12:13:02 EST

Contents:
  Re: RSA deppading ("Ian Michael Ash")
  Re: Passwords secure against dictionary attacks? (Jens Haug)
  Re: Status of alleged *THIRD* key in MS Crypto API ? (Francois Grieu)
  Re: Passwords secure against dictionary attacks? (Lincoln Yeoh)
  Re: QUESTION: Enigma Machine Plans, specification etc (Jim Backus)
  Re: Passwords secure against dictionary attacks? (Gordon Walker)
  Re: increasing key length through Hasing (Anton Stiglic)
  Re: How do I get the key from the passphrase in DES? (John Savard)
  Re: CRC-16 Reverse Algorithm ? (Doug Stell)
  Want to poke holes in this protocol? (Johan Hoogenboezem)
  Re: Passwords secure against dictionary attacks? (e n t r o p i c)
  Re: are self-shredding files possible? (Erik)
  Re: Want to poke holes in this protocol? (Tim Tyler)
  Re: Want to poke holes in this protocol? (Erik)
  Encryption (only) in a extremely small program? (~1.4KB) (dywalsh)
  Re: Want to poke holes in this protocol? (Glenn Larsson)

----------------------------------------------------------------------------

From: "Ian Michael Ash" <[EMAIL PROTECTED]>
Subject: Re: RSA deppading
Date: Mon, 28 Feb 2000 14:44:27 +0200

One often pads the real data that you're going to encrypt with a series of
random numbers to make the message longer and increase entropy(?). Perhaps
this reference is to stripping of the random numbers that were added to the
end of the message. i.e. you decrypt the RSA message, then strip off random
padding, and you're left with original message.

Ian



Yo wrote in message <89dl6a$7fa$[EMAIL PROTECTED]>...
>
>Does anybody know what is "RSA deppading" ?  when does it apply?
>
>



------------------------------

From: [EMAIL PROTECTED] (Jens Haug)
Crossposted-To: comp.security.misc,alt.security.pgp
Subject: Re: Passwords secure against dictionary attacks?
Date: 28 Feb 2000 13:44:54 GMT
Reply-To: [EMAIL PROTECTED]

In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (JimD) 
writes:
> On Fri, 25 Feb 2000 07:17:11 GMT, [EMAIL PROTECTED] wrote:
> 
> >-----BEGIN PGP SIGNED MESSAGE-----
> >Hash: SHA1
> >
> >JimD wrote:
> >> >Don't use *any* word in *any* language!
> >> 
> >> How about ten English words with different punctuation symbols
> >> as word separators?
> >
> >do you mean that 'English' is not '*any* language' ? :-)
> >
> (>> >Don't use *any* word in *any* language!) isn't my
> quote.

Of course not. There's one more quotation character before
that quote. No need to mention that, everybody can see that.
(It was my quote.)



Jens


------------------------------

From: [EMAIL PROTECTED] (Francois Grieu)
Subject: Re: Status of alleged *THIRD* key in MS Crypto API ?
Date: Mon, 28 Feb 2000 15:01:40 +0100

I found an article by Duncan Campbell, dated Sept 4, 1999 with a fragment
on the third key, at
<http://www.heise.de/tp/english/inhalt/te/5263/1.html>

according to two witnesses attending the conference [presumably:
Crypto'99], even Microsoft's top crypto programmers were astonished to
learn that the version of ADVAPI.DLL shipping with Windows 2000 contains
not two, but three keys. Brian LaMachia, head of CAPI development at
Microsoft was "stunned" to learn of these discoveries, by outsiders. The
latest discovery by Dr [Nicko] van Someren is based on advanced search
methods which test and report on the "entropy" of programming code.

Is there any substance in this ?

  Francois Grieu

------------------------------

From: [EMAIL PROTECTED] (Lincoln Yeoh)
Crossposted-To: comp.security.misc,alt.security.pgp
Subject: Re: Passwords secure against dictionary attacks?
Date: Mon, 28 Feb 2000 14:42:17 GMT
Reply-To: [EMAIL PROTECTED]

On Sat, 26 Feb 2000 11:17:48 +0000, Johnny Bravo <[EMAIL PROTECTED]>
wrote:

>On Sat, 26 Feb 2000 07:56:52 GMT, [EMAIL PROTECTED] (Lincoln
>Yeoh) wrote:
>
>>Erm, it's trivial to run through a dictionary, just think of it as a two
>>character password where you have say 20000 alphabets.
>>e.g.
>><word1><word2>
>><word1> <word2>
>><word1>,<word2>
>
>  And just these two words have 1.2 billion permutations for 30 bits of
>password with the separators you've given.  Add in a third word and you

Yep, as I was telling Ilya two words is not enough.  

>  40 bits for that, and trying to remember 5 or 6 of them would be over
>kill and very hard to remember.  Diceware is very suited to mnemonic aids

Hmm, I recalculated. Just remember four 6 character passwords. Or five 5
char passwords. 

Remembering four passwords isn't that difficult is it? Just make sure you
do NOT use those four anywhere else.

Diceware is a good idea if it suits your brain. Two diceware words = one 5
character alphanumeric password, so mix and match if you wish. e.g. two
diceware words with 3 passwords.

If you do that I think attackers better have access to you or the machine
;).

To each their own.. Pick what works for you. 

I just hope I don't bump my head or something :).

Cheerio,

Link.
****************************
Reply to:     @Spam to
lyeoh at      @[EMAIL PROTECTED]
pop.jaring.my @ 
*******************************

------------------------------

Date: Mon, 28 Feb 2000 14:59:21 +0000
From: Jim Backus <[EMAIL PROTECTED]>
Subject: Re: QUESTION: Enigma Machine Plans, specification etc

Timothy Charles Holtom wrote:
> 
> Does anyone know of sites giving the specifications of the Enigma
> Machine.  i.e. how the rotors were wired and how the patch panel
> figured in the overall design.
> 
> Thanks!!
> 
> Tim

Have you had a look at www.blueangel.demon.co.uk ?

-- 
NT? - caNT work with it

Jim Backus  [EMAIL PROTECTED]
Systems engineer  Tel +44 1245 702702 ext 2577

------------------------------

From: [EMAIL PROTECTED] (Gordon Walker)
Subject: Re: Passwords secure against dictionary attacks?
Date: Mon, 28 Feb 2000 15:14:36 GMT

On 26 Feb 2000 22:26:26 EST, [EMAIL PROTECTED] (Guy Macon) wrote:

>My current passphrase (which I use only with ciphersaber
>[ http://ciphersaber.gurus.com ] has 54 total characters,
>four punctuation characters, three high order ASCII characters,
>four numbers, and about 50% short english words.

I think you'd better go and change it now ...
-- 
Gordon Walker

------------------------------

From: Anton Stiglic <[EMAIL PROTECTED]>
Subject: Re: increasing key length through Hasing
Date: Mon, 28 Feb 2000 10:14:24 -0500

[EMAIL PROTECTED] wrote:

> I tried to increase key length for user supplied keys that were smaller
> than the maximum key length an algorithm could support. Below is the
> source code for that section of code [from Borland C++ Builder] -=- if
> anyone sees anything wrong with it or has a better way of doing
> something similar then please get back to me.
>

Hashing the key once (or twice, one time for each hash algo) does that
make the key much more secure.   When an attacker wants to do a
dictionary attack on small keys, he just has to hash the key the same
way you did.  Kelsey and al. have a paper called "Secure Applications
of Low-Entropy Keys" (I'm sure you can found it on www.couterpane.com)
in which they describe a way to stretch keys in a way that forces an
attacker doing a dictionary attack to spend alot of CPU time (they just
iterativley hash the key alot of times).
But in any case, I also have some comments on the code, the bellow:

>
> -Emrul
>
>  /* If keysize entered is less than keysize of algoirthm, data needs
>             to be hashed to at least the length of KeySize.*/
>         if ((state.Key.Length() * 8) < CryptAlgoData->KeySize)
>         {
>             TRMD160Context  RMDContext;
>             TRMD160Digest   RMDDigest;
>             TSHA1Context    SHAContext;
>             TSHA1Digest     SHADigest;
>             long            pos, x;
>             int KeyLength;
>             AnsiString      TmpStr;
>
>             pos = 0;
>             KeyLength = Key.Length();
>             RMD160Init(RMDContext);
>             SHA1Init(SHAContext);
>             /*
>                 1. Use RipMD160 Hash Algorithm to generate a 160bit
>                         hash.
>                 2. Feed the output of RipMD160 to SHA1 Hash algorithm
>                          and
>                     concatenate the ouput with the original input.
>                 3. Repeat 1 and 2 until the number of bytes of hash =
>                 the KeySize.
>             */
>             do
>             {
>                 RMD160Update(RMDContext, FinalKeyData, KeyLength);
>                 RMD160Final(RMDContext, RMDDigest);
>                 for (x = 0; x < 20; x++)
>                 {
>                     if (pos  <= (CryptAlgoData->KeySize / 8))
>                     {
>                         FinalKeyData[pos] = RMDDigest[x];
>                         KeyLength = pos;

You are affecting KeyLenght in each iteration or the if loop, you could
simply affect it at the end, outside of the if scope.

>
>                         pos++;

You can put that pos++ in the if, something like
    if (pos ++ <= (CryptAlgoData->KeySize / 8))

>
>                     }
>                     else
>                         break;
>                     }
>                 SHA1Update(SHAContext, FinalKeyData, KeyLength);
>                 SHA1Final(SHAContext, SHADigest);
>                 for (x = 0; x < 20; x++)
>                 {
>                     if (pos <= (CryptAlgoData->KeySize / 8))
>                     {
>                         FinalKeyData[pos] = SHADigest[x];
>                         KeyLength = pos;

Same comment here....

>                         pos++;
>                     }
>                     else
>                         break;
>                 }
>             } while (pos  < (CryptAlgoData->KeySize / 8));
>
>         } /* End key initialisation*/

You need to make sure that you overwrite everything that was in SHADigest
(and the
other hash context).  That is, write '0' in it to fill it up.   An
attacker could read 'left over'
memory and grab the key if not...


my $0.02...

Anton


------------------------------

From: [EMAIL PROTECTED] (John Savard)
Subject: Re: How do I get the key from the passphrase in DES?
Date: Mon, 28 Feb 2000 08:34:10 GMT

"Amit IG" <[EMAIL PROTECTED]> wrote, in part:

>I want to know the technique used for deriving the 64-bit key from an
>arbitrary length passphrase. The key is then used in DES.

As noted in other replies, there is no standard technique for doing
so. One technique that can be used is as follows:

1) Append a 1 bit to the end of the pass phrase.

2) Append as many 0 bits to the end of the pass phrase as required to
make it 8 more than a multiple of 56 bits in length.

3) Take the first 64 bits of the result, and subject it repeatedly to
the following operation, once for each remaining 56 bits in the padded
pass phrase:

Take the 64 bit value, encrypt it using the 56 bits from the pass
phrase as the key, and then XOR the 64 bit value used as input to DES
with the output from this DES encryption.

4) Convert the 64 bit result to a DES key in standard format by
replacing the _least significant_ bit of each byte by the value
required to give that byte odd parity.

John Savard (jsavard<at>ecn<dot>ab<dot>ca)
http://www.ecn.ab.ca/~jsavard/crypto.htm

------------------------------

From: [EMAIL PROTECTED] (Doug Stell)
Subject: Re: CRC-16 Reverse Algorithm ?
Date: Mon, 28 Feb 2000 15:33:24 GMT

On Sat, 26 Feb 2000 20:41:34 -0800, "Marty" <[EMAIL PROTECTED]> wrote:

>
>Doug Stell <[EMAIL PROTECTED]> wrote in message
>>
>> CRCs that are initialized to all zeros (CRC-16 is one of these) can
>> not detect the addition or deletion of leading zeros. Likewise, CRCs
>> that are initialized to all ones can not not detect the addition or
>> deletion of leading ones. That's why some CRCs initialize to some
>> known, fixed value that is neither all ones nor all zeros.
>
>Inserted and/or deleted ones at the start of a ones initialized CRC are
>indeed detected.

I am indeed wrong. A CRC initialized to all ones can detect inserted
and/or deleted leading ones.

doug


------------------------------

From: Johan Hoogenboezem <[EMAIL PROTECTED]>
Subject: Want to poke holes in this protocol?
Date: Mon, 28 Feb 2000 18:06:54 +0200

Hi Everyone,

Would some of you please help me to poke holes in this scenario?

1. A Bank called 'B' installs a program on a customer called Alice's
computer.
2. Alice uses this program to do her banking with B over the Internet.
3. The program generates a new secret key 'K' that is to be used for a
symmetrically encrypted conversation between Alice and B, encrypts it
using B's public key and sends it to B.
4. B takes its private key, decrypts the message, gets K and sets things
up to use K for symmetrical encryption/decryption between Alice and B.
5. From now on the conversation between Alice and B is encrypted using
K.
6. (Encrypted) The program now asks Alice to enter her password and
sends it to B.
7. (Encrypted) B takes the password and logs Alice on to B's systems.
8. (Encrypted) Alice does her banking.
9. Alice or B ends the conversation.

A few notes:
============
1. A 'B' representative installs the software on Alice's computer and
stores B's public key onto it.
2. Alice is solely responsible for restricting access to her computer.
3. Alice is solely responsible for keeping her password for logging onto
B's systems a secret.
4. A new secret key 'K' is generated and used every time Alice uses the
program.

So, what's wrong with this picture?

Thanks
Johan

email: [EMAIL PROTECTED]


------------------------------

Date: 28 Feb 2000 16:07:19 -0000
From: e n t r o p i c <[EMAIL PROTECTED]>
Subject: Re: Passwords secure against dictionary attacks?
Crossposted-To: comp.security.misc,alt.security.pgp

On Tue, 22 Feb 2000, Ilya <[EMAIL PROTECTED]> wrote:

>Is it secure to take two words and join them together, such as:
>
>crypto/life cyber@machine green-dog Loud!Music

A more secure method is described in the Diceware FAQ:

How can I use Diceware to make up a login password?

One way is to select two words using diceware. Then select a special
character using the chart below. Then stick the special character
between the two words instead of a space. Drop characters off the end
of the second word if the resulting password is too long for your
computer system. (Most Unix systems limit you to 8 characters, for
example.)

Example:

base<threw which truncates to the 8 character password base<thr

-- 
e n t r o p i c
on the brink of the dot com generation

------------------------------

From: Erik <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp,comp.security.pgp.discuss
Subject: Re: are self-shredding files possible?
Date: Mon, 28 Feb 2000 11:27:04 -0500

Wilfried Kramer wrote:
> The reason is IMHO very obvious. When you send a file to a recipient, he
> (or she) must take some action to read it. Of course it is possible to
> create a file, securely deleting itself after (or while) displaying the
> message.
> But the recipient can make a local copy _before_ reading it. How do you
> intend to handle this?

You could have a self-shredding file and built-in reader, all in a
tamper-resistant smartcard.

Erik

------------------------------

From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Want to poke holes in this protocol?
Reply-To: [EMAIL PROTECTED]
Date: Mon, 28 Feb 2000 16:26:27 GMT

Johan Hoogenboezem <[EMAIL PROTECTED]> wrote:

: 1. A Bank called 'B' installs a program on a customer called Alice's
: computer.
: 2. Alice uses this program to do her banking with B over the Internet.
: 3. The program generates a new secret key 'K' that is to be used for a
: symmetrically encrypted conversation between Alice and B, encrypts it
: using B's public key and sends it to B.
: 4. B takes its private key, decrypts the message, gets K and sets things
: up to use K for symmetrical encryption/decryption between Alice and B.
: 5. From now on the conversation between Alice and B is encrypted using
: K.

[snip encrypted banking bit]

: A few notes:
: ============
: 1. A 'B' representative installs the software on Alice's computer and
: stores B's public key onto it. [...]

: So, what's wrong with this picture?

Nothing terribly much that I can see.  You don't say how 'B's
representative authenticates himself to Alice.  The rest looks
ordinary enough.
-- 
__________
 |im |yler  The Mandala Centre  http://www.mandala.co.uk/  [EMAIL PROTECTED]

OK, make me an offer.  I have a computer to support.

------------------------------

From: Erik <[EMAIL PROTECTED]>
Subject: Re: Want to poke holes in this protocol?
Date: Mon, 28 Feb 2000 11:49:00 -0500

I'm working on something similar.  I think the biggest potential
weakness is the generation of the random key.  If it's generated from a
PRNG seeded with the current time, an adversary will likely know both
the algorithm you use and the approximate time of generation, making the
key not so random.

Erik


Johan Hoogenboezem wrote:
> 
> Hi Everyone,
> 
> Would some of you please help me to poke holes in this scenario?
> 
> 1. A Bank called 'B' installs a program on a customer called Alice's
> computer.
> 2. Alice uses this program to do her banking with B over the Internet.
> 3. The program generates a new secret key 'K' that is to be used for a
> symmetrically encrypted conversation between Alice and B, encrypts it
> using B's public key and sends it to B.
> 4. B takes its private key, decrypts the message, gets K and sets things
> up to use K for symmetrical encryption/decryption between Alice and B.
> 5. From now on the conversation between Alice and B is encrypted using
> K.
> 6. (Encrypted) The program now asks Alice to enter her password and
> sends it to B.
> 7. (Encrypted) B takes the password and logs Alice on to B's systems.
> 8. (Encrypted) Alice does her banking.
> 9. Alice or B ends the conversation.
> 
> A few notes:
> ============
> 1. A 'B' representative installs the software on Alice's computer and
> stores B's public key onto it.
> 2. Alice is solely responsible for restricting access to her computer.
> 3. Alice is solely responsible for keeping her password for logging onto
> B's systems a secret.
> 4. A new secret key 'K' is generated and used every time Alice uses the
> program.
> 
> So, what's wrong with this picture?
> 
> Thanks
> Johan
> 
> email: [EMAIL PROTECTED]

------------------------------

Subject: Encryption (only) in a extremely small program? (~1.4KB)
From: dywalsh <[EMAIL PROTECTED]>
Date: Mon, 28 Feb 2000 08:54:28 -0800

Is it possible to do public key ENcryption in a program of
approx. one and a half kilobytes?

[Backround:
I am investigating the idea of doing application level
encryption for WAP. There is a lower-level protocol for
encryption, WTLS, but apart from the weakness of that (see other
messages in this group), there a other issues in that you either
have to provide you own WAP gateway ($$$,hassle) or deal with
all the network providers (who may not have WTLS).]

This system would encrypt only. There is no need for decryption
(i.e. only need to encrypt sensitive user-entered info such as
passwords or credit details), and the keys would be generated on
the server. So all that is required is that this program encrypt
certain data using a public key provided by the server. The
language used would be WMLScript, a language derived from
javascript.

I am no expert on cryptography. What algorithms could be provide
this in such a small program, and how would the strength of
these algorithms compare with whatever is used in SSL?

For instance I have looked at the code of an implementation of
Blowfish, but for starters it defines a set of arrays with
values for Pi,Ss0 to S3, which alone is a massive amount of data
in this context.

Thank you for any help/pointers you can provide.


* 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: Glenn Larsson <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Want to poke holes in this protocol?
Date: Mon, 28 Feb 2000 17:54:17 +0100

- - - - - - - - - - - - - - - - - - - - - - - - - - - - -
From: 'B' Bank. (Using faked email adress, ofcourse)
To: Alice.
Subject: Critical Upgrade - install now.

...yada yada yada... our brainless technician forgot to
install this critical piece of software... blah blah...
please install this file called Tro_jan.EXE by starting
it in Windows.

Regards,

Mr Compro M. Ise.
'B'-bank Security/Technical support.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Geddit?

.Reg's
Ichinin
A.S.C.
_________________________________________________

Spammers will be reported to their government and
Internet Service Provider along with possible legal
reprocussions of violating the Swedish "Personal
Information Act" of 1998. (PUL 1998:204)

This is punishable by a fine or 6 month to 2 years
imprisonment (Paragraph 49)

------------------------------


** 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
******************************

Reply via email to