aMule Forum
English => Feature requests => Topic started by: magic on September 16, 2004, 05:29:26 PM
-
do you think about implementing the webcache function?
More infos about webcache: http://ispcachingforemule.de.vu/
regards,
magic
-
as long as the legal issues aren't solved i don't think this would be a good idea... but that's just my personal opinion ;-)
-
I agree with jacobo221 too :)
Thepolish
-
You don't want your ISP to know WHAT you are sharing :) Don't you :) ?
-
I would rather like to see and end-to-end encryption of the
data (privacy). And after that store and forward with intermediate
hops...
-
@Jacobo221,
using the proxy of my ISP is nothing illegal. I don't understand what you meen with "legal issues".
@lfroen,
all data send through the proxy will be encryptet.
regards,
magic
-
Explaining "legal issues" : ISP's do not want to touch anything that involves file sharing (read piracy). Moreover, if asked by court, ISP will be obligated to take mesures to prevent such. And you suggest, that instead, ISP will provide it's own servers to store pirated data (encrypted or not ?!). This will not happen.
Regarding encryption: this is fairy tales. No *mule support cryptography. You must change protocol to make it work (authentication, key exchange, etc etc)
-
@lfroen: An extension to the protocol with fallback to plain text will do for the
begining. As Emule has the largest number of users the extension should be
supported by Emule as well. If most of the users are using the new version,
plain text could be switched off...
-
Implementing such a encription feature is not hard, I can do it in 1 hour (REALLY!). Problem is, that doesn't help much,because the other end of the encription must be a trusted source, and we don't know how if it is. It can be the RIAA downloading from you ;)
-
Well, the encryption should solve only one part: An ISP that is doing
more than you expect it to do and that you pay for (Task of the ISP is
not sniffing your communication - so make it impossible for them to
do it).
Other problems are solved by the ipfilter.dat. And for some things we
need to hide data transfer in other traffic, hide the sender by forwarding
packets, ... but this asks for a completely different protocol while encryption
is relatively easy to do.
IMHO encryption is more a political problem. As I already wrote, it would
be necessary that most people can use this feature. With the current
numbers (~90% of my peers are Emule) encryption is almost worthless
if Emule is not supporting this feature.
-
I'll talk to eMule devs about it, as an option of course.
I wonder what for. Encrypted:
a) Protocol
b) data
c) both
d) selectable
....
-
I think encrypting data is mandatory, but it's better to encrypt data
and protocol. Maybe define new (extended) packets for the encrypted
transfers. One packet containing other packets as payload will do.
To maintain compatibility with older clients, I think it would be necessary
to the start a plain text communication. When the peer can use encryption
the communication will switch to encryption.
-
Well, encrypted communication would work for me, I would be able to use aMule in my office. Nowadays we are not allowed to use any p2p program.
Cheers!
-
@phoenix: This will not work. If you look at your traffic you will learn that
the signature (number of connections/second, amount of data transfered,
source, destination, ...) is unique for most p2p applications. Even if
your use encryption it will be possible to detect an ed2k communication
by analyzing the traffic!
The only thing encryption can do is to hide the data from an attacker
sniffing your communication. IMO it's not even possible to prevent
a man-in-the-middle attack, because peer authentication is not possible.
But one thing the providers are currently discussing is scanning the
traffic for viruses, worms, copyrighted material, ... . In this area encryption
will help. In the next step they might think about the more sophisticated
attacks, and we might think about more sophisticated countermeasures ;-)
-
Well, I'll think about implmenting it... after 2.0
-
No hurry Kry. I think the most important thing for such a feature is
that other *mule (Emule) clients are implementing it as well. And if
the number of compatible clients is large enough at some point in
time, an 'accept only encrypted communication' makes sense 8-)
-
Hi there,
just to let you know http://www.emcrypt.com/ does provide encryted communication, but the question is still: who else uses eMCrypt?
Cheers,
Martin
-
Originally posted by sk8muc
Hi there,
just to let you know http://www.emcrypt.com/ does provide encryted communication, but the question is still: who else uses eMCrypt?
Cheers,
Martin
Plus, it's in German and apparently not free.
Next! :p
Edit: Ok, I'll have to elaborate. Apparently it is a eMule mod ... but the smucks at eMCrypt.com doesn't seem to care about the GPL, so no sources ... friggin bastards.
-
and btw if you read more carefully its a freaking "joke" the encryption does not really help a lot...and after a couple days you also get charged for using it...
so its basically a way to foul stupid people and get their money
stefanero
-
encryption doesn't help at all, if you don't have secure authentication and key exchange. You must be sure who are you talking to :)
-
Sure, encryption without authentcation is vulnerable to man-in-the-middle
attacks. But it will help against traffic probes!
About the authentication issue: Would it be possible to use secure ident
as authentication mechanism and generate the crypto key out of the
authentication process?
-
Hi,
Just remenber that encryption is NOT security: the level of security depend of the amount of data transfered. The more data u transfert, the easier it is to break the key.
Thats because wifi is not secure with WEP mechanism. Only about few GB to break 128bit wep key.
With amule, u will transfert a lot of data, so u will have to use mechanism to change the key very often, which will become very complicated if u have to associate a key with cache data...
U can easaly associate a key to a client connection, as u do on https, it will be more complicated, and more insecure to associate a key with cache...
So, to resume: crypt packets during a p2p connection between 2 clients ok, just use far more cpu to crypt and decrypt, and a mechanism to exchange keys at the beginning of the connection, based on secure ident auth (yes, riaa use secure ident too, thats the hole of the mechanism), but unadapted to web cache pb.
The polish
-
Originally posted by thepolish
Hi,
Just remenber that encryption is NOT security: the level of security depend of the amount of data transfered. The more data u transfert, the easier it is to break the key.
The polish
Where did you got this idea ? Good encryption scheme is not affected by this attack.
-
lfroen, that not a stupid idea :) thats the truth !
If u use the same key to crypt each pakets, u r vulnerable proportionaly to the amount of data used to break the code. Thats why security implies trashable keys. U cannot use static keys. Thats easy to do that with client, not for static cache.
The best example as i mentionned is WEP:
The flaws in WEP data encryption described earlier might have been ameliorated if static WEP has included a method to automatically update the encryption keys regularly. Tools for cracking static WEP need to collect between one and ten million packets encrypted with the same key. Because static WEP keys often remain unchanged for weeks or months it is usually easy for an attacker to collect this amount of data. As all computers on a WLAN share the same static key, data transmissions from all computers on the WLAN can be harvested to help discover the key.
Using a solution based on 802.1X allows the encryption keys to be changed frequently. As part of the 802.1X secure authentication process, EAP method generates an encryption key that is unique to each client. To prevent the WEP cracking attacks (described earlier), the RADIUS server regularly forces the generation of new encryption keys. This allows WEP encryption algorithms (found in most current WLAN hardware) to be used in a much more secure way.
complete src: http://www.microsoft.com/technet/security/guidance/peap_int.mspx
or here: http://www.wi-fiplanet.com/tutorials/article.php/2106281
The polish
-
hello,
if you implement webcache, please make it optional
-
thepolish: pls make us all a favor: before claiming something - check the f**cking literature. Read some books about encryption and math behind.
You will understand that:
* ) For some algorithm it's matter, how many data you process, for some dont.
* ) For even DES it doesn't matter ! It's length of the key that makes it weak
* ) If some algorithm is vulnerable to such attack - its due to its internal implementation
Anyway, this is not general property of encryption as such. Pls, put you "common sense" arguments away - this is complicated math issue which you clearly have no idea about.
-
Wow there, calm down lfroen. o_O
caspartroy
I doubt that it'll ever get implemented, so no need to worry. ;)
-
Hey, I mean no offense to anybody :)
-
I think webcache is a great idea, in my case my ISP forces me to use a transparent cache that I don't want... So, it can be the only way to take advantadge of it.
If someway the webcache is something dangerous for the ISP it will just remove it from my network... And everyone happy! If not... Lot of MB for the mule just paid for the ISP...
-
The ISP doesn't force you to use that proxy. It's on the contract, so if you don't like, just use another ISP (I know what I'm saying, I work at your ISP :
-
webcache would be realy cool, i hope it gets implemented!
-
99,9 % nope ;)
-
Add some more '9' to it.
-
http://forum.emule-project.net/index.php?showtopic=61326&st=0#
That's all I have to say.
-
ok
have you ever thought about webcache and your encryption idea ?(
1) User A establish a conection to user B.
2) They are generating a key for secure data transfer
3) User A encrypt the data chunk with the key
4) User A send the encrypted data to the proxy of the IPS from user B
4) The Proxy send is forward to user B
5) User B decryt th data and is funny
6) Data is storred on the proxy server
7) User C want to get them ... but the key?
Sorry for that now. I've realised after I finished my list, that user B can send user C the key for the proxy data. But I post it nevertheless. It can be that it possibly whom helps.
-
It still means using the proxy for what it wasnt meant to be (meaning abusing it and getting ready for legal charges), and a new way of atracting needless atention. Encryption or not.
-
Seagull got to read my mind :)
-
Closing thread, cause the answer will be "No" regardless of the number of times people ask ...