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
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 chris@funkyobjects.org 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 Cryptography@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cryptography
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 luchiano@gmail.com 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 chris@funkyobjects.org 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 Cryptography@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cryptography
Cryptography mailing list Cryptography@lists.squeakfoundation.org 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 spakala@gmail.com 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 luchiano@gmail.com 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 chris@funkyobjects.org 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 Cryptography@lists.squeakfoundation.org
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cryptography
Cryptography mailing list Cryptography@lists.squeakfoundation.org
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cryptography
Cryptography mailing list Cryptography@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cryptography
Hi, Thank you. It is just a small project so no need to worry about the hacker. Can you please give me some more information how to proceed. you said that the GPG ask the user to type some random charaters to seed the random numbers and we can give fingeprint image. I need some more information about that.If you have any code please send me. Thanks, Pakala
On 2/16/06, luciano luchiano@gmail.com wrote:
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 spakala@gmail.com 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 luchiano@gmail.com 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 chris@funkyobjects.org 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 Cryptography@lists.squeakfoundation.org
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cryptography
Cryptography mailing list Cryptography@lists.squeakfoundation.org
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cryptography
Cryptography mailing list Cryptography@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cryptography
Cryptography mailing list Cryptography@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cryptography
cryptography@lists.squeakfoundation.org
-
Chris Muller -
luciano -
satru pakala