My application uses SRP for authentication and then uses the random
session data produced during the SRP authentication process to seed
3DES for encrypting the actual communications.

My question. Once encryption is set up, my application does its own
signon handshake. The data in that handshake is pretty much
constant. Is that a big security hole, or does 3DES do more than XOR
the data against a bit unknown (and changing) value? For example,
does 3DES send the data bytes in a random order or do anything else
that would make it impossible to guess the key based on knowing the
data that's being encrypted?

If not, are there recommendations for 'randomizing' the communications
to fix the problem. Something like inserting random numbers into
unused places in the data stream prior to encryption.

Thanks,
Rob

It was only when other readers in sci crypt took me to task recently
for wrongly claiming and understandably so from their perspective,
that a one-way function is a powerful tool that underwrites
theoretically unbreakable cryptography that this writer came to
realize the hole that exists in our separate understanding of what
this is. The authors of popular handbooks, Bruce Schneier for
instance, are understandably hesitant to make statements that won’t
stand up under close mathematical rigour and these people say that
there is considerable doubt that any one-way functions exist in
mathematics. Bruce Schneier pointedly agrees to pretend that they do
exist just to smooth the ways for imparting his knowledge of hard
functions in “Applied Cryptography” p29.

The writer has used a change-of-origin to a frame of reference as an
intuitive act in a cipher realizing that this is a truly definitive
one-way function. The writer will defy any attempt to say one-way
functions do not exist. It is incredible that it should be necessary
to labour the point of the existence of this very obvious ploy in
vector or coordinate geometry methods. It is a vector function formed
by the addition of a constant vector to vector zero (0).

In Vector Cryptography Alice and Bob calculate displacements relative
to the arbitrary origin defined as vector zero or in coordinate terms
(0, 0, 0). At the end of the calculation they collude and
deliberately confuse an adversary by means of giving the computed
displacement an agreed change-of –origin, (this is school level stuff)
and the new relative displacement is now the cipher text.

This ploy of a change-of-origin is a perfectly proper mathematical
function. This function has no mathematical inverse however and the
only way of reversing it is to put the entities on the rack and force...

Hi,

In the RFC 4493, i find the source code in C language for AEC CMAC
algorithm.
I find that there is an API called as AES_128 . But, there is no
definition for that API :( :(
Can anyone give me a definition for the AES_128 API that is being
used in the RFC 4493.
Is there any link for the definition of AES_128 ?

Below is an extract from RFC 4493 for your reference :-
" printf("\nSubkey Generation\n");
AES_128(key,const_Zero,L);
printf("AES_128(key,0) "); print128(L); printf("\n");
"

Thx in advans,
Karthik Balaguru

http://www.adacrypt.com
Quote from “ Handbook of Applied Cryptography” – A.Menezes, Paul Van
Oorsccot, S Vanstone. “The One-Time Pad can be shown to be
theoretically unbreakable. That is, if a cryptanalyst has a cipher
text string encrypted using a random key string which has been used
only once, the cryptanalyst can do no more than guess at the plaintext
being any string of length ‘t’ ( i.e., t-bit binary strings are
equally likely as plaintext). It has been proven that that to realize
an unbreakable system requires a random key of the same length as the
message – Unquote.

In default of the latter requirement the message string is then some
float multiple of the key string and the numbers of the component data
variables in the key string will not be equal, implying unequal
probability and therefore not a random key. A theoretically
unbreakable system cannot then be claimed in the absence of
randomness.

The world's finest independent booksellers
New, Used, Rare Books & Textbooks
Lowest shipping rates on the Web:
Free shipping in the USA, and $2.97 shipping worldwide.
Deep savings (up to 90%%) on college textbooks.
http://sciandtechbooks.blogspot.com/

I'm a glutton for punishment and I'm getting an iphone. :)

Anyone know of a PKCS#12 implementation in Javascript?

Hello,
Can anyone tell me if there is a conventional byte order for DES?
That is, when reading octet strings into the 64-byte blocks that DES
operates on? I can't find any clear indication in the specification. I
realize it's largely irrelevant, but it seems to matter for a padded
block. Is there any agreement on this matter "in the community"? Or
does it vary by implementation.

Regards,
--jonathan

My team have a legacy web login system use a homemade md5 MAC like MAC
= MD5(key || Message) and MAC = MD5(key XOR Message). As a programmer
knowing some cryptography, I believe it is a worse design compared to
the official rfc2104 HMAC. Still, it looks "secure enough" to some of
my team.

So my plan is to use some real results such as a forgery message with
a legal keyed hash code to convince them to abandon this design.
Moreover, I know from Wikipedia it's possible to attach bytes after
Message without knowing the key.

So my question is how to attach bytes to the message in practice?
Shall I use collision attack, extension length attack or to exploit
MD5 internal state? Please give me some hints about this
cryptanalysis. Thanks a lot:-)

This is not meant to be a patronizing feedback, a promotional sales
pitch for vector cryptography or indeed an attempt to teach grannie
how to crack eggs. It's to do with achieving theoretically unbreakable
cryptography at all costs on the premise that like me, the reader will
not settle for anything less. It comes after a lot of very hard work
over a long period.

Briefly:
Theoretically unbreakable cryptography is guaranteed outright by a one-
way function. A one-way function is the ultimate security device in
cryptography and in mathematics these are as rare as rocking horse
droppings. To say a natural occurrence of a one-way function simply
means one that becomes visible in everyday methodology. More
correctly to cryptographers, a one way function enables the entities
to create a one-way ‘trapdoor’ function as a development of a one-way
function. They decide on a ‘trapdoor’ which is simply information
that they alone are privy to.