I've always wondered if there could be another "dimension" to encryption beyond
the basic two. I forget the name of the famous British double-agent (working with the
British against the Germans) who would use both methods of transposition and
substitution, but then add a third element or "dimension" to the ciphertext:
invisibility... as he would then write the message in invisible ink.

Although the idea of invisible ink today may seem quaint, even childish, as it
relates to computers there may be a way to implement what we might tentatively call
"binary invisibility" as a mathematical function, most likely depending on some
shared, likely secret but also ephemeral, inner workings of the systems on which the
communication is processed.

To create a new "publicly shared information" cryptosystem entirely that is non prime
dependent (i.e. non RSA), I think one must begin by first looking at the nature of
knowledge itself. for example, if I send someone the message:

MEET ME AT FOGGY CREEK BRIDGE AT ONE PM

Then that message is fairly unambiguous. The only real assumption made is that the
recipient knows where Foggy Creek bridge is (there are more, but they are mere
linguistic, trans derivational assumptions and not relevant in this case). If I send
the message:

FOGGY CREEK BRIDGE ONE PM

"Tom St Denis" gmail.com> wrote in message
news:1164853529.527080.227070@j44g2000cwa.googlegroups.com...

The best;

http://en.wikipedia.org/wiki/Hash_brown

Have you considered aggregate signatures? If you set things up right,
you can arrange for a set {P1,..,Pn} of parties to sign the packet.
The space needed is roughly the number of bits needed to represent
the identities of the parties who have signed it, plus 160 bits or so
for a single signature field that aggregates all the signatures of all
the signers.

http://crypto.stanford.edu/~dabo/abstracts/aggsurvey.html
http://crypto.stanford.edu/~dabo/abstracts/aggreg.html

I've been asked to (and have) write some simple bios verification code
for the OLPC (laptop.org) project. Essentially, they wanted a simple
tool where they could sign a bios with various algorithms (in case one
dies in the future) and then verify it from the BIOS side (which has no
libc).

I've written the following code

http://libtomcrypt.org/cock.htm

Which is very rough [but functional] initial code that uses LTC and TFM
to perform the crypto (what else?).

The code fits in at around 70KB, and uses 64KB of heap so it's nice and
small (could be smaller I suppose but I do include both RSA and ECC,
Whirlpool and SHA512 in there, as well as an ASN1 library...)

Basically there are two pieces of code. The cli_tool can make keys,
signatures and verify the signatures. The bios_side is a rough stub
for what will be placed in the BIOS (with suitable use of -fPIC for
instance).

The signatures and key formats are ASN.1 encoded (to make porting this
to another library in the future possible if need be). The key format
is basically

Does anyone have a good source for HSMs? We currently have ones from
SafeNet (Previously Eracom Tech) but they do not have any APIs that
work with VB.Net.

Any advice on interfacing with a Protect Server Orange from VB.Net or a
recomendation of another HSM would be great!

Thank you
Karl

Consider two peers A and B.
B wants to verify the authenticity of every message sent by A.
Then they adopt this scheme:

A keeps a 32bit number c, which is simply incremented by one for each
sent message.
When they establish a connection,
A initialises c to a random number,
A and B exchange their public keys and
A sends c to B. B saves c to d.

A, for every message, increments by one c and appends c' in the
message. c' is

c'=private_encrypt(c+1, A_privk)

B, to verify the authenticity of the received message, will compare

public_decrypt(c', A_pubk) == d+1

If the comparison is true, then the message is authentic and d will be
incremented by one.

Peter Fairbrother wrote:

I would look at the nShield range from nCipher.

http://www.ncipher.com/cryptographic_hardware/hardware_security_modules/8/nshiel...

For $10k you are probably looking at a nShield 2000 - which does 2000
1024-bit RSA private key operations a second.

If you can stretch a little there is a 4000 tps model.

Pubkeybreaker wrote:

A high-end desktop, say a gigE twin opteron/Xeon with 2 GB ram.

I'd hope not - I was hoping for commercial add-on cards, or perhaps suitable
systems for the more expensive amounts.

Peter Fairbrother wrote:

VIA x86 processors have a cryptography engine that now includes a
Montgomery multiplier.

The following document gives some performance figures for modular
exponentiation using either GMP or the VIA ACE engine:

http://www.via.com.tw/en/downloads/whitepapers/initiatives/padlock/programming_guide...

http://tinyurl.com/v5qus

Unfortunately it requires some study of the sample code to work out what
the numbers given really mean.

Brian Gladman

Hello,

in this page :
http://www.bright-shadows.net/challenges/javascript_harlequin_relee/8453ShiftS.h...

there is a ripe-md cipher
I am not sure, but i think the code has been modified and becoming
subject to simple brute force attack.

The challenge is to retrieve the word of this hash :
3375c1ba423a79b91afa8e7ace64d791409d4d28

Word length = 12
Chars : [a - o]

Do you have an idea ? Have you seen some suspects parts of code ?

Original implementation of ripemd algorithm in javascript :
http://www.java2s.com/Code/JavaScript/Security/RIPEMD160HashinginJavaScript.htm

Thanks