Fortuna

> PRNG I plan to work on Bruce's FORTUNA implementation for squeak.

Hi, KryptOn is an all-Smalltalk implementation of purely the ideas in Practical Cryptography.  I have already implemented the Fortuna generator as specified in Chapter 10 (via AES in Bruce's preferred CTR mode).

Perhaps you would like to do the accumulator?

 - Chris



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

Hi Chris!  

How are you doing?  I knew that you improved secure random, and had
mentioned the need for adding the accumulator.  Is there more in KryptOn in
terms of PRNG that is not already included in SecureRandom?  I will spend
some time looking at KryptOn to see if there is stuff that could be useful
our overall platform in the Cryptography package.  Your suggestions are
welcome!

Many of the ideas in Practical Cryptography especially keeping secrets -
Data retention by Memory 9.3.4 using Fortuna (with a proper accumulator) as
a PRNG seem to be quite sufficient ways to protect Secure Channel keys on a
client machine.  Even knowing how it all works, I would think it would be
very difficult for me to break the code, unless I was able to introduce new
code into the running system.  So if we can solve the problem of introducing
new code, and we could add Fortuna and some of the requirements Practical
Cryptography for protecting secrets I would think we are a long way towards
making a very secure channel implementation for a client system.

I hope that you will consider helping out with all this!

Nice to hear from you!

Ron


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

Hi!  I'm doing very well.

Fortuna is actually not part of KryptOn, it's its own package (one class, 9 methods) which KryptOn loads as a prereq in advance of itself.  This way Fortuna can be used on its own as just another RandomGenerator subclass, without KryptOn.

KryptOn does not, itself, implement any security primitives, only uses the ones from our Crypto library.

To implement Fortuna, I factored SecureRandom into a superclass, RandomGenerator,

    RandomGenerator
        SecureRandom
        Fortuna

so that code wouldn't be duplicated.  RandomGenerator has but five methods:

    nextBits: bitLength
        "answer a random integer up to size bitLength"
            subclassResponsibility

    nextBytes: anInteger
        "Generate and answer a ByteArray of size anInteger filled with random data."
            subclassResponsibility

    nextFrom: start to: end
           "Answer a random integer between start and end."

    nextInt: anInteger
        "Answer a random integer in the interval [1, anInteger]."

    destroy
        "destroy seed keys, etc."
        subclassResponsibility

and Fortuna and, now, SecureRandom, override the proper methods accordingly.  Though Fortuna is "done" I never did post it to the Crypto library yet because I got side-tracked earlier this year to do the (significant) query's function for Magma.  Also, I didn't think there would be much interest in it.  If there is, I'll see about packaging it up and posting it.

I do plan to return and finish KryptOn.  It's been long enough that I feel I'll have to read through the whole book again and scruntinize my code closely (this will be the "third" time doing so!).  This is always good though, to review with a fresh, suspicious perspective again.  The goal is to allow Magma to run naked on the Net without being hacked, supporting two-tier Squeak applications.

> Even knowing how it all works, I would think it would be
very difficult for me to break the code, unless I was able to introduce new
code into the running system.  So if we can solve the problem of introducing
new code, and we could add Fortuna and some of the requirements Practical
Cryptography for protecting secrets I would think we are a long way towards
> making a very secure channel implementation for a client system.

Yeah, right now KryptOn makes no attempt to protect the image once its launched other than killing keys as soon as possible after they're not needed anymore.  But still, you gotta have *some* keys in memory, how else can you decrypt or sign?  

I don't see how its possible to know whether the image has been tampered since it's been launched unless you have special hardware or, at least, special VM (but then how could the VM know it was not modified to not validate itself?).  It sounds even harder than knowing for sure if one is not truly crazy, or living in a simulated world (http://www.simulation-argument.com/), for example..  :)

So, Bravo to you for taking this on.  It's way beyond my ambition, much less ability.

Regards..


Message: 1
Date: Sun, 22 Oct 2006 16:43:26 -0400
From: "Ron Teitelbaum" <[hidden email]>
Subject: RE: [Cryptography Team] Fortuna
To: "'Cryptography Team Development List'"
    <[hidden email]>
Message-ID:
    <!&!AAAAAAAAAAAYAAAAAAAAALn4DBa9j89Bkul53Jf1ky/CgAAAEAAAABVgndAuNIVHtVtWJUGxVIwBAAAAAA==@USMedRec.com>
   
Content-Type: text/plain;    charset="us-ascii"

Hi Chris!

How are you doing?  I knew that you improved secure random, and had
mentioned the need for adding the accumulator.  Is there more in KryptOn in
terms of PRNG that is not already included in SecureRandom?  I will spend
some time looking at KryptOn to see if there is stuff that could be useful
our overall platform in the Cryptography package.  Your suggestions are
welcome!

Many of the ideas in Practical Cryptography especially keeping secrets -
Data retention by Memory 9.3.4 using Fortuna (with a proper accumulator) as
a PRNG seem to be quite sufficient ways to protect Secure Channel keys on a
client machine.  Even knowing how it all works, I would think it would be
very difficult for me to break the code, unless I was able to introduce new
code into the running system.  So if we can solve the problem of introducing
new code, and we could add Fortuna and some of the requirements Practical
Cryptography for protecting secrets I would think we are a long way towards
making a very secure channel implementation for a client system.

I hope that you will consider helping out with all this!

Nice to hear from you!

Ron




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

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


End of Cryptography Digest, Vol 12, Issue 30
********************************************




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

> From: Chris Muller
> Sent: Tuesday, October 24, 2006 9:38 PM

> and Fortuna and, now, SecureRandom, override the proper methods
> accordingly.  Though Fortuna is "done" I never did post it to the Crypto
> library yet because I got side-tracked earlier this year to do the
> (significant) query's function for Magma.  Also, I didn't think there
> would be much interest in it.  If there is, I'll see about packaging it up
> and posting it.

Please do it will be an excellent starting point!

> I don't see how its possible to know whether the image has been tampered
> since it's been launched unless you have special hardware or, at least,
> special VM (but then how could the VM know it was not modified to not
> validate itself?).  It sounds even harder than knowing for sure if one is
> not truly crazy, or living in a simulated world (http://www.simulation-
> argument.com/), for example..  :)

The argument is silly since the logic is circular and demonstrates Theorem 8
in symbolic logic.  My favorite example of the sound logic of these
statements is: If the universe doesn't exist then I am king of the world.
Sure it's true but not very useful!  As for the VM there are some good
techniques that can be used to lock it down.  If Java could do it then we
can too!  We just need to take this on one step at a time and put ourselves
on a reasonable path towards improvement.

It's nice to hear form you!  If you have time I would love to see your
participation in our validation project.  

Ron


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