Silk Road forums
Discussion => Security => Topic started by: MollyMarley on October 25, 2012, 08:38 pm
-
For any of you who have not heard of Silent Circle, here is an enlightening article for you:
***CLEARNET***
http://www.buzzfeed.com/tommywilhelm/why-is-the-government-afraid-of-this-iphone-app
My Question: After reading the article, listed above, and reviewing the terms and conditions, below, does anyone have any reason to believe that this service would not be the best solution for dealers/buyers to communicate? All of the encryption appears to be done locally, on the user's device, therefore, once the information has left the sender's phone, it is already encrypted and only capable of decryption on the intended receiver's end. So, if LE requires Silent Circle to hand over any user information, it will all be encrypted and useless to them? Is my understanding correct? Any opinions from legal professionals would be great! :)
Silent Circle Terms and Conditions:
*******************************
Your Subscription.
Silent Circle, LLC ("Silent Circle”) has developed a suite of encrypted communications services, which are collectively known as known as Silent Circle. The services Silent Circle provides to you under this Agreement are: 1) Silent Eyes, encrypted VoIP teleconference service; 2) Silent Text, encrypted text messaging service; 3) Silent Mail, encrypted email service; and 4) Silent Phone, encrypted mobile video and voice service. For detailed information about the services, refer to https://www.silentcircle.com.
You have a limited, non-exclusive and non-transferable subscription with the right to download and use the Silent Circle suite of applications and to use Silent Circle’s encrypted communications services (the “Services”). The “Services” referred to in this Agreement may include the Plan (if you are purchasing a Plan), which is described below. You may use the Services as long as you have paid the applicable fees, which are for a 90-day, 6-month, 12-month or 36-month term. The fees are non-refundable, except as set forth later in this Agreement.
Secure Calling Plan Option.
When you purchase a Silent Circle secure calling plan (the “Plan”), you are receive unlimited cellular usage over the term that selected. The Plan is for personal use, and you agree not to use the Plan for commercial purposes. Please keep in mind that unlimited is not unreasonable use. To ensure that all Plan customers have access to reliable services provided at a reasonable cost, the Plan may not be used in a manner that interferes with another customer's use or disproportionately impacts Silent Circle’s network resources. Silent Circle’s wireless service is intended for personal use only. We have determined that placing a high number of calls or repeatedly placing calls of unusually long duration relative to typical usage by other customers on the Plan suggests that a mobile phone or device is being used other than for personal use in violation of this Agreement. So that you will understand what we look for, we have determined that in most cases, usage in excess of the lesser of 3000 minutes per month or 3 times typical usage by Plan customers (as determined by us) is likely to be the result of unauthorized use. If we determine at our sole discretion that you are using an unlimited service in violation of this Agreement or other or in any other manner that we deem to be unreasonable or excessive, then we may terminate individual calls or terminate your service under the Plan, decline to renew your Plan or offer you a different Plan with no unlimited usage component at any time. We will attempt to provide you with notice that we intend to take any of the above actions, but we cannot ensure that you will receive such notice, and we reserve the right to take any of the actions above even if you do not get notice.
Prices are subject to change. Silent Circle cannot be responsible for any problems with your device, and its only obligation in the event of network interruptions is a pro rata refund of the purchase price upon termination by you You can request a refund after the first 90-days of the purchase of your Plan by sending us written notice of cancellation, and you will be refunded the balance of the purchase price on a pro rata basis, based on the number of days remaining on your plan.
You consent to disclosure of any information about you (in most cases we will have little or no information) to any person as required by law if the device programmed with your number calls an emergency service number such as 911. This consent survives the termination of this Agreement or your use of the Plan services.
Voice services under the Plan are provided for live dialogue between two individuals and may not be used for monitoring services, data transmissions or other connections that do not consist of uninterrupted live dialogue between two individuals. Neither the Plan nor your Silent Circle phone number may be used for pager or voicemail retrieval service.
Service is normally available to your phone when it is within the operating range of our system, which is currently the United States, Canada and Puerto Rico. Service functionality may vary. Service is subject to transmission limitations, reduction in transmission speed, or interruption caused by weather, your equipment, terrain, obstructions such as trees or buildings, or other conditions. Service may be limited in some areas where coverage is not available or may be temporarily limited or interrupted due to system capacity limitations, system repairs or modifications, or in response to suspected fraud, abuse, misuse of the network, hacking or malicious viruses. Interruption may also result from violation of this Agreement. We may block access to certain categories of numbers (e.g. 976, 900 and certain international destinations) if, in our sole discretion, we are experiencing excessive billing, collection, fraud problems or other misuse of our network.
Support.
In addition to the Services, you have the right to receive customer support for the Services from Silent Circle through our website and customer support team. The Silent Circle website has all of the details you will need to access Silent Circle’s customer support.
Some Other Rights And Limitations.
The Services contain encryption technology that is or may be specifically controlled for export by the United States government. As a result, you may not export, or otherwise transfer the Services to or into Cuba, Iran, Iraq, North Korea, Sudan or Syria or a resident of those countries or to any person on the Specially Designated Nationals List (“SDN”) maintained by the United States Treasury or the Table of Denial Orders or Entity List maintained by the United States Department of Commerce. The SDN can be found at http://www.treasury.gov/resource-center/sanctions/SDN-List. The Denied Persons List can be found at www.bis.doc.gov/dpl.
You also may not, and you agree not to, knowingly export or transfer the Services to anyone outside of the United States without first obtaining a proper license and satisfying all requirements of International Traffic in Arms Regulations and the Export Administration Act. It is your responsibility to comply with foreign laws and regulations on encryption import, export or use.
When you subscribe to the Services and download the applications, you are certifying to Silent Circle that you are eligible to receive products exported from the United States, without any restrictions.
Any Silent Circle accounts which have not been used for six months or more may be suspended by Silent Circle. We will normally inform you before we suspend or terminate your access to the Services. An activation fee may be charged to reinstate your account.
You have no ownership rights to your Silent Circle phone number or other identifier provisioned by Silent Circle and you agree that we reserve the right to change your phone number or other identifier at any time without prior notice to you
What We Promise – Your Privacy.
We promise to do everything we can to protect the confidentiality of all your Silent Circle transmissions and your customer information. We have employed encryption technology for our services, and we run them on custom-designed and custom-built platforms that we own. We own the servers, the software and the data.
We promise that your communications to others within the Silent Circle (that is, member to member) cannot be decrypted by anyone other than those with whom you choose to communicate. Because we own our servers and have built our own platform, we also promise that there are no backdoors or other unauthorized means of access for anyone.
Your communications are fully encrypted and we do not hold the keys, therefore, we have nothing for anyone who might attempt to access your communications. However, if you decide to do bad things with your Silent Circle services (e.g., commit a crime), there is a chance that law enforcement officials may come to us with a subpoena, and we will meet our obligations as required by applicable law. So, if you don’t do bad things, we’ll both be happier. We will do everything legally permissible within our power to protect the privacy of your communications and information. We promise to provide complete transparency if we are ever required to turn over information to law enforcement authorities by, amongst other things, maintaining a list updated every six months of any law enforcement demands for information, the nature of the information provided and the number of users affected.
We also promise not to sell your information. We won’t use your information or communications for marketing purposes and we won’t provide it to anyone else for marketing. We won’t sell your personal information or anything about your use of our services. Silent Circle is in business to provide you with groundbreaking encrypted communication services focused on security, simplicity and service, not to monetize your information.
If you have any question, concerns or comments about the privacy of your communications and other information, or if you have thoughts about how we can do better, please send us an email at info@silentcircle.com.
Limited Warranty.
Silent Circle warrants that the Services will perform substantially as spelled out on our website and in any written materials provided by Silent Circle. Because we cannot foresee how you may be using our services or what might happen if there is a problem with the Services, Silent Circle’s only obligation under this limited warranty is to use its best reasonable efforts to solve any problems you may encounter with the Services. If the Services do not perform as you expected, you have the right to terminate this Agreement, as explained below, and you will then be refunded any remaining subscription amount, also as explained below. Your right to terminate and receive a refund is your only remedy should the Services not perform to your satisfaction or as described by Silent Circle.
Silent Circle’s Services may be dependent on your connection to a data or voice network and your Services may therefore cease to function, may experience latency or may not function properly if there is a power failure or other failure or delay in the underlying data or voice network.
SILENT CIRCLE MAKES NO OTHER WARRANTY, EXPRESS OR IMPLIED, WITH RESPECT TO THE SERVICES AND ALL OTHER WARRANTIES, EXPRESS OR IMPLIED, ARE DISCLAIMED, INCLUDING THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. YOU AGREE THAT SILENT CIRCLE’S LIABILITY TO YOU IN CONNECTION WITH THE SERVICES OR THIS AGREEMENT IS LIMITED TO THE AMOUNTS YOU ACTUALLY PAID TO SILENT CIRCLE UNDER THIS AGREEMENT. SILENT CIRCLE IS NOT LIABLE TO YOU FOR ANY OTHER DAMAGES OF ANY KIND, INCLUDING CONSEQUENTIAL, PUNITIVE, EXEMPLARY OR INDIRECT DAMAGES.
Terminating This Agreement.
You are pre-paying for either a 90-day or 12-month subscription period. If you have purchased a 12-month subscription, you can terminate this Agreement at any time after the first 90 days by providing us written notice of your intent to cancel. The effective date of your termination will be ten (10) days after we receive written notice of your termination of the Services. If you terminate your Services before the expiration of the subscription period you have paid for, Silent Circle will refund to you the pro rata portion of any prepaid subscription fees that relate to the period following the effective date of the termination. The termination provisions of this paragraph do not include Rōnin Card subscriptions, which are non-refundable. The sale of a Rōnin Card and the Services associated with the Rōnin Card is final and not subject to a refund or return for any reason. This helps to maintain the privacy of the purchasers and recipients of Rōnin Cards.
The Law Governing This Agreement.
Our customers are located all around the world, but we are a Delaware company, so to make things simple, this Agreement is governed by and enforced according to the laws of the State of Delaware notwithstanding any choice of law principles that might otherwise apply. If you are a resident of Canada, then you are expressly requesting and agree that this Agreement will be drawn up in the English language.
This Is Just Between You And Silent Circle, And This Is The Entire Agreement.
You can’t assign this Agreement without our prior written consent. This Agreement can only be modified by another written agreement that you and Silent Circle both sign. This Agreement is the entire agreement between you and Silent Circle, and there are no other written or implied agreements between us. If for some reason any part of this Agreement is deemed to be void or unenforceable, the rest of the Agreement will remain in effect.
Don’t Read Too Much Into The Headings
The headings used in this Agreement are an attempt at making things more clear (and sometimes an attempt at humor) so they can’t be used to construe meaning or intent in any of the rest of the Agreement.
How We Will Resolve Any Disputes We Might Have
You and Silent Circle agree that we will all use our best efforts to amicably resolve any dispute relating to this Agreement. Any dispute that we can’t resolve that way will be settled by final binding arbitration in accordance with the rules of JAMS, and judgment on the award rendered by the arbitrator or arbitrators may be entered in any court having jurisdiction. Any arbitration will be held in Delaware, or some other place that we all agree to. Within fifteen (15) days after the arbitration is started, each party will select one person to act as arbitrator, and the two arbitrators so selected shall select a third arbitrator within ten (10) days of their appointment. Each party will bear its own costs and expenses and an equal share of the arbitrators’ expenses and the administrative fees of arbitration.
If You Have Any Questions Or Need to Give Us Notice
If you have any questions about your Agreement with Silent Circle or these terms and conditions, please contact us by email at info@silentcircle.com or by telephone at +1.202.499.6427. Where written notice is required, you may email the notice to info@silentcircle.com or send it by regular mail to: Silent Circle, 174 Waterfront Street, Suite 310, National Harbor, MD, 20745 , attn: Customer Service.
**************************************
MM
-
Yes but if you go AND READ to the LAW AND COMPLIANCE page you eventually get to this part :
In providing this service, however, it’s also important to recognize that a small number of people will use our products and services to do unlawful, bad things. We obviously don’t want that--it hurts everyone, but we know it will happen. Various law enforcement agencies will therefore make demands, on a case by case basis, that we disclose existing subscriber data, and preserve data that we would not normally keep. Such legal demands are inevitable and come with the territory. We must and will comply with valid legal demands for the very limited information we hold. Thus, we want to make it clear that when legally compelled to do so, we will turn over the little information hold, described above. Before turning it over, however, we will evaluate the request to make sure it complies with the letter and spirit of the law. And, consistent with best privacy practices followed by other companies, when possible and legally permissible, we will notify the user in order to give him or her the opportunity to object to the disclosure.
We believe that the general public and policy makers benefit from transparency regarding the scale of law enforcement requests for subscriber data. We will therefore follow the lead of other privacy-minded companies in posting aggregate reports online that detail the number of requests we have received, from whom, and how many customers were affected. We will clearly post this information on our website every 6 months or sooner.
Not sure is really that safe....
-
Yes, but wouldn't the information that they have to release to LE already be encrypted and impossible to decrypt without the user-to-user key? If you read that first article on BuzzFeed, it says that Silent Circle can protect the Avon Barksdales (drugdealers) of the world just as well as anybody.
-
From what I've read until now, I don't like it.
Good privacy software shouldn't be controlled by a corporation. It should be open source freeware, released to the public without any back doors. Like GPG. Or TrueCrypt.
I don't trust smartphones when it comes to privacy. Not yet at least. For now, if you want to be anonymous and secure you should use a computer + Linux + Tor + PGP.
-
Yes they won't be able to read your communications... maybe,however when LE puts their foot through the door looking 4 u.... you should know what happens next...
I'll stick with Linux-Tor-PGP....thx
-
Just use a prepaid. This reeks of hushmail.
-
The premise they are claiming is sound in that they are using the same building blocks that open source tools use. However a closed source implementation reeks of poor auditing and potential back doors/weak keys/master keys.
Things like GPG and TOR are widely audited by the public at large, not by a small team of programmers that are being pushed to add features rather than harden the existing code.
Go open source, big business and big gov can't meddle in it.
I don't see how they justify $20 a month for something that does not even need a central server. Why are they using a central server anyways? Why can't phones talk directly? If they can't read the encrypted data then why even have it pass through them.
This coupled with their declared intention to cooperate with the government tells me that they can likely man in the middle your data if they wanted. After all it is their closed source software doing the encoding.
The part about "unsending" data is nonsense, this is likely implemented through security via obscurity. Meaning that the removal of data is not based on open mathematical techniques but rather application logic that enforces it. It is not as though malware could not take a screenshot or something.
-
All good points. It seems it would be best to just stay away and stick to my regular prepaid burner phone system. Not sure why somebody attacked my karma. I was just trying to notify the community about a potentially helpful resource...
-
Just use a prepaid. This reeks of hushmail.h,
Prepaid phones and encrypted phones serve two different purposes. Encrypted phones protect the content of intercepted communications by scrambling (encrypting) the voice communications so that they can only be decrypted with a secret key. Prepaid phones sort of protect from targeted communications interception because if the attacker doesn't know the phone to target they may not be able to intercept communications from/to it (of course they may just intercept all communications, but then the problem is finding a needle in a haystack). Encrypted phones don't inherently protect you from traffic analysis, if an attacker determines your phone number they can see who you call and who calls you but they cannot determine what you say. Frequently switching prepaid phones does protect some from traffic analysis as the attacker will need to find your new number to continue being able to determine who is calling you and who you are calling. You can probably meet both goals by using an encrypted phone with frequently switched anonymously obtained SIMs though.
Both of these systems for communications have flaws. Law enforcement agencies can identify when you switch your phone very quickly simply by monitoring the numbers that you are known to call and seeing when a new number calls these numbers. They can with high probability determine your new number in this way. The only way around this is for everyone you communicate with to frequently switch their numbers. Actually protecting from having your phone identified is quite hard to pull off if you try to accomplish it by switching the number frequently. Encrypted voice is certainly far better than nothing, but all kinds of fingerprinting attacks can gather information from encrypted voice streams. The CIA has been able to identify the language being spoken for some years now, even when the actual voice content is encrypted. There are also attacks that can pick out entire phrases and words through the encryption. This is because different languages / sentences create different interpacket timing characteristics that can be fingerprinted, and encryption doesn't hide the time delay between various packets of voice data. To protect from this sort of attack you will need to pad the voice data stream.
My suggestion is to stick with encrypted text messages if you must use a phone. Better yet, use a smartphone that can use pidgin OTR and stick to using pidgin via Tor for your communications. This will protect the content of your communications as strong encryption is used on the text, and it will protect you from traffic analysis as the data is routed through Tor. If you absolutely need encrypted voice (hint: you do not), I would look into whispersys.
-
Actually I believe that silentcircle actually does attempt to protect from traffic analysis in the form of routing all of the encrypted communications through their servers (making it appear to anyone monitoring you as if you are communicating with them instead of the party you are communicating with). If they are pressured by law enforcement this is the information that they will quickly give up, although if their software is proprietary nobody knows if they have backdoored the crypto software.
-
I was going to say that I'm not a fan of the burner phone concept, because even though you're kinda anonymous, the communication itself is in no way secure. But kmfkewm said it all. I've got nothing to add to that.
All good points. It seems it would be best to just stay away and stick to my regular prepaid burner phone system. Not sure why somebody attacked my karma. I was just trying to notify the community about a potentially helpful resource...
Don't worry about the karma, some people have an itchy trigger finger for dealing out negs. It doesn't mean much. The most important thing is that you keep asking good questions, because that way you learn stuff. But if it really bothers you, visit the "Karma heaven" thread in the off-topic section.
-
Just use a prepaid. This reeks of hushmail.h,
Encrypted voice is certainly far better than nothing, but all kinds of fingerprinting attacks can gather information from encrypted voice streams. The CIA has been able to identify the language being spoken for some years now, even when the actual voice content is encrypted. There are also attacks that can pick out entire phrases and words through the encryption. This is because different languages / sentences create different interpacket timing characteristics that can be fingerprinted, and encryption doesn't hide the time delay between various packets of voice data. To protect from this sort of attack you will need to pad the voice data stream.
I take it this is different from the attacks described on Phil Zimmermann's Zfone project homepage, where he advised people not to use variable compression codecs?
Q: What if I use a Variable Bit Rate (VBR) codec? Won't that leak information?
A: Johns Hopkins University researchers have observed that when voice is compressed with a variable bit-rate (VBR) codec, the packet lengths vary depending on the types of sounds being compressed. This leaks a lot of information about the content even if the packets are encrypted, regardless of what encryption protocol is used. We strongly recommend that you avoid using VBR codecs if you want to make a secure phone call. Most codecs are not VBR, so it's not hard to avoid using VBR. If you plan to use Zfone with a VoIP client, open the preference panel in the VoIP client and disable the VBR codecs from the menu.
Some codecs have a VBR mode and a non-VBR mode, so you should disable the VBR mode. If you are the implementor of a VoIP client, you can disable the VBR feature while still allowing the codec to be used. But if you are the end user, most VoIP clients do not have preference panels that allow such fine granularity of control, so you will be lucky to be able to just disable the whole codec. Some VoIP clients don't allow the user any choice at all about what codecs are used.
Some safe non-VBR codecs include GSM 6.10, iLBC, G.711 (A-LAW, u-LAW, and PCMU), G.722, and G.726. It's not a problem if the codec adapts the bit rate to the available channel bandwidth. The dangerous codecs are the ones that change their bit rate depending on the type of sound being compressed.
Skype's VBR codec leaks information regardless of the quality of the encryption, which may allow phrases to be identified with an accuracy of 50-90%.
Let me be clear about this leakage of information-- it doesn't leak any cryptographic key material, and it doesn't help the attacker actually break the crypto. The VBR codec is leaking information about the content of the voice packets, because some sounds compress more than other sounds. By looking at how much each packet of sound was compressed, which can be inferred by the packet size, it is possible to infer something about what kind of sound it is, like a vowel, or a sharp consonant. This undermines the usefulness of the encryption. Some phrases can be identified with an accuracy of 50% to 90%. This is a serious vulnerability.
Fortunately, not too many codecs use VBR. Speex has a VBR-capable codec, and some VoIP applications that use Speex allow the user to choose which codecs to enable. iSAC is a commercially licensed VBR codec, used by Skype, Google Talk, and Gizmo. This means that Skype is vulnerable to VBR leakage regardless of the quality of Skype's built-in crypto. Sadly, this also means Gizmo and Google Talk are not the safest VoIP clients to use with Zfone. And it appears the user cannot disable the use of this codec in those products. Microsoft's RT Audio also appears to be a VBR codec, and is used in Microsoft Office Communicator.
It also appears that voice activity detection (VAD) leaks information about the content of the conversation, but to a far lesser extent than VBR. This effect can be mitigated by lengthening the VAD "hangover time" by about 1 to 2 seconds. That would sharply reduce the information leakage, but it may be something that only the VoIP application developer can do, if the VAD parameters are tunable. For an end user, a simpler solution would be to avoid the use of VAD, if this is feasible in your situation. Examples of codecs that use VAD include AMR and G.722.2. If it's not convenient to avoid all VAD codecs, keep in mind that the leakage from VAD is much less than the leakage from VBR.
Some researchers have suggested that the VAD hangover time should be lengthened by a random amount. For example, a random normal distribution over the range of 1 to 2 seconds. Most codecs that use VAD only allow a fixed amount of VAD hangover to be easily configured. It remains unclear whether a random hangover time is worth the extra effort. This requires further research.
Source: http://www.zfoneproject.org/faq.html
-
silent circle was questioned about its obligation to CALEA and they dodged the question. If its possible to put a backdoor in it, they are required by law to. Theres no reason why this couldnt be made opensource and decentralized except that zimmerman has become a greedy dick.
burner phones are cool if you want to stay anon, just accept the fact that everything u say can be logged and ur basically carrying a gps locator with you if the cops ever bust one of your contacts and start trying to find you.
I like the pidgin/OTR via tor route, everything is crypto and at arms reach, so if ur friend gets busted they cant find you, just so long as he doesnt have ur number.
-
found this
https://ostel.me/
This service is a public testbed of the Open Secure Telephony Network (OSTN) project, with the goal of promoting the use of free, open protocols, standards and software, to power end-to-end secure voice communications on mobile devices, as well as with desktop computers.
This service is in public beta. Calls placed throug the system are encrypted and authenticated between peers. It is continually being tested and improved to ensure the best possible security. Logging is minimal and work is being done to ensure no unecessary IP addresses are stored on disk. We encourage you to build your own OSTN server with our cookbook.
-
Just use a prepaid. This reeks of hushmail.h,
Encrypted voice is certainly far better than nothing, but all kinds of fingerprinting attacks can gather information from encrypted voice streams. The CIA has been able to identify the language being spoken for some years now, even when the actual voice content is encrypted. There are also attacks that can pick out entire phrases and words through the encryption. This is because different languages / sentences create different interpacket timing characteristics that can be fingerprinted, and encryption doesn't hide the time delay between various packets of voice data. To protect from this sort of attack you will need to pad the voice data stream.
I take it this is different from the attacks described on Phil Zimmermann's Zfone project homepage, where he advised people not to use variable compression codecs?
Q: What if I use a Variable Bit Rate (VBR) codec? Won't that leak information?
A: Johns Hopkins University researchers have observed that when voice is compressed with a variable bit-rate (VBR) codec, the packet lengths vary depending on the types of sounds being compressed. This leaks a lot of information about the content even if the packets are encrypted, regardless of what encryption protocol is used. We strongly recommend that you avoid using VBR codecs if you want to make a secure phone call. Most codecs are not VBR, so it's not hard to avoid using VBR. If you plan to use Zfone with a VoIP client, open the preference panel in the VoIP client and disable the VBR codecs from the menu.
Some codecs have a VBR mode and a non-VBR mode, so you should disable the VBR mode. If you are the implementor of a VoIP client, you can disable the VBR feature while still allowing the codec to be used. But if you are the end user, most VoIP clients do not have preference panels that allow such fine granularity of control, so you will be lucky to be able to just disable the whole codec. Some VoIP clients don't allow the user any choice at all about what codecs are used.
Some safe non-VBR codecs include GSM 6.10, iLBC, G.711 (A-LAW, u-LAW, and PCMU), G.722, and G.726. It's not a problem if the codec adapts the bit rate to the available channel bandwidth. The dangerous codecs are the ones that change their bit rate depending on the type of sound being compressed.
Skype's VBR codec leaks information regardless of the quality of the encryption, which may allow phrases to be identified with an accuracy of 50-90%.
Let me be clear about this leakage of information-- it doesn't leak any cryptographic key material, and it doesn't help the attacker actually break the crypto. The VBR codec is leaking information about the content of the voice packets, because some sounds compress more than other sounds. By looking at how much each packet of sound was compressed, which can be inferred by the packet size, it is possible to infer something about what kind of sound it is, like a vowel, or a sharp consonant. This undermines the usefulness of the encryption. Some phrases can be identified with an accuracy of 50% to 90%. This is a serious vulnerability.
Fortunately, not too many codecs use VBR. Speex has a VBR-capable codec, and some VoIP applications that use Speex allow the user to choose which codecs to enable. iSAC is a commercially licensed VBR codec, used by Skype, Google Talk, and Gizmo. This means that Skype is vulnerable to VBR leakage regardless of the quality of Skype's built-in crypto. Sadly, this also means Gizmo and Google Talk are not the safest VoIP clients to use with Zfone. And it appears the user cannot disable the use of this codec in those products. Microsoft's RT Audio also appears to be a VBR codec, and is used in Microsoft Office Communicator.
It also appears that voice activity detection (VAD) leaks information about the content of the conversation, but to a far lesser extent than VBR. This effect can be mitigated by lengthening the VAD "hangover time" by about 1 to 2 seconds. That would sharply reduce the information leakage, but it may be something that only the VoIP application developer can do, if the VAD parameters are tunable. For an end user, a simpler solution would be to avoid the use of VAD, if this is feasible in your situation. Examples of codecs that use VAD include AMR and G.722.2. If it's not convenient to avoid all VAD codecs, keep in mind that the leakage from VAD is much less than the leakage from VBR.
Some researchers have suggested that the VAD hangover time should be lengthened by a random amount. For example, a random normal distribution over the range of 1 to 2 seconds. Most codecs that use VAD only allow a fixed amount of VAD hangover to be easily configured. It remains unclear whether a random hangover time is worth the extra effort. This requires further research.
Source: http://www.zfoneproject.org/faq.html
encrypted VoIP traffic: Alejandra y Roberto or Alice and Bob is the paper I was originally thinking of , and indeed I remembered incorrectly by thinking that they were focusing on information leaked through interpacket timing characteristics rather than variable packet sizes. However, interpacket timing characteristics can actually leak information as well, I did a little searching and found this research paper for example: etd.ohiolink.edu/send-pdf.cgi/Lu%20Yuanchao.pdf?csu1260222271 which shows how interpacket timing characteristics can be analyzed with traffic classifiers in an attempt to identify the speakers of an encrypted voice chat (provided the attacker has encrypted VOIP samples from a pool of potential suspects and wants to later be able to link encrypted VOIP streams to them). They also claim to be able to identify encrypted speech from the target so long as they have a sample reference of encrypted speech + plaintext to compare it to (note that the same speech encrypted twice would produce different ciphertexts if any sane cryptosystem is being used, so the data is leaking via interpacket timing).
It is VERY likely that more information than just the speaker + previously sampled ciphertext:plaintext phrases will leak via interpacket timing characteristics. I have done a (very) little google-fu looking for research papers to back this but so far this is all I have been able to find. However, we can extrapolate from the research done on encrypted website fingerprinting that both variable packet size AND interpacket timing characteristics will leak information about the encrypted payload, and the most successful classifiers will likely take both data points into consideration. I would be surprised if the language spoken and possibly even non-sampled phrases cannot be identified with interpacket timing fingerprinting alone.
-
some excerpts (I have only skimmed through the full paper)
In this thesis, we propose a class of passive traffic analysis attacks to com-
promise privacy of Skype calls and SIP-Based VoIP calls. The proposed attacks
are based on application-level features extracted from VoIP call traces. The proposed
attacks are evaluated by extensive experiments over different types of networks includ-
ing commercialized anonymity networks and our campus network. The experiments
show that the proposed traffic analysis attacks can detect speeches and speakers of
SIP based VoIP calls with 0.65 and 0.32 detection rate respectively, about 70-fold and
35-fold improvement over random guess. For Skype calls, the speech detection rate
and speaker detection rate are 0.33 and 0.44, about 30-fold and 15-fold improvement
over random guess. Countermeasures are proposed to mitigate the proposed traffic
analysis attacks by camouflaging. The proposed countermeasures can largely mitigate
the traffic analysis attacks and does not cause significant degradation on quality of
VoIP calls.
The proposed traffic analysis attacks exploit silence suppression. Different
people have different talk patterns in terms of talk spurts and silence gaps. For
example, some persons speak very fast with only a couple of short silence gaps while
some speak with long silence gaps. As shown in Figure 1, an eavesdropper can learn
a speaker’s talk pattern from packet timing. Based on talk patterns learned from
packet timing, the proposed traffic analysis attacks can detect speeches or speakers
of encrypted VoIP calls with high accuracy.
The typical attack scenario focused in this chapter is as follows: An adversary
may want to detect whether the target speaker, say Alice, is communicating with
Bob now or not based on the previous encrypted VoIP calls made by Alice. The
previous calls may use different codecs than the one Alice using now. The adversary
may collect VoIP packets at any point on the path from Alice to Bob and may also
want to detect the content of the conversation, such as a partial speech in previous
calls.
Comparing with previous researches, the proposed attacks do not require si-
multaneous access to both sides of the links connected to Alice and Bob. Traces
of calls used in detection can be collected at different time and in different network
environment and these calls possibly made with different codecs.
In this chapter, we also assume Alice uses mass-market VoIP services to com-
municate with Bob as shown in Figure 2. In other words, we assume SIP and RTP
are used as the signaling protocol and the transport protocol respectively. To protect
confidentiality of her VoIP calls, we assume Alice encrypts her VoIP packets by using
secure versions of the RTP protocol such as SRTP [2] and ZRTP used in Zphone [1].
To better protect privacy of her calls, we assume Alice routes these encrypted
VoIP calls through anonymity networks as shown in Figure 2. For better voice quality,
Alice can use low-latency anonymity networks such as Tor [3] and JAP [4].
We focus on passive attacks in this thesis. In other words, the attacks launched
by the adversary will not disturb existing network traffic. In comparison with active
attacks, the proposed attacks are harder to detect. We assume that the adversary
11
only has access to the links directly connected to participants of VoIP calls. This
assumption is widely used in traffic analysis attacks such as attacks on anonymity
networks and tracing VoIP calls [5, 8, 29, 30]. We do not assume the adversary as a
global attacker because rerouting techniques used in anonymity networks make global
attacks too costly to be practical. The threat model is weaker than threaten models
defined for traditional privacy-related traffic analysis attacks: The threat model does
not require simultaneous access to the links connected to participants of a VoIP
call which may not be feasible for international VoIP calls. Instead we assume the
adversary can collect traces of VoIP calls made by Alice in advance and use these
collected traces to detect whether Alice is a participant in the VoIP conversation
of interest. Our model is similar as the model for identifying a human being by
fingerprints: Fingerprints of human beings are collected in advance through driver
license applications. To identify a specific person, the fingerprint of interest such
as a fingerprint in a crime scene will be compared against the person’s fingerprints
collected in advance.
The threat model assumes the detections are based on different VoIP calls. So
the speaker identification should also be independent of the voice content of VoIP
calls.
The proposed traffic analysis attacks are based on packet timing information.
As described in Section 3.1.2, silence suppression enables adversaries to recover talk
patterns in terms of talk spurts and silence gaps from packet timing. Adversaries can
create a Hidden Markov Model (HMM) to model Alice’s talk pattern recovered from
SIP-Based encrypted VoIP calls made by her. When adversaries want to determine
which SIP-Based encrypted VoIP call is made by Alice, adversaries can check talk
patterns recovered from the call of interest against Alice’s model.
The proposed attacks can be divided into two phases: the training phase and
the detection phase as shown in Figure 3. The two steps in the training phase are
feature extraction and HMMs training. The detection phase consists of three steps:
feature extraction, speech detection or speaker detection, and intersection attack.
The last step, intersection attack, is optional. We describe the details of each step
below.
The input and output of the feature extraction step are raw traces of VoIP calls
and feature vectors respectively. The feature vector used in the proposed attacks is
where n is the length of a feature vector, tsi and sgj denote the length of the ith talk
spurt and the jth silence gap respectively.
Talk spurts and silence gaps are differentiated by a silence threshold Tsilence : If
an inter-packet time is larger than the threshold, the inter-packet time is declared as
a silence gap. Otherwise the inter-packet time is declared as a part of one talk spurt.
Obviously the threshold Tsilence is critical to overall detection performance. We
did initial experiments to investigate the suitable range of the threshold for detection:
We feed voice signals to VoIP clients and collect VoIP packets generated by VoIP
clients. Different values of the threshold Tsilence are used to determine silence gaps.
Actual silence gaps can be found by checking marker bits in RTP packets which
indicate the start of talk spurts2 . We evaluate a value of the threshold by two metrics:
false positive rate and false negative rate. False positive rate is the fraction of talk
spurts that were erroneously declared as silence gaps. False negative rate is the
fraction of silences gaps that are erroneously declared as talk spurts. The experiment
results with different codecs3 are shown in Figure 4.
We can observe that for a wide range of the threshold Tsilence , both the false
positive rate and the false negative rate are low: When Tsilence is larger than 70ms,
the false positive rate is below 10% for all the codecs. The false negative rate is below
20% when Tsilence is less than 100ms. The wide range is because of the big difference
between inter-packet time of silence gaps and inter-packet time of talk spurts: Silence
gaps are in order of seconds. Inter-packet time during talk spurts is usually around
packetization delay of 20ms or 30ms for most codecs.
We can also observe that increasing the threshold Tsilence decreases the false
positive rate and increases the false negative rate. The changes in these two rates
are again because the inter-packet time during silence gaps is larger than inter-packet
time during talk spurts.
A big challenge in feature extraction is to filter out noise caused by random net-
work delays in silence tests. Random network delays can cause errors in silence tests
especially at receiving side: Because of random packet delays, inter-packet time dur-
ing talk spurts can become larger than the threshold Tsilence . The main idea of filtering
noise in silence tests is to determine a silence gap based on N successive inter-packet
intervals instead of one inter-packet interval. The silence test with filtering techniques
works as follows: If one inter-packet interval is larger than the threshold Tsilence , we
declare a new silence gap only when none of the following ⌊
Tsilence
packetization delay
⌋ − 14
inter-packet intervals are shorter than a threshold Tspurt, used to filter out long inter-
packet intervals caused by network delays. The rationale behind the new silence tests
method is that: If an inter-packet interval is erroneously declared as a silence gap
because network delays increase the length of the inter-packet interval, then following
inter-packet intervals must likely be shorter than normal inter-packet intervals during
talk spurts. The new silence tests can improve silence detection performance in terms
of the false positive rate. The filtering does not focus on false negative errors because:
(a) The false negative rate changes very little when Tsilence changes. (b) We take into
account false negative errors in choices of HMM structures.
Our experiments clearly show that the proposed traffic analysis attacks can
greatly compromise privacy of VoIP calls. The detection rates for speech detection
and speaker detection are 70-fold and 35-fold improvement over random guess. Higher
detection rate can be achieved with more training traces.
Comparable detection performances are achieved for both traces collected by
sending side and receiving side. It is an indication that when the threshold is large
enough, feature extracted in the proposed attacks are largely independent of network
dynamics.
The framework proposed in this chapter, including extracting application-level
features from network traffic traces and statistical analysis of extracted application-
level feature by HMMs, can be potentially used to infer other sensitive information
at application level. For example, the framework can be potentially used to detect
speaker’s emotion during a call suppose the speaker’s talk behavior can change signif-
icantly when the speaker’s mood changes. The framework may also be used to detect
different types of speeches such as seminar talk, conversation between two parties,
and classroom discussion. One of our future works is to explore the potential of the
framework experimentally and theoretically.
-
Encrypted voip works by encrypting each UDP packet on its own. I have sniffed such traffic and was able to graph the data volume over time. I then used that data volume to synth a sound based on the volume over time.
The result was a bit like listening to Charlie Brown's parents, "wa wa waaa wa wawawawa".
I could not make out words but I could hear the pauses between the words and sentences. I could tell one side talked faster and the other slower. Granted this was about 4 years ago, perhaps they have something better now.
This can be avoided by sending dummy traffic to create a consistent volume, this however dramatically increases the required bandwidth.
Encrypting a real time protocol has special challenges.
-
For better voice quality,
Alice can use low-latency anonymity networks such as Tor [3] and JAP [4].
Something tells me these researchers dont know what they're talking about.
-
From what I've read until now, I don't like it.
Good privacy software shouldn't be controlled by a corporation. It should be open source freeware, released to the public without any back doors. Like GPG. Or TrueCrypt.
I don't trust smartphones when it comes to privacy. Not yet at least. For now, if you want to be anonymous and secure you should use a computer + Linux + Tor + PGP.
Agreed. Plus if you have a smartphone, why not just use GPG encrypted e-mail to communicate? Or is it so important that you hear someone's voice?
-
Agreed. Plus if you have a smartphone, why not just use GPG encrypted e-mail to communicate? Or is it so important that you hear someone's voice?
cause 90% of people dont understand public key crypto and couldnt even if you showed them a diagram. and theres only one or two email clients that support gpg without having to go through a bunch of bullshit hoops.
-
For better voice quality,
Alice can use low-latency anonymity networks such as Tor [3] and JAP [4].
Something tells me these researchers dont know what they're talking about.
You could use Tor or JAP to route encrypted voice streams, although Tor is not able to route UDP. They are not claiming that using a low latency anonymity network improves voice quality over not using an anonymizer at all, simply that when it comes to anonymity networks routing VOIP anything other than a low latency network will totally destroy the voice quality (to the point of being impossible to use, I imagine). A lot of encrypted voice services provide their own 'anonymity networks' in the form of what are essentially high bandwidth VPNs , these solutions will give less of a hit to voice quality than networks such as Tor or even JAP, but they are also more limited in the amount of anonymity they can provide. There has actually been a fairly substantial amount of research done on anonymizing and deanonymizing VOIP streams, although to be fair none of it seems particularly unique to VOIP (judging from the little I have read regarding this particular aspect of anonymity).
Encrypted voip works by encrypting each UDP packet on its own. I have sniffed such traffic and was able to graph the data volume over time. I then used that data volume to synth a sound based on the volume over time.
The result was a bit like listening to Charlie Brown's parents, "wa wa waaa wa wawawawa".
I could not make out words but I could hear the pauses between the words and sentences. I could tell one side talked faster and the other slower. Granted this was about 4 years ago, perhaps they have something better now.
This can be avoided by sending dummy traffic to create a consistent volume, this however dramatically increases the required bandwidth.
Encrypting a real time protocol has special challenges.
If you had a trained classifier and used it to analyze the pauses (which can be determined via interpacket timing) you would quite possibly be able to determine the language being spoken and possibly even be able to pick out certain phrases or words. The paper I previously linked to shows that analysis of these pauses is enough to identify a previously fingerprinted speaker with high probability, and even to pick out previously fingerprinted words and phrases of a given speaker. I would hypothesize that even if there is not a previously created fingerprint of a particular individuals encrypted VOIP speech, that a classifier could be used to gain information about encrypted VOIP streams via interpacket timing characteristics. I believe that the speed of speech in itself would be useful for determining or at least narrowing in on the language being spoken. Different languages are spoken with varying average speeds and thus being able to determine the rate of speech should by itself help in identifying the spoken language with better than random chance probability.
Of course before you will be able to learn anything from the pauses you will need to have a substantial database of speech samplings in various languages. You would then see the average interpacket timing for each of the languages, and then after obtaining a sample of an encrypted VOIP stream you would use the classifier to see which of the previously fingerprinted languages the sample most closely matches. I highly suspect that this technique will have better than random chance probability of correctly identifying the spoken language.
-
For better voice quality,
Alice can use low-latency anonymity networks such as Tor [3] and JAP [4].
Something tells me these researchers dont know what they're talking about.
VOIP over TCP(the only protocol tor supports) is problematic because TCP will keep retrying old packets and delaying new ones. In a voice conversation if a bit of info was lost then it is better to just play what is coming next and forgetting about it, that is why UDP is used.
Real time protocols don't really play well with anonymizing networks. Far better to just use chat.
At this moment I am working on a chat client/server that opens a tor hidden service to facilitate secure communication.
-
For better voice quality,
Alice can use low-latency anonymity networks such as Tor [3] and JAP [4].
Something tells me these researchers dont know what they're talking about.
VOIP over TCP(the only protocol tor supports) is problematic because TCP will keep retrying old packets and delaying new ones. In a voice conversation if a bit of info was lost then it is better to just play what is coming next and forgetting about it, that is why UDP is used.
Real time protocols don't really play well with anonymizing networks. Far better to just use chat.
At this moment I am working on a chat client/server that opens a tor hidden service to facilitate secure communication.
Sounds like Tor Chat (or libertes cables system). This is a flawed design, hidden services have much less anonymity than regular Tor clients and having chat protocols where two parties both run as hidden services decreases the anonymity of both of them. It would be better for anonymity if they communicated through a hidden service as regular Tor clients.
-
You all are talking about tor right? the network that takes 30 secodns to load a page? sounds like a perfect network for realtime communication.
-
VOIP over TCP(the only protocol tor supports) is problematic because TCP will keep retrying old packets and delaying new ones. In a voice conversation if a bit of info was lost then it is better to just play what is coming next and forgetting about it, that is why UDP is used.
Real time protocols don't really play well with anonymizing networks. Far better to just use chat.
At this moment I am working on a chat client/server that opens a tor hidden service to facilitate secure communication.
Sounds like Tor Chat (or libertes cables system). This is a flawed design, hidden services have much less anonymity than regular Tor clients and having chat protocols where two parties both run as hidden services decreases the anonymity of both of them. It would be better for anonymity if they communicated through a hidden service as regular Tor clients.
How exactly are tor services less anonymous than tor clients? I would love to know about that, can you point me to an article on the subject?
The design I am working on only requires one of the parties to run a hidden service, the other connects as a tor client. Hidden service to client communication involves two tor circuits connecting to the same node and engaging in end to end communication.
No single node or party to this connection is privy to the location of both parties, and only the parties themselves are privy to the information. It is not like using an exit node where someone can sniff you.
The only vulnerability in hidden services I am aware of is that a hostile node has a chance of discovering your .onion address and potentially impersonating your client. However tor support a trusted client model where a hidden service can only be connected to by someone who has entered the correct client key into their own tor daemon.
This is after all the exact same security model that silk road itself is using. If hidden services are vulnerable then it behooves you to warn us of its exact nature. Please, I really need to know this, my freedom depends on it.
I have done a lot of research on tor and am very surprised by your statements. Please enlighten me as to what crucial information I am missing.
-
VOIP over TCP(the only protocol tor supports) is problematic because TCP will keep retrying old packets and delaying new ones. In a voice conversation if a bit of info was lost then it is better to just play what is coming next and forgetting about it, that is why UDP is used.
Real time protocols don't really play well with anonymizing networks. Far better to just use chat.
At this moment I am working on a chat client/server that opens a tor hidden service to facilitate secure communication.
Sounds like Tor Chat (or libertes cables system). This is a flawed design, hidden services have much less anonymity than regular Tor clients and having chat protocols where two parties both run as hidden services decreases the anonymity of both of them. It would be better for anonymity if they communicated through a hidden service as regular Tor clients.
How exactly are tor services less anonymous than tor clients? I would love to know about that, can you point me to an article on the subject?
The design I am working on only requires one of the parties to run a hidden service, the other connects as a tor client. Hidden service to client communication involves two tor circuits connecting to the same node and engaging in end to end communication.
No single node or party to this connection is privy to the location of both parties, and only the parties themselves are privy to the information. It is not like using an exit node where someone can sniff you.
The only vulnerability in hidden services I am aware of is that a hostile node has a chance of discovering your .onion address and potentially impersonating your client. However tor support a trusted client model where a hidden service can only be connected to by someone who has entered the correct client key into their own tor daemon.
This is after all the exact same security model that silk road itself is using. If hidden services are vulnerable then it behooves you to warn us of its exact nature. Please, I really need to know this, my freedom depends on it.
I have done a lot of research on tor and am very surprised by your statements. Please enlighten me as to what crucial information I am missing.
http://freehaven.net/anonbib/cache/hs-attack06.pdf
The bottom line is: Hidden services create new circuits every single time a client asks them to. If the client is malicious, this could be ten times in one minute. Clients use roughly one circuit every ten minutes. Essentially this hidden service design allows an attacker to 'artificially' speed up the rate at which a hidden service instance of Tor will use one of their malicious Tor relays to relay traffic for their malicious client. Conversely, a hidden service cannot so easily force a client to open circuit after circuit nonstop. This makes hidden services much easier to trace to their entry guards, and once you have identified the entry guards you are only one hop from the target.
-
warning: rambling alert
The honest truth of the matter is that low latency anonymity networks are just not very good at providing anonymity, and they are even worse at providing anonymity for hidden services. Here is one thing worth mentioning that not many people realize: when accessing a hidden service it is theoretically possible for a single malicious node to deanonymize you. When accessing the clearnet, it is not possible for a single Tor node to deanonymize you. Allow me to elaborate:
this is what the path from the hidden services perspective looks like:
Hidden Service <-> HS Entry <-> HS Middle <-> HS Final
This is what the path from the clients perspective looks like:
Client <-> Client Entry <-> Client Middle <-> Client Final (rendezvous)
giving us this:
Client <-> Client Entry <-> Client Middle <-> Client Final (rendezvous) <-> HS Final <-> HS Middle <-> HS Entry <-> Hidden Service
HS entry is capable of determining if it is an entry node for the hidden service simply by sending the hidden services a specifically modulated stream through Tor and looking to see if it relays a stream with this modulation after sending it. Additionally, there is nothing preventing HS Entry and Client Entry from being the same exact node. If they are, then the node operator can link the client and hidden service with an end to end timing attack. When a client accesses the clearnet this is not possible
Client <-> Client Entry <-> Client Middle <-> Client Exit <-> Website
as the client selects the entire path it will avoid using the same node for entry and exit. Additionally, it will entirely avoid using nodes from the same family. Thus, clients connecting to hidden services can theoretically be deanonymized by an active attacker with a single node, but clients accessing the clearnet cannot be deanonymized by an active attacker with less than two nodes (traffic fingerprinting attacks aside).
This is not to say that clients are better off accessing clearnet websites though. Accessing hidden services gives a big advantage in that it makes it more difficult for an arbitrary attacker to position themselves so that they can eavesdrop on traffic to the hidden service. This probably makes doing end to end timing attacks more difficult in the end, even though it does open up the possibility of a single node carrying out an end point timing attack the probability of this being possible to carry out against a large number of clients is small (although it is very likely that some of the clients connecting to such a popular site as SR, are indeed using at least one of the same entry guards as SR is, making them vulnerable to the single node attack I mentioned)
I feel like I have strayed from the point I originally set out to make, but only to illustrate a point about hidden service connections that I think many people do not realize (that they are weak to single active node attacks, unlike connections to the regular internet). Back to the point though, using low latency anonymity techniques only can afford so much anonymity. The goal of an anonymity network is to prevent an attacker who can see Alice from determining who Alice communicates with. Likewise, the anonymity network attempts to prevent an attacker who can communicate with Bob from determining who Bob actually is. There are a variety of techniques used to accomplish this goal. Networks like Tor rely on an attacker having only being able to view a small portion of traffic on the network. They protect anonymity entirely by preventing an attacker from watching the traffic leaving from Alice AND the traffic arriving to the person Alice is communicating with, or the traffic arriving at Bob if they are the people communicating with Bob. Tor attempts to do this by having a very large geographically diverse network of volunteer operated nodes.
Once the attacker can see the traffic at both ends of a connection, the communicating parties are deanonymized. Unfortunately for Tor and similar networks, tracing communicating parties to their entry guards has proven to be a somewhat trivial task, particularly (although not exclusively) in the case of hidden services. Once a target is traced to its entry guards, deanonymizing it is simply a matter of obtaining logs from the entry guard (either actively or passively) . The situation is equally grim in the case of Alice who uses Tor to visit a website, with the trace starting at Alice rather than the website (in some situations the trace starts at one end, in other situations it starts at the other). If Alice visits honeypot.com which is run by the FBI, they will immediately be able to deanonymize her if they are already monitoring the traffic from her (traffic confirmation). Tor prevents traffic analysis, it does not and cannot prevent traffic confirmation. Even if Alice is visiting notahoneypot.com and the FBI gets logs from it, they can immediately determine that Alice is visiting notahoneypot.com if they are already monitoring her traffic. Tor is really meant for the specific situation in which the feds gather logs from (nota)honeypot.com and they have not yet been able to determine that Alice is someone they are interested in (traffic analysis). Unfortunately even when it comes to traffic analysis Tor leaves a lot to be desired, as mentioned earlier the feds could very well just run several entry nodes and wait until a client that visits (nota)honeypot.com uses them.
I don't mean to sound like I am fear mongering, really I do like Tor and I recognize that it provides a lot of anonymity working in the low latency framework that it does. I just also recognize that it is somewhat of a toy compared to high latency anonymity solutions. In a high latency mix network, an attacker can watch Alice send traffic and they can watch that traffic arrive at its destination. Still they are incapable of linking the traffic. In fact in some high latency designs the attacker is capable of watching Alice send a message, passively AND largely (but only partially) actively watching Alice's message on its path all the way to it arriving at her correspondents IP address, and still they cannot link Alice to her correspondent. In some high latency systems, the attacker can send a message to Bob, follow the message all the way to the point that it is delivered to Bob's IP address, and still they cannot determine that Bob's IP address is linked to Bob the pseudonym they communicate with. Comparing high and low latency networks is somewhat apples and oranges, but the difference in the anonymity guarantees between them is extremely massive. I do not believe that low latency networks, including Tor, will continue to hold up to focused attacks. I do believe that a lot of the success of these networks is due to a lack of technical competence on the part of those who wish to attack them. I believe that Tor will continue to provide some degree of anonymity, particularly to people who use it for a very brief period of time before discontinuing its use. It will also continue to provide anonymity to people who desire anonymity but who do not have significant attackers (ie: abusive boy friends, not federal police). But I also strongly believe that it is not the appropriate tool to be using for things upon which your freedom depends. I do believe that currently it will work for these purposes, but I do not think it is the strength of Tor protecting you but rather the weakness of your enemies.
-
To put things another way, security measures generally are only good for buying time. The amount of time bought generally negatively correlates with the amount of resources spent by the attacker. This is not always the case, for example a message encrypted with a one time pad will never be decrypted unless the key is compromised. However, in the majority of cases a security measure can only buy time even if it is properly implemented. In the case of strong encryption such as AES, the amount of time bought is more than enough. It is so long that the universe will die prior to the amount of time bought running out. An attacker can spend enormous amounts of resources trying to reduce the amount of time bought, but even if they spend trillions of dollars they can not reduce the amount of time bought to a level that makes it practical to spend resources. In the case of anonymity networks, especially low latency anonymity networks, the amount of time bought is much less. It might be measurable in hours or days instead of millenniums. Or it might even be measured in weeks or months or years. And attackers are much more capable of reducing the amount of time to practical levels. If you halve ten billion years you still have five billion left. If you halve a year you are left with six months. Even most high latency solutions can only provide anonymity for a number of messages (against global passive attackers). Maybe they will allow you to send fifty messages before you are identified, perhaps one hundred. Exact numbers aside, the point is simply that even rather strong anonymity systems are simply not comparable with strong encryption systems in regards to the amount of resources that it takes for an attacker to compromise them in a practical amount of time.
-
Thanks for all of the info, I appreciate it.
-
found this
https://ostel.me/
This service is a public testbed of the Open Secure Telephony Network (OSTN) project, with the goal of promoting the use of free, open protocols, standards and software, to power end-to-end secure voice communications on mobile devices, as well as with desktop computers.
This service is in public beta. Calls placed throug the system are encrypted and authenticated between peers. It is continually being tested and improved to ensure the best possible security. Logging is minimal and work is being done to ensure no unecessary IP addresses are stored on disk. We encourage you to build your own OSTN server with our cookbook.
Good video on the subject.
http://vimeo.com/45820451