CTR mode, SecureRandom, ElGamal updates

Nice! Thanks!
Wow, the generation of the 2048-bit key takes 10 hours? I'll see if I
can improve that.

Luciano

On 2/16/06, Chris Muller <[hidden email]> wrote:
> Hi, this is just note to keep everyone informed about
> what I've done.  Sorry its long, I will try to keep it
> newsworthy and dense.   I have begun committing my
> initial Cryptography improvements as promised.  I just
> committed the following to our repository:
>
> For CryptographyBase:
>
> - Updated all usages of standard Random to use

> SecureRandom.  This now allows calculation of 512,
> 1024, 2048 and, computational power permitting, larger
> keys.  According to Schneier, Ferguson - "Practical
> Cryptography" p. 217:
>         "A prime of 2048 bits can be expected to secure data
> until around 2022; 3072 bits is secure until 2038; and
> 4096 bits until 2050." ...  "Be careful with these
> kinds of predictions."
>
> - Extended SecureRandom with #nextInt: and
> #nextFrom:to:.  The implementation just keeps calling
> nextBits: until an in-range is returned, and it passed

> a simple dispersion test.

>
> - As a substitute for Collection
> class>>#randomForPicking, we now have SecureRandom
> class>>#picker.  This keys of this are wiped out and
> regenerated on every image save, since saving the key
> to disk is not recommended.
>
> - Added SecureRandom class>>#withGeneratedKey.  This
> enumerates a series of relatively unpredictable
> Strings such as the bitmap of the current Squeak
> desktop, mouse position, Timer values, etc.
>
> - Fixed printOn:
>
>
> For Cryptography-Core:
>
> - Addition of CTR (counter) cipher mode.  In
> "Practical Cryptography" Schneier reasons this is
> preferred mode due to its simple implementation and no
> need for padding.
>
> - Added LargePositiveInteger>>#destroy to permit
> wiping of keys from the image at proper times.
>
>
> For Cryptography-ElGamal
>
> - Now using SecureRandom instead of (insecure) Random.
>
>
> For Cryptography-Tests
>
> - The ElGamal cryptography tests let us down in terms
> of testing for practical usage.  They were using
> 15-bit keys which totally obscured the problem with
> the Random, which could not even generate numbers
> large enough for the primes associated with 2048-bit
> asymmetric keys (not to mention 1024 and 512!).
> Therefore, I upgraded the tests to use 384
> (generated), 512, 1024, 2048 bit ElGamal keys.  The
> 2048-bit took 10 hours (!!) to generate, so I
> instantiate with its #storeString so that the tests
> run quickly.
>
> - Also beefed up the associated DiffieHellman test to
> use 384 bit keys (probably should test these with the
> same key sizes as ElGamel).
>
> - Because of the enhanced tests, there are more
> methods, so I recategorized according to what they are
> testing; "ElGamal", "DSA", "RSA", etc.  However, I'm

> beginning to think we should move these tests to their
> individual packages of what they're testing.  What
> does everyone else think?
>
> That's all for now, I hope you like it..!
>
>  - Chris
> _______________________________________________
> Cryptography mailing list
> [hidden email]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cryptography
>
_______________________________________________
Cryptography mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cryptography

Hi Pakala,
You cannot use the fingerprint image directly as key, but you could
use the fingerprint image as a source of randomness for the key
generation algorithm. For instance, the RSA key generation algorithm
must find two large prime numbers, and those primes must be different
for every key and are generated at random. Usually, programs like GPG
ask the user to type some random characters to seed the random numbers
generator that is used to find those prime numbers. You could use the
fingerprint image instead. However, I'm not sure you'll actually want
to generate keys from potentially public information like
fingerprints, since this could help an attacker (an attacker with
access to the same fingerprint image would be able to generate the
private key).

Hope this helps, don't hessitate to ask.
Luciano


On 2/16/06, satru pakala <[hidden email]> wrote:

> Hi,
> I am new to this group. I have a question about generation of cryptographic
> keys.
> Is it possible to generate public and private keys from a String? i mean
> what i am doing is i am taking a fingrprint image and i am converting it to
> Stirng then from that string i have to generate keys.i don't know whether we
> can do like that or not? Please tell me is there anyway to generate keys
> from an inputted image or a Stirng or array of bytes?
> Thanks,
> Pakala
>
>
>
> On 2/16/06, luciano <[hidden email]> wrote:

> > Nice! Thanks!

> > Wow, the generation of the 2048-bit key takes 10 hours? I'll see if I
> > can improve that.
> >
> > Luciano
> >
> > On 2/16/06, Chris Muller < [hidden email]> wrote:
> > > Hi, this is just note to keep everyone informed about
> > > what I've done.  Sorry its long, I will try to keep it
> > > newsworthy and dense.   I have begun committing my
> > > initial Cryptography improvements as promised.  I just
> > > committed the following to our repository:
> > >
> > > For CryptographyBase:
> > >
> > > - Updated all usages of standard Random to use
> > > SecureRandom.  This now allows calculation of 512,
> > > 1024, 2048 and, computational power permitting, larger
> > > keys.  According to Schneier, Ferguson - "Practical
> > > Cryptography" p. 217:
> > >         "A prime of 2048 bits can be expected to secure data
> > > until around 2022; 3072 bits is secure until 2038; and
> > > 4096 bits until 2050." ...  "Be careful with these
> > > kinds of predictions."
> > >
> > > - Extended SecureRandom with #nextInt: and
> > > #nextFrom:to:.  The implementation just keeps calling
> > > nextBits: until an in-range is returned, and it passed
> > > a simple dispersion test.
> > >
> > > - As a substitute for Collection
> > > class>>#randomForPicking, we now have SecureRandom
> > > class>>#picker.  This keys of this are wiped out and
> > > regenerated on every image save, since saving the key
> > > to disk is not recommended.
> > >
> > > - Added SecureRandom class>>#withGeneratedKey.  This
> > > enumerates a series of relatively unpredictable
> > > Strings such as the bitmap of the current Squeak
> > > desktop, mouse position, Timer values, etc.
> > >
> > > - Fixed printOn:
> > >
> > >
> > > For Cryptography-Core:
> > >
> > > - Addition of CTR (counter) cipher mode.  In
> > > "Practical Cryptography" Schneier reasons this is
> > > preferred mode due to its simple implementation and no
> > > need for padding.
> > >
> > > - Added LargePositiveInteger>>#destroy to permit
> > > wiping of keys from the image at proper times.
> > >
> > >
> > > For Cryptography-ElGamal
> > >
> > > - Now using SecureRandom instead of (insecure) Random.
> > >
> > >
> > > For Cryptography-Tests
> > >
> > > - The ElGamal cryptography tests let us down in terms
> > > of testing for practical usage.  They were using
> > > 15-bit keys which totally obscured the problem with
> > > the Random, which could not even generate numbers
> > > large enough for the primes associated with 2048-bit
> > > asymmetric keys (not to mention 1024 and 512!).
> > > Therefore, I upgraded the tests to use 384
> > > (generated), 512, 1024, 2048 bit ElGamal keys.  The
> > > 2048-bit took 10 hours (!!) to generate, so I
> > > instantiate with its #storeString so that the tests
> > > run quickly.
> > >
> > > - Also beefed up the associated DiffieHellman test to
> > > use 384 bit keys (probably should test these with the
> > > same key sizes as ElGamel).
> > >
> > > - Because of the enhanced tests, there are more
> > > methods, so I recategorized according to what they are
> > > testing; "ElGamal", "DSA", "RSA", etc.  However, I'm
> > > beginning to think we should move these tests to their
> > > individual packages of what they're testing.  What
> > > does everyone else think?
> > >
> > > That's all for now, I hope you like it..!
> > >
> > >  - Chris
> > > _______________________________________________
> > > Cryptography mailing list
> > > [hidden email]
> > >
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cryptography
> > >
> > _______________________________________________
> > Cryptography mailing list
> > [hidden email]
> >
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cryptography
> >
>
>
> _______________________________________________
> Cryptography mailing list
> [hidden email]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cryptography
>
>
>

_______________________________________________
Cryptography mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cryptography