Re: Dynamic salting in encryption algorithms for peer to peer communication
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Dynamic salting in encryption algorithms for peer to peer communication



Dear Atul,

I have the same thought regarding dynamic techniques, in this case the 
encryption.
If you use a well known mathemtical formula, I think passive attackers 
may still have a chance to challenge it.

What if the encryption algorithm is made dynamic?
It means that each peer can update and upgrade peer's algorithm 
whenever required.

Regards,
Benny

-- 
====================================================
Benny B. Nasution
Peninsula School of Information Technology
Information Technology Faculty
Monash University
A U S T R A L I A
+61 401 230 818
+61 397 696 078
email: benny.nasution at infotech.monash.edu
====================================================

----- Original Message -----
From: Atul Sabharwal <iamatul at comcast.net>
Date: Sunday, August 28, 2005 7:28 pm
Subject: Dynamic salting in encryption algorithms for peer to peer
	communication
> _______________________________________________
> Ietf mailing list
> Ietf at ietf.org
> https://www1.ietf.org/mailman/listinfo/ietf
> 
Title: Message
Generally, I have seen that people use PKI or static salts for encrypting data e.g. password.
In case of peer to peer communication, would it be useful to use dynamic salts derived from
known mathematical series e.g. Fibonacci series, Ramanajum number series.  The first
salt need not be item(1) of the list but a random item(N) out of a circular series of M items.
 
This could be useful for VPN client/server from same vendor.  Web site /Java Applet from
a company etc.
 
Is SSL still more secure than dynamic salting for man in the middle attack ?
 
--
Atul
_______________________________________________
Ietf mailing list
Ietf at ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.

Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.