Re: #3655 (Specify the order of the Activity taskbar icons)

[Mitch Bradley]

>> <  I'd say...  our priority (or our message) should be more on the
>> "hard fun" items.
>> 
>>>   What do you think?
>>>   

I think that children will do what they consider fun, regardless of our 
priorities or "message".

It largely doesn't matter which particular activities are "emphasized" 
by preferred placement.  So long as activities are not so well hidden as 
to be undiscoverable, within short order the group of children as a 
whole will have seen all of them, and individuals and groups will 
gravitate toward the ones they find appealing.

You can't make people be interested in what you think is good for them.

___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: #3655 (Specify the order of the Activity taskbar icons)

[Yoshiki Ohshima]

  SJ,

> <  I'd say...  our priority (or our message) should be more on the
> "hard fun" items.
> >
> >   What do you think?
> 
> I largely agree.  I would put persistent collaboration on a par with
> hard fun; but then I think multiplayer notepad is among the greatest
> games ever.  And certainly combining the two is something to focus on.
> 
> Some of the better instances of 'hard fun' have learning curves and
> network effects that aren't immediately obvious; emphasis helps to get
> communities to a sweet spot of shared use and feedback.

  I have trouble to figure out what you are agreeing with and what is
this multiplayer game thing.

  Anyway, I'm not entirely sure the "persistent collaboration" is that
big idea.  When you are reading a book, and especially when you are
getting an idea that is going to contradict with the stuff written in
the book, you definitely don't want to hear from your peers or
teachers or talk about your idea too early; that is a recipe for
killing a radical idea.  Collaboration at the right time will
definitely help, but when you are engaging deep thought is not when.

-- Yoshiki
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: Performance tuning for the XO

[C. Scott Ananian]

On 9/22/07, NoiseEHC <[EMAIL PROTECTED]> wrote:
> There is a crypto++ library:
> All in all, include in speed testing.

I'm aware of this library.  Really, what I'd like now is a volunteer
to do the speed tests.
 --scott

-- 
 ( http://cscott.net/ )
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: Performance tuning for the XO

[C. Scott Ananian]

On 9/22/07, Albert Cahalan <[EMAIL PROTECTED]> wrote:
> You don't seem terribly committed to any particular hash.
> How about picking one that the Geode is especially good at?
> You have AES acceleration hardware, and there are several
> ways to turn a block cipher like AES into a hash.

This is actually surprisingly hard.  There are cryptoanalytic attacks
which establish broad vulnerabilities in all block-cipher-as-hash
constructions which don't rekey frequently.  The accepted
constructions rekey every 16 bytes.  And the result is a 128-bit hash
function, which is not very strong.

See http://en.wikipedia.org/wiki/One-way_compression_function :
| Using a block cipher to build the one-way compression function for a
hash function is
| usually much slower than using a specially designed one-way
compression function in
| the hash function. This is because all known secure constructions do
the key scheduling
| for each block of the message. It has been shown that without
repeated key scheduling it
| is impossible to construct a secure block cipher based hash
function[1]. In practice
| reasonable speeds are achieved provided the key scheduling of the
selected block cipher
| is not a too heavy operation.
|
| [1] John Black, Martin Cochran, and Thomas Shrimpton. On the Impossibility of
| Highly-Efficient Blockcipher-Based Hash Functions. Advances in Cryptology --
| EUROCRYPT '05, Aarhus, Denmark, 2005

Note that this attack also applies to trying to use a MAC as a hash function.

AES was selected to support fast rekeying (
http://csrc.nist.gov/CryptoToolkit/aes/round2/r2report.pdf ).
I had a discussion with the AMD folk about the key scheduling speed of
the Geode's implementation, however, and they were not optimistic that
one could rekey every block (as required by any secure AES-as-hash
construction) and obtain good performance.  It's been on my to-do list
for a while to test that assumption, but more pressing tasks have
intervened.

If you want to play around with timing this yourself, the AES features
are described in section 6.11 (page 510) of the Geode LX reference
manual linked from http://wiki.laptop.org/go/Geode_instruction_set.

> (too late wish: hashing in the NAND controller chip)

I'd settle for storing a hash in the filesystem metadata, so that we
don't have to rehash files which haven't changed since they were last
hashed.  For upgrades, this is a very common case.
 --scott

-- 
 ( http://cscott.net/ )
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: Performance tuning for the XO

[NoiseEHC]

There is a crypto++ library:

hash functions SHA-1 , SHA-2 
 (SHA-224, SHA-256, 
SHA-384, and SHA-512), Tiger , 
WHIRLPOOL , RIPEMD-128, 
RIPEMD-256, RIPEMD-160, RIPEMD-320

It has an MMX Whirlpool, and SSE2 SHA implementation.
The problem is that it is written in C++ and assembly and the MMX 
implementation could be slower than the C++ one on the Geode. see:
http://wiki.laptop.org/go/Geode

All in all, include in speed testing.

C. Scott Ananian wrote:
> On 9/22/07, Mitch Bradley <[EMAIL PROTECTED]> wrote:
>   
>> Some timing for libtomcrypt with various compilation options.  All times
>> are for hashing 1MiB of data from memory, timed under Open Firmware with
>> interrupts disabled.
>> 
> [...]
>   
>> So, with this code, the slow version does sha256 at about 4 MiB/sec, the
>> fast version does sha256 at about 5.3 MiB/sec, and rm160 goes at 9
>> MiB/sec in all cases.
>> 
>
> Hmm.  I did browse through all the SHA256 implementations I could
> find, looking at libtomcrypt, libgcrypt, and openssl in particular.
> Most of what I've seen has followed the definitions in the SHA
> standard pretty closely; unrolling the loops seems to be the only
> common "optimization".  Assuming you were starting from portable C
> code, it seems that compiler quality had the most effect, which made
> me realize that I don't actually know the appropriate machine type to
> pass the the GCC optimizer, prompting my original post.
>
> Some more SHA256 implementations I found which claim to be optimized:
>http://www.ouah.org/ogay/sha2/
>http://fp.gladman.plus.com/cryptography_technology/sha/index.htm
>
> I'd gladly accept a volunteer to go through and benchmark different
> implementations on XO hardware.  From my initial investigations, it
> seems like we should use RIPEMD-160 for bulk hashing of filesystem
> data.  There were some recent cryptoanalytic results against RIPEMD,
> however; I need to go off and reread them to get a sense for its
> current level of security.
>  --scott
>
>   
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: Performance tuning for the XO

[C. Scott Ananian]

On 9/22/07, Mitch Bradley <[EMAIL PROTECTED]> wrote:
> Some timing for libtomcrypt with various compilation options.  All times
> are for hashing 1MiB of data from memory, timed under Open Firmware with
> interrupts disabled.
[...]
> So, with this code, the slow version does sha256 at about 4 MiB/sec, the
> fast version does sha256 at about 5.3 MiB/sec, and rm160 goes at 9
> MiB/sec in all cases.

Hmm.  I did browse through all the SHA256 implementations I could
find, looking at libtomcrypt, libgcrypt, and openssl in particular.
Most of what I've seen has followed the definitions in the SHA
standard pretty closely; unrolling the loops seems to be the only
common "optimization".  Assuming you were starting from portable C
code, it seems that compiler quality had the most effect, which made
me realize that I don't actually know the appropriate machine type to
pass the the GCC optimizer, prompting my original post.

Some more SHA256 implementations I found which claim to be optimized:
   http://www.ouah.org/ogay/sha2/
   http://fp.gladman.plus.com/cryptography_technology/sha/index.htm

I'd gladly accept a volunteer to go through and benchmark different
implementations on XO hardware.  From my initial investigations, it
seems like we should use RIPEMD-160 for bulk hashing of filesystem
data.  There were some recent cryptoanalytic results against RIPEMD,
however; I need to go off and reread them to get a sense for its
current level of security.
 --scott

-- 
 ( http://cscott.net/ )
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: Performance tuning for the XO

[Albert Cahalan]

C. Scott Ananian writes:

> We make currently make heavy use of hashing in our upgrade &
> verification infrastructure.  I'd like to find the fastest possible
> implementation of the SHA-256 and/or RIPEMD-160 algorithms.

If it has to be SHA-256 or RIPEMD-160, I don't think you'll
be finding any miracle cure. The computation itself is hard.

Assuming the Geode actually does something with the cache
prefetch instructions, you might gain a tiny bit there.
This is unlikely to be your bottleneck though.

You don't seem terribly committed to any particular hash.
How about picking one that the Geode is especially good at?
You have AES acceleration hardware, and there are several
ways to turn a block cipher like AES into a hash.

Examples:
http://en.wikipedia.org/wiki/One-way_compression_function

BTW, if the EEPROM for secure key storage is available,
then message authentication codes become an option.
This is probably much faster than a hash.

Examples: Poly1305-AES, hash127-AES, CBC-MAC-AES

(too late wish: hashing in the NAND controller chip)
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: Performance tuning for the XO

[Mitch Bradley]

C. Scott Ananian wrote:
> We make currently make heavy use of hashing in our upgrade &
> verification infrastructure.  I'd like to find the fastest possible
> implementation of the SHA-256 and/or RIPEMD-160 algorithms.  Can
> anyone offer me advice on the proper compilation options and
> strategies for maximum performance on the processor in the XO?  I
> don't see the -mxo option to gcc yet.
>  --scott
>   

Some timing for libtomcrypt with various compilation options.  All times 
are for hashing 1MiB of data from memory, timed under Open Firmware with 
interrupts disabled.

Hash
-DLTC_SMALL_CODE, -Os
large code, -Os
large code, -O2
sha256
249 mS
202 mS
189 mS
sha512
373 mS
347 mS
358 mS
rmd160
111 mS
112 mS
112 mS


-DLTC_SMALL_CODE causes rolled (as opposed to unrolled) loops in 
sha256.c and sha512.c, but is not used in rmd160.c

The code size for the bios_hash binary is about 20K with rolled loops, 
about 44K with unrolled loops.

So, with this code, the slow version does sha256 at about 4 MiB/sec, the 
fast version does sha256 at about 5.3 MiB/sec, and rm160 goes at 9 
MiB/sec in all cases.




___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel