[Cryptography Team] Re: Fortuna

Wed Oct 25 01:38:25 UTC 2006

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" <Ron at USMedRec.com>
Subject: RE: [Cryptography Team] Fortuna
To: "'Cryptography Team Development List'"
    <cryptography at lists.squeakfoundation.org>
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

> -----Original Message-----
> From: cryptography-bounces at lists.squeakfoundation.org
> [mailto:cryptography-bounces at lists.squeakfoundation.org] On Behalf Of
> Chris Muller
> Sent: Saturday, October 21, 2006 12:13 PM
> To: cryptography at lists.squeakfoundation.org
> Subject: [Cryptography Team] 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
> Cryptography at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cryptography

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

_______________________________________________
Cryptography mailing list
Cryptography at lists.squeakfoundation.org
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cryptography

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