[SIZE="+1"]PART-1-of-2 : Display HASH/Checksum Integrity Code Of Original Files Inside 1st Post & Use HTTPS WebPages/WebSites[/SIZE]
This topic thread is containing various types of info on various matters & areas (related to computers, networks, hardware, software, operating systems, kernels, firewalls, security, protection, prevention, encryption, pgp/gpg, rules & laws, violators, data-miners, data-stealing, vulnerabilities, etc, etc) with primary focus on "PRIVACY-RIGHTS & SECURITY & SAFETY" aspect for Users/People, and their devices, and their used software inside their devices, and the remote-servers where these software are connecting & sending/receiving data with. Our primary focus is NOT how much easy/convenient/nice it is to use something, or how much faster something is, or how many features exist in something.
And we are definitely NOT IN-SUPPORT of how something can or will or should benefit (or needs to secretly benefit), a dictatorial (or harmful or FASCIST) adversary or a SECRET branch (or semi-secret branch or even an open branch) of government or a (public proxy or a private PROXY) Corporation/Company, for doing MASS-SURVEILLANCE or bulk-data-collection or BULK-DATA COLLECTION STORAGE or DATA-MINING activities, WITHOUT ACQUIRING PUBLIC-VOTE FROM MAJORITY-OF-PUBLIC for each specific (secret and not to mention all open) activities. We SUPPORT those activities (and laws, sub-laws, etc) which at-first benefits majority (or close to 100%) of all Public and upholds public (and their persons, houses, papers, and effects) safety & security & privacy & civil RIGHTS & Civil Liberties, according to the country's highest laws which Majority-of-Public of that country have PUBLICLY-VOTED-FOR. (Though not a perfect example, but for the sake of an example, we can mention this example: USA Bill-of-Rights (aka, USA-Constitution, aka, USA Amendments), ICCPR (International Covenant on Civil and Political Rights)). And we SUPPORT such activities (or laws or sub-laws or clauses, legislatures, etc) only-when those are NOT loosing or NOT violating any bits of Privacy Right (for example, USA 4th Amendment Right) or any other Civil Liberty Rights. We DO NOT SUPPORT such SUB-LAWS (aka, Referendums, clauses, legislatures, etc) which are created in a CLOSED or secret or non-open session with NON-MAJORITY of people's decision or with CORRUPTED or BRIBED leaders' (aka, Law-Makers', aka, Public-Servant) decision, and then such sub-laws are used for abusively governing majorities or minorities. We consider such sub-laws are invalid & illegal & unethical in a real healthy democratic system, and so we will not support such unethical sub-laws. But in a special-case, a single person's (and not a group of persons, and NOT at-mass-scale) very-specific personal-record can be REQUESTED-for to-be looked-upon, when+if it is (technologically or humanly) possible (without violating any RIGHTS of even a single-other person, it also means, NO-backdoors are placed or existing in device technologies which can be used to decrypt or to allow collecting or sending or storing data from multiple (or even single) person & from their devices), and when probable-cause/reason AND sufficient-proof exists, and presented to impartial+unbiased+neutral jury & judge, (where, each jury member & each judge's all public records must be available for public access), in an open PUBLIC discussion COURT, with both side present in the court or both side's representatives are present in court, and when jury or judge at-end decides to do so. And such proceeding must also uphold the Right (for example, USA 5th Amendment Right) of any person (and their any device) not-being forced or tortured or hacked, to expose or incriminate themselves, it also means, it allows a person Not-Disclose any of his/her Password or Encryption-Codes or Keys, etc, if he/she chooses or decides to do so.
We will use many acronyms, synonyms, etc, and we will try to keep conversation understandable for average general users of this forum. But, PLEASE CLICK on Acronyms, Synonyms, Links, and REFERENCES items, when you are unable to understand what we are talking about or what we are indicating to or what we are pointing at, and then attentively read further, and then please come back & please continue to the end, as different concepts & different portions of security & privacy are mentioned into different posting.
Links to significant content/post under this thread-topic:
* Post #1: (this 1st post) Info On Necessity Of Using Hash/checksum Integrity Codes, Why Hash Needs To Be Shown On HTTPS webpage How to Calculate/Find Hash codes, Known Weaknesses In Various Hash & Encryption Related Applications & Systems.
* Post #2: Part-2-of-2 for 1st/top post, References.
* Post #3: List Of Hash/Checksum Calculating Apps & TOOLS For Various Different OS & Platforms.
* Post #4: List Of File Compression+Encrypt & Decompression+Decrypt Apps/Tools, List of AppStores, List of Repositories.
* Post #5: Basics on PGP, GPG, OpenPGP Based Verification Of File's Integrity, File-Size, File's Author. How To "Securely" & Correctly Obtain Signing Key/Cert. Where To Show & Share File Signing-Key, Signature File, etc. Which File Signing-Key Or Which Own Key From Author Can Be Trusted. Which Level Of Trust Can Be Used For Signing & Setting Trust-Level, When It is Necessary (and Not-Necessary) To Set Trust-Level.
* Post #7: How To Securely Share Password & Hash Codes & Files With Destination Users, over OTR or END-TO-END ENCRYPTION Supported Secure Instant Messengers software clients.Hi,
DEVS (developers or authors) who release software or data files, should SHOW/share file's HASH/CHECKSUM tiny integrity code, like MD5 and SHA-256 etc, on the 1ST POST / 1ST MESSAGE (of a forum-topic for any category of forum-thread). Please also show/share file's full BYTE SIZE, ... Not it's MegaBytes or KiloBytes or GigaBytes, etc.
Right click on any file, and see/view its "Properties" or "Info" option, it will show you full byte-size, select that portion of text with your mouse & copy (Ctrl+C)(Command+C), and then paste (Ctrl+V)(Command+V) on your 1st post. You only have to do it only-once for each file when you release it for 1st time, and when you release a newer or updated file or version of software. See the 3rd post in below for software tool list, to find out what file-explorer or what file-management software or what tools or what shell-addons, etc you can use for your preferred choice of OS+hardware platform. (Quick-Tip: Inside Android based OS you may/can use "Total Commander" (by C. Ghisler), or, "ZArchiver" (by ZDevs), etc app/tool, to view (and copy) full byte size).
Acronyms, Synonyms:
aka = also known as. alias. alternatively known as, or, alternative similar.
cert = certificate, it is a type of public-side encryption-key. This is needed for HTTPS encrypted communication or data-transfer.
protocol = communication (or data-transfer) language, for computer & any internet connected devices.
TA = Trust Anchor. The beginning/root/source piece of a trusted certificate/key system. aka, trusted anchor, aka, trusted authority (aka, trusted third/3rd party, aka, TTP, aka, TTPA), aka, Certificate Authority (aka, CA).
TLS = Transport Layer Security (TLS). TLS is Successor (aka, Next version) of SSL (Secure Sockets Layer) certificate. It's used for encrypted data/content transport & authentication system, (like, HTTPS, SMTP+TLS, IMAPS, POP3S, etc), to prevent eavesdropping and tampering of data/content in transit. TLS/SSL cert helps to create a secure encrypted PIPE or TUNNEL or TUBE for internet data packets, it is like using a non-transparent pipe/tube or non-transparent glass-bottle for delivering liquid-material into a remote location, where the liquid-material can deteriorate (means, quality or integrity is reduced) if UV-sun-light can shine on liquid directly, example of such liquid is Citrus-oil & other edible-oil.
TLSA = aka, DANE. DANE is part of DNSSEC standard, (dnssec is the standard AND next-version for older DNS standard). TLSA DANE is used for TLS/SSL certificate authentication, via DNSSEC based system, for HTTPS & similar encrypted webpages & web-contents. See in below "REFERENCES" section in 2nd-Post, where i have shown Links-to, How to create TLSA DANE code from TLS/SSL cert, How to add TLSA DNS records in name-server, How to enable DNSSEC for a name-server, How to enable DNSSEC authentication chain with higher level domain-name registrar, etc.
And it would be better, if this entire (xda-developers, aka, xda-dev) website is shared with visitors/users over HTTPS (aka, encrypted) connection based webpages.
A fair strength SSL cert (aka, TLS cert) is now around $6/yr. There are also FREE TLS/SSL cert providers. Search for "LetsEncrypt free SSL cert" in bing/yahoo/google, also see "References" section in below, where i have shown very important links on How to obtain TLS cert, How to decide which TLS cert to use, Which tools can be used, etc.When DNSSEC verification system is applied in name/dns-servers of a website (aka, domain-name) (and also applied into related software/hardware components), then, used TLS/SSL cert can become even more or super secured (and double channel/TA authenticated) to deliver & show the content of webpage.And for this (double TA authentication of webpage content data) to work, user/visitor side also need to use (inside their own computer) a local full dnssec validation supported dns-resolver software ( like, "Unbound" by NLnet Labs https://www.unbound.net/ ) and a dnssec+tlsa validation web-browser addon ( like, "DNSSEC-TLSA-Validator" by CZ.NIC https://www.dnssec-validator.cz/ ).Those two components will display two extra icons in web-browser's url-bar. One icon will indicate if obtained "website" is DNSSEC authenticated or not, and the other icon will display indication if the displayed "webpage" has used correct & DNSSEC-TLSA verified TLS/SSL certificate or not.
HTTPS or SSH or VPN or DNSSEC etc is very secured & encrypted protocol (when higher-strength encryption is used), but HTTP or old DNS or FTP is not. HTTP or old-DNS or FTP is "open", it means its Not-Encrypted, not secured, so internal-content or internal data is not-private, and data/content can be viewed & eavesdropped very easily. For example, when we mail "postcard" to a destination user, via post-office, then such "postcard" is open & it's contents are easily visible to postman and to anyone who have access to mailbox, and also visible to anyone who lives in the destination address location, so it cannot be private or personal anymore. It is also like using a transparent-colored (or see-through) PIPE or TUBE or TUNNEL for delivering water into a tree or garden, where anyone can see the water flowing through the pipe. But using HTTPS means (for example) like this: using a NON-Transparent PIPE or TUBE or TUNNEL to deliver (or receive) liquid material into (or from) a remote or distant location, where such liquid material can deteriorate if UV-sun-light can shine on the liquid, for example, like, citrus-oil or other edible-oil, etc. So to keep the quality of oil intact, inside the pipe, we need to use a non-transparent pipe, to block harmful portions of sun-rays.
When a website or web server connection is using encrypted HTTPS protocol, then in web-browser's URL bar (where web-site address is shown), it will usually display a tiny "Lock" icon/picture, and website address will also begin with https://... not with http://...
"Encryption" is like a cloth/dress/jacket for internet data/packets, it is like using cloth/dress/jacket for a human body, and its like using an Envelope (as a wrapper) for a personal or private (or secret) Mail Message/Letter, before we post it via post-office. But mailed "postcard" (does not have envelope, so it) is open & visible to many, so "postcard" is not private, not personal (in many cases). Encryption or Cloth or wrapper or shield or jacket, protects the internal-thing (aka, internal-content, aka, payload, aka, data) & keeps it intact & unmodified, from environment / stress / abuse & unwanted prying/spying eyes (and from nosy bad people or thief, and from computers made by nosy bad people or thief), and encryption or cloth or jacket protects from harmful things (virus, bacteria, UV-rays, malware software code, data corruption & manipulation, etc) which are out there. And encryption or cloth also keeps you & your family members and your co-workers and your community & neighbors more civilized & secured, like using cloth/dress on human-body, which creates moral shields & security, and also creates security & sense of decency, and also creates barrier for abuse, and reduces chance of abuse, and reduces chance of future abuse. Breaking-seal or Tearing of any Enveloped-Mail message communication by a non-receiver (aka, non-addressed) person or system, is a USA-federal crime, and ofcourse it is also crime in almost all country in world. Breaking seal of sealed-message or tearing of enveloped-mail is treated as crime since these were invented very very long time ago. Similarly, removal of cloth/dress from human-body (aka, nudity) in front of other's kids/children or in (kids/child) school or similar ground/area, is also a USA all-states wide crime, and forcefully removing someone's cloth/dress is even much worse, and even higher level of crime (violation of multiple Human Rights). Please do not support & do not encourage those violators/thieves who forcefully remove cloth/dress or forcefully remove encryption or forcefully decrypt.
Non-Encrypted (aka, open) data packets are faster, because its easier & faster to generate & deliver. But, generation of Encrypted data packets (for different & specific destination location of users & software-clients) are comparatively more computing resource consuming, and thus more time consuming.
Showing any file's hash code (MD5/SHA1/SHA-256) etc checksum, over an un-encrypted or open or HTTP based webpage, is useless & not-secured & not-trustworthy, but slightly better than none. Because, many adversary or many entity or many group or many person or many software, can eavesdrop or alter or change UN-ENCRYPTED internet data traffic very easily. And its easy to steal/blackmail/abuse personal or private data from Un-Encrypted (aka, open) internet data.
Hash/checksum integrity-code (of a file or data), is like a PHOTO-ID of a person, which is attached on a person's passport or on a photo-id-card,
MITM = man-in-the-middle, aka "middle-man". For example: Wireless carriers, Internet connection service carriers, Online/Cloud Email service providers, Corrupted government surveillance agencies (USA based agencies are in top of this list) which are illegally (without obtaining majority of people's vote) have placed computers & routers & gateways to monitor & record & collect data in bulk & mass scale. So middle-man means, anyone (or any computer/router/component), who-ever (or which-ever) sits/exists in-between (or in-middle of) you (or your computer), and, your communication destination person (or computer).
By verifying a downloaded file's actual hash/checksum (INTEGRITY) code, against or with a developer's shared+original hash-code, which is shown in 1st-post of forum website or (in developer's own website) over HTTPS connection, ... users & visitors can figure out, if downloaded file (in their-side) is STILL AUTHENTIC, or has got MODIFIED by someone or by some-program, or got ALTERED or CHANGED by someone or by some program or by some script-codes, in transit (means, in the middle of the way), or got modified or intercepted by a "middle-man" (aka, MITM) type of script or program or person or entity or adversary.
When users or visitors can have (or can obtain) the original CHECKSUM integrity code, shown on a (ENCRYPTED HTTPS) WEBPAGE (created by original developer/author, locating in original developer's/author's own server computer), ... then, it does not matter, from whatever website the main file or data file is (or will be in future) coming-from or downloaded-from, into user's or visitor's computer. AND it also does not matter whatever NON-ENCRYPTED connection protocol or software is used, to obtain the main file. Because user or visitor has obtained the tiny hash/checksum code (or checksum code file), over a HTTPS based secure + TRUSTWORTHY + encrypted connection.
Many devs/authors or (owners or builders of) websites use a file-naming-format like this to share the checksum integrity code thru a file, i.e.: a "filename.md5" is indicating this checksum file has the MD5 checksum code for the main file "filename". Similarly, the "filename.zip.sha256" is indicating it contains the SHA256 integrity code for the main file "filename.zip". These checksum files must be delivered to users/visitors over a HTTPS encrypted connection. Then main file "filename" or "filename.zip" can be downloaded or obtained or delivered via HTTP or FTP etc any un-encrypted connection. If the author/developer/website-owner is smart, then they/he/she would also include full byte-size of main-file inside the checksum file. You may use the "DownThemAll" addon in firefox web-browser, and set addon settings to show full url (or, unselect the option "Show only filenames"), then check if the checksum-file's url has started with https://... or http://... And, a pre-obtained hash/checksum integrity code can be entered into the file download window, shown by the DownThemAll addon, before initiating the download in firefox. And then, this addon can auto check file's integrity, immediately after downloading the main file (over HTTP/FTP etc any connection). But this auto integrity check functionality is buggy & not available in all OS platforms yet. And using a separate software tool (other than what has downloaded it), to check the integrity of file, is a better security practice.Request file releaser/developer (or owner/builder of website webpages) to share the checksum integrity codes on a HTTPS webpage, or request to share the checksum integrity FILE over a HTTPS based connection. If you keep your mouse pointer icon on a checksum-file, then it should display the URL in bottom-side somewhere, and check if url has started with https://... or with http://...
Even if, an entire file or software tool is delivered to users/visitors over HTTPS based encrypted connections, the dev/author still need to display it's hash/checksum integrity codes. So that integrity code is helpful when file is (or will be in future) delivered from some (or any) 3rd party websites/web-servers, or from mirror websites, or from file-sharing websites or from different content delivery servers (even though its under the same domain-name), or when file was shared by a 2nd/3rd/4th-party person, who is not the actual (1st party) developer/author.
When a file or software is delivered to a visitor/user from the (actual or) original dev's (or original author's) own website, and when the file and the webpage (html/php/cgi) (which is showing the file's checksum info to user's/visitor's web-browser), ... when both (file & webpage), are delivered-to (or obtained-by) user/visitor from exact same physical web server computer, and over exact same type of SSL/TLS cert based HTTPS encrypted connection, and from exact same domain or from exact same sub-domain, only then, displaying the file's hash/checksum integrity code on the HTTPS webpage, is slightly-less necessary, BUT that said, it is STILL always BETTER to show the integrity code even in such case, so that user/visitor can check (now and in future) the integrity by using the shown hash/checksum code anyway, just to be 100% sure.
Why? Because, webpage & file, (are two different things), each goes to user/visitor over at-least two different SESSIONS : in 1st session, webpage could be showing one set of data using certain encryption strength, but when 2nd session is initiated for some file TRANSFER/download, then a different (LOWER/downgraded/fall-backed) STRENGTH ENCRYPTION or No-Encryption can be FORCED to be used, to intercept & deliver a manipulated data stream (or to eavesdrop). Even the session for webpage, can also be compromised & false checksum for main file can be embedded into webpage. Such exploit has happened, and many (client-side) software & web-servers are still (Dec, 2015) not completely protected from such exploits & vulnerabilities.
CDN = content delivery network. a type of (multiple) file server set. Usually a 3rd party (hosting/cloud/CDN) server (or set of servers), which has (or have) very faster internet connection, to very-quickly deliver webpages or certain files or certain components of webpages, into visitor's/user's web-browser client software.
So, displaying tiny HASH-code (aka, integrity-code) of any (software/media/data/main) file (and displaying it's full byte size) on a HTTPS based webpage, is a very essential step for secured file-sharing, with one of the lowest level of real-security, ... displaying a file's integrity code over HTTPS is very essential, that, it does not matter weather encrypted connection is used for the main file download or not, because file's data-manipulation or intercept is still possible, ... so downloaded any file must be checked after download, by comparing it with correct integrity codes, just to be 100% sure that received file is still 100% intact, ... and this, is a very BASIC SECURITY & BASIC SAFETY (COMMON) SENSE, which, everyone should have & practice, specially when files are delivered-to (or downloaded-by) users or visitors, from some 3RD-PARTY file-sharing (or mirror or cloud or hosting or CDN based) websites or web-servers, or when files are shared by (or will be shared in future by) a (2nd/3rd/4th party) person who is not the actual or not the real author/developer/creator (1st party) of the file (software/media/data).
"Best" (or, one of the "BEST" option or practice) is to publish the author's/developer's/releaser's FILE-SIGNING public-side encryption KEY (aka, public-side certificate), into DNSSEC based resource-record (RR), and also show the public-side key/cert code or file on a HTTPS based webpage (or share with user/visitor thru a HTTPS based file). Such KEY file/code MUST be shown from original author's own server from their own home or office, which must not have any-access by any-other user or group, who are not part of the software project. And original author must also own the SSL/TLS cert, used by the sub-domain or domain name of that server. Then author/developer/releaser must do a PGP or GPG or OpenPGP "sign" step/process for the main/data file, and must share the resulted "signature" file, (aka, "sig" file or "asc" file) with user/visitor, also over HTTPS based encrypted connection, (and author should include main/data file's checksum & full byte-size inside the ("sig"/"asc") signature-file). Then main/data file can be shared-with or delivered-to any user/visitor, over any type of connection, either open or encrypted any type connection, and from any type of web/file-server, or from any type of 3rd-party server: Mirror/CDN/Cloud/Hosting etc. (For more info or basics on GPG or GnuPG or PGP or OpenPGP based file-&-author-&-size, all authentication (aka, verification) process, see below into 5th post, related to PGP/GPG).
-.-.-.-.-.-.-. -.-.-.-.-.-.-. -.-.-.-.-.-.-. -.-.-.-.-.-.-. -.-.-.-.-.-.-. -.-.-.-.-.-.-. -.-.-.-.-.-.-.
CONTINUED ON NEXT POST.
SEE NEXT POST, FOR PART-2-of-2.
REFRENCES:
Moved references into 2nd/below post.
Well informed (and well spirited) suggestions to improve this & other posting info, are welcomed, but please provide your links & references. Or, add/post your own posting related to this thread, under this thread (or in your own or other thread, and let me know), then i can add link to it in the top/1st post, if its correct. Thanks in advance. #xda-devs @ irc.freenode.net
Note:
I have tested most but not all.
Note:
I have copied various info portions on this & my other posts, from various other websites & authors, with their permission obtained. Most of which are mentioned inside each post's "References" section.
Display HASH/Checksum Code Of Original Files Inside 1st Post & Use HTTPS WebPages
[SIZE="+1"]PART-2-of-2 : Display HASH/Checksum Integrity Code Of Original Files Inside 1st Post & Use HTTPS WebPages/WebSites[/SIZE]
At the time of this message/post initial writing, it is now June, 2015: every 18 to 24 months or so, general computing power is doubling up since/around 1971. And, in every 12 months or so, super-computing power is doubling up. Displaying/showing/informing ONLY the MD5 hash-code of a file, MUST be avoided, as MD5 was cracked long time ago (in around 2004), cryptanalysis showed wrong files can be created to have/produce/show same MD5 (you may want to see the PDF file linked in below reference section). Fake MD5 based SSL certificate-authority (CA) is existing since 2008, which is more dangerous than any single MD5 based SSL certs. Displaying only SHA-1 hash-code must also be avoided, it was also cracked few years earlier (in around 2009, then again in 2011, and then again in Oct, 2015, and getting more easier by each time). Displaying (only) SHA-256 code is better & still fine for now (yr2015-june). Displaying of MULTIPLE hashing integrity codes for same file, is also very fine step, infact, it is better. Like showing both: SHA-1 & SHA-256, or, MD5 & SHA-1, or, MD5 & SHA-256, etc. Because, to create a fake file to match both types of hash-codes & also matching the shown file size, would be almost-impossible, (but not totally impossible). Using SHA3-512 (by USA-NIST) or SHA-512 (by USA-NIST) etc is always better than using any other lower strength hash (Jan 2016). You may also consider to use Skein hash, or use both Skein & SHA3-512 (or SHA-512). Whenever a lower strength hash algorithm or mechanism is used, then that data-portion is secure for a less-longer time (it means, that data-portion is secure for a shorter time period), than a data, which is hashed using a higher strength hash algorithm or mechanism.
Please use (one of) those or other hash/checksum calculating software tools/apps, and compute checksum/hash-codes for files, and copy-paste those hash-codes (and file's full byte-size) into your 1st post/message, under each released file or file-link, immediately when you release. A dev only need to do it once (one-time), when he/she releases a new file.
Thanks for considering & practicing.
-- Erik.
REFERENCES:
* https://eprint.iacr.org/2004/356.pdf (PDF file) (Practical Attacks or Risks on Digital Signatures Using MD5 Message Digest 5, in 2004).
* wikipedia.org/wiki/Comparison_of_file_verification_software
* wikipedia.org/wiki/Hash_function_security_summary
* wikipedia.org/wiki/Collision_attack (researchers use such techniques for finding a data(-file) with same Hash integrity code, to see weakness level in hash functions, including how weak is PBKDF, PBKDF2, etc based protection, because hardware computing power around us, are changing every 12 to 18, or 18 to 24 months. When we know how risky or vulnerable a thing is, or When we know what amount of danger exists in a thing, then we can improve (and have a chance to improve) it by reducing risks/dangerous items/components and fix it).
* wikipedia.org/wiki/Comparison_of_cryptographic_hash_functions
* http://www.reuters.com/article/2014/03/31/us-usa-security-nsa-rsa-idUSBREA2U0TY20140331 (RSA encryption codes are backdoored (in 2004) for Mass Surveillance (aka, Bulk Data Collection) by USA-NSA, which is in violation of multiple Amendments of USA Bill Of Rights, not to mention it was in violation of worldwide many other Laws & Rights).
* https://pomcor.com/2016/02/09/nsas-faqs-demystify-the-demise-of-suite-b-but-fail-to-explain-one-important-detail/ (NSA’s FAQs Demystify the Demise of NSA's Suite-B for Cryptography, but Fail to Explain One Important Detail, written by Francisco Corella, Feb-09, 2016)
* https://sites.google.com/site/ItsTheSHAppening/ (Not-so-costly hardware-sets or systems can be used (in Oct, 2015) easily to create SHA1 collisions, demonstrated by Marc Stevens (CWI, the Netherlands), Pierre Karpman (Inria, France and NTU Singapore) and Thomas Peyrin (NTU Singapore)).
* http://www.WashingtonPost.com/world/national-security/us-israel-developed-computer-virus-to-slow-iranian-nuclear-efforts-officials-say/2012/06/19/gJQA6xBPoV_story.html[/b] (The "Flame" virus was, invented at-least 5 years earlier of 2012 by United States of America (U.S.A) & Israel, jointly. Though it was used (by them) for long time, but this info (was disclosed to public, aka) came to public knowledge in 2012, it+they used MD5 weaknesses in SSL certs).
* https://www.win.tue.nl/hashclash/rogue-ca/ (Fake MD5 based CA cert, in 2008, which used complete new type of attack which no other earlier researchers even mentioned/indicated/found. Such news should create questions in your mind, if not, something wrong with your brain & body, question like this: So how about SHA1 based SSL certs or others ? Even after cryptanalysis researchers suggested long time ago, not to use SHA1 after 2010, then why many CA (SSL cert providers) are still providing SHA1 based SSL cert even in 2015 ?!!! Another question should come to your mind, Why & how few countries or businesses still received MD5 based SSL certs & kept on using it, even after 2008 ?!!!).
* en.wikipedia.org/wiki/PBKDF2 (Read & analyze & follow related & referenced links to understand, why all developers & users should use stronger Hash & longer length password, in various software login components & in file/data encryption components & in other areas).
* https://tools.IETF.org/html/rfc5246 (RFC-5246 : TLS-Protocol-1.2, and updates).
* wikipedia.org/wiki/Cipher_suite (Various Combinations of Authentication, Encryption, Message Authentication Code (MAC) and Key Exchange Algorithms, etc which are used for TLS/SSL certs, for HTTPS & similar encrypted connections). https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml (List of Cipher Suites), OpenSSL-ciphers , GnuTLS-ciphersuites
* What SSL/TLS Cipher Suites Should Be Used in a High Security HTTPS environment? (discussed & voted by members of StackExchange.com).
* Testing for Weak SSL/TLS Ciphers
* https://LetsEncrypt.org/howitworks/ (Obtain FREE SSL/TLS Certificates for your domain-name & web-servers. Unfortunately it needs to run inside a web-server with root-level access given to it for major updates, OR, obtain LetsEncrypt-NoSudo which does not need root-level access). Read more info from wikipedia.org/wiki/Let's_Encrypt.
* https://httpd.Apache.org/docs/2.4/ssl/ssl_howto.html (How to add SSL/TLS certificate in Apache httpd web server).
* https://www.OpenSSL.org/docs/faq.html (FAQ on OpenSSL & Certificate).
* http://GnuTLS.org/ (Though this project website itself is not using any HTTPS server yet, but it is a very very good alternative of OpenSSL tool, and GPG based authentication can be done on downloaded files), wikipedia.org/wiki/GnuTLS , http://gnutls.org/manual/gnutls.html
* wikipedia.org/wiki/Comparison_of_TLS_implementations (Comparison of various types of certificate creator software & tools).
* https://www.InternetSociety.org/deploy360/resources/dnssec-registrars/ (How To Secure And Sign Your Domain With DNSSEC Using Domain Registrars).
* https://www.ISC.org/downloads/bind/dnssec/ (Basics of enabling DNSSEC using BIND domain name-server). Automatic DNSSEC Signing With BIND NameD.
* https://wiki.Debian.org/DNSSEC (Enabling DNSSEC based domain-name resolution by using various name-server software, on Debian linux).
* https://www.Unbound.net/documentation/index.html (How to use "unbound" in your computer as a local full DNSSEC supported DNS resolver).
* https://www.internetsociety.org/deploy360/blog/2013/12/want-to-quickly-create-a-tlsa-record-for-dane-dnssec/ (How to publish a free or self-signed or purchased SSL/TLS certificate in TLSA/DANE DNSSEC record for HTTPS based web-servers).
* https://www.internetsociety.org/deploy360/resources/dane/ , https://tools.IETF.org/html/rfc6698 (Standard definitions on DANE, aka RFC-6698). Rfc7218 (DANE-acronyms). Rfc7671 (DANE operational guidelines).
* https://tools.ietf.org/html/rfc7469 (Public Key Pinning Extension for HTTP, aka, HPKP). Use HPKP as well as DANE. You may also want to see HSTS (HTTP Strict Transport Security) and HSTS-weaknesses.
Note:
Well informed suggestions to improve this & other posting info, are welcomed, but please provide your links & references. Or, add/post your own posting related to this thread, under this thread (or in your own/other thread, and let me know), then i can add link to it in the top/1st post, if its correct. Thanks in advance. #xda-devs @ irc.freenode.net
Note:
I have tested most but not all, and i have copied various info portions on this & my other posts, from various other websites & authors, with their permission obtained.
File Hash/Checksum Integrity Code Calculating Tools & Apps For Multiple Platform & OS
[SIZE="+1"]C[/SIZE]HECKSUM or [SIZE="+1"]H[/SIZE]ASH [SIZE="+1"]INTEGRITY[/SIZE] code [SIZE="+1"]CALCULATOR TOOLS[/SIZE]/APPS:
These are very common & easy to use tools.
Over time, file-sharing website or account, etc goes down or expires, but if the hash/checksum-code is obtained & known, from original developer's work or developer's 1st post (from forum websites), then original file still can be obtained/downloaded from any other locations, or uploaded-&-shared by ANY other USER or group, WITHOUT the FEAR & CHANCE, that, (one or more) MALWARE/virus/trojan/backdoor etc was EMBEDDED by that user/sharer/group/MITM. And hash-code (aka, checksum-code, aka, integrity-code) also helps to make sure, that, correct & intended files are used by users/visitors now & in later times.
OS = Operating System. It is a system of governing inter-communication in-between various hardware components & firmware components & software components. It has the potential of becoming self-aware (aka, have a form of soul), if enough intelligence (from other intelligent beings, and nature) is transferred/trained/shown/recorded into it, and if enough freedom is permitted for its various components & functions.
In Microsoft [SIZE="+1"]Windows[/SIZE] OS:
developers/users/visitors may obtain & load any below apps/tools (from any link, if they wish to), these tools can add an extra tab/page, inside file's "Properties" info-window (or can add an extra right-click context-menu item), which can be used from "Windows Explorer" (it is a GUI shell window for file management in Windows OS computers). Just right-click on any file, goto "Properties", then find+goto "Hash" tab or similarly named tab, and then click on "Calculate" button or similar button, to view that right-clicked file's md5, sha-256, etc hash/checksum tiny integrity codes. You can press both Windows-Flag button & the E button together, to start the Windows Explorer, in windows.
* https://github.com/arktronic/hashprop/
* https://www.safer-networking.org/products/filealyzer/
* http://www.febooti.com/products/filetweak/members/hash-and-crc/
* http://implbits.com/products/hashtab/
* http://code.kliu.org/hashcheck/
* https://github.com/gpfjeff/winhasher
* https://code.google.com/p/jdigest/
Above or below websites, which are NOT using a HTTPS based webpage or connection, for showing the hash-code of their hash-calculating tool file, those website's owner/developer must add a TLS/SSL-certificate in their website server, and must show hash-code of file on a HTTPS (encrypted) webpage, and must allow users/visitors/developers to obtain such important & INITIAL level software tool/app over HTTPS secure+encrypted connection.
Once such a tool/app is obtained securely & installed in a developer's computer, then, a developer only need to calculate only-once for each file & show the tiny few bytes of alpha-numeric characters of HASH/checksum integrity codes (next-to or under the filename or file-link), shown on a HTTPS (secure+encrypted) forum WEBPAGE (in the 1st post/message of a forum-thread or forum-topic), and then, any large or small size files can be delivered to users over any non-encrypted connection link/page, like: HTTP, FTP, p2p (bittorrent), etc, and can also be delivered to users from any 3rd-party websites.
CLI = Command Line Interface.
[SIZE="+1"]MacOS/Linux/Unix[/SIZE]:
start a "Terminal" window (a CLI shell), type "openssl md5 " (without those double quote symbols, and enter a single "space" character after that "md5" word), or type "openssl sha256 ". Then, from MacOS "Finder" app (which is equivalent of "Windows Explorer", or, "Total Commander", etc), DRAG-&-DROP that downloded file on the end of the word "md5" or "sha256", in that "openssl" line in "Terminal" window. Then press "enter" or "return" button, and you now have checksum/hash-code. Getting tiny hash-code is that easy.
In [SIZE="+1"]MacOS[/SIZE]:
user/dev may use below few GUI based hash calculator tool:
HashTab:
http://www.implbits.com/Products/HashTab.aspx
previous link is not on a HTTPS webpage & it asks for email registration.
free.
HashMaker:
https://itunes.apple.com/us/app/hashmaker/id509733654?mt=12
free.
In [SIZE="+1"]MacOS & Linux/Unix[/SIZE]:
many other command-line interface (CLI) based hash/checksum code calculator tools can be used, too many to list here.
In [SIZE="+1"]Linux/Unix[/SIZE] OS:
below hash/checksum code calculator tools may be used:
DeepDigest:
https://sourceforge.net/projects/deepdigest/
Update, Mar 5, 2016: SourceForge (SF) website has began to allow HTTPS encrypted connections, for all general users & visitors (at-least for USA side users/visitors). To view HASH code of files, over HTTPS webpage/connection, their forced sign-in/login process/policy is not required anymore.
Older (Jun 20, 2015) info: After login/sign-in into SourceForge (SF) website, if you click on the circular "i" icon next to filename, then it can show hash-code of the file, but its not obtained over a HTTPS based query in all locations ! Unfortunately SF requires users to login 1st, before pulling & showing any hash/integrity code, (and the SF website is not HTTPS based by default on all locations), so targeted attack & alteration is possible toward a certain locality or user.
[SIZE="+1"]Android[/SIZE] / [SIZE="+1"]AOSP[/SIZE] / [SIZE="+1"]CyanogenMod[/SIZE] / [SIZE="+1"]Replicant[/SIZE], etc OS:
user/dev may use below app (GUI tool), to calculate hash/checksum code:
Hash Droid (by Hobby One) : open-source, free, available in PlayStore, it does not use Un-Necessary Permissions & does not do unnecessary system level Accessing:
https://play.google.com/store/apps/details?id=com.hobbyone.HashDroid&hl=en
ZArchiver (by ZDevs): free, file compression/decomression tool, available in PlayStore, it can show only MD5 (in current version 0.8.3) when "Information" option is chosen after touching & holding-onto a file, it does not allow to copy the MD5 code, this tool does not use Un-necessary Permissions or System Level Accesses:
https://play.google.com/store/apps/details?id=ru.zdevs.zarchiver&hl=en
[SIZE="+1"]iOS[/SIZE] (Apple [SIZE="+1"]iPhone[/SIZE] / [SIZE="+1"]iPad[/SIZE] etc devices) OS:
user/dev may use below free, open-source checksum calculating tool:
info coming here later.
So far no free hash calculating tool is found in iOS !!! out of 1.4 million iOS apps, not one free app to check hash integrity of downloaded files !!!
A free MD5 hash/checksum calculating library is available for iOS apps, so if any free File management or Archiver type of app can integrate it, then they can provide the feature for "free", it can also be adapted for other hash functions : https://github.com/JoeKun/FileMD5Hash
Microsoft [SIZE="+1"]Windows 10 Mobile[/SIZE] / [SIZE="+1"]Windows Phone[/SIZE] OS:
user/dev may use below free checksum/hash calculating tool:
Hash Express (by eCodified) : free, available in Windows-Phone appstore:
https://www.microsoft.com/en-us/store/apps/hash-express/9wzdncrdmnj7
Hash (by Miroslav Veselý) : free, available in Windows-Phone appstore:
https://www.microsoft.com/en-us/store/apps/hash/9wzdncrdmn99
-.-.-.-.-.-.-. -.-.-.-.-.-.-. -.-.-.-.-.-.-. -.-.-.-.-.-.-. -.-.-.-.-.-.-. -.-.-.-.-.-.-. -.-.-.-.-.-.-.
Note:
If you find free tools are useful or helpful and not-intrusive for you, then please try to donate what you can, so that developer/group can continue to develop & update & provide a non-intrusive program for free. Please do not donate & do not encourage those, who makes intrusive/spying programs.
Note:
I have tested most but not all, and i have copied various info portions on this & my below posts, from various other websites & authors, with their permission obtained.
File Compression (zip, archive, compact, pack) & Decompression (unzip, unarchive)
[SIZE="+1"]FEW CHOICES FOR FILE COMPRESSION (aka: ZIP, ARCHIVE, ENCRYPT, COMPACT, PACK), or, DECOMPRESSION (aka: UNZIP, UNARCHIVE, DECRYPT, EXTRACT, UNPACK) TOOLS:[/SIZE]
-.-.-.-.-.-.-. -.-.-.-.-.-.-. -.-.-.-.-.-.-. -.-.-.-.-.-.-.
[SIZE="+1"]Windows[/SIZE] platform/os:
7-zip : open-source, GUI, CLI, 7zip-manager can compress+decompress multi files+folders, encrypt/decrypt, LZMA & various other formats & algorithms are supported.
http://www.7-zip.org/
https://SourceForge.net/projects/sevenzip/
-.-.-.-.-.-.-. -.-.-.-.-.-.-. -.-.-.-.-.-.-. -.-.-.-.-.-.-.
[SIZE="+1"]Mac OS X[/SIZE] platform/os:
(some core portions of this OS is BSD or FreeBSD Unix)
7zX : a 7-zip based derivative, GUI, encrypt is supported, it can do only one file at-a-time compression.
http://7zx.UpdateStar.com/
Keka : a 7-zip based p7zip derivative, open-source, GUI, compress+decompress tool, encrypt/decrypt, obtain free-edition from their website.
http://www.KekaOSX.com/
The Unarchiver : GUI, decompression tool, decrypt only, obtain it from Apple iTunes Mac AppStore.
https://itunes.apple.com/us/app/the-unarchiver/id425424353?mt=12
-.-.-.-.-.-.-. -.-.-.-.-.-.-. -.-.-.-.-.-.-. -.-.-.-.-.-.-.
[SIZE="+1"]Linux/Unix[/SIZE] platform/os:
p7zip : a 7-zip based derivative, open-source, compress+decompress tool, encrypt/decrypt.
https://SourceForge.net/projects/p7zip/
p7zip for Debiaun, Ubuntu, etc.
https://packages.debian.org/sid/p7zip-full
-.-.-.-.-.-.-. -.-.-.-.-.-.-. -.-.-.-.-.-.-. -.-.-.-.-.-.-.
[SIZE="+1"]Android[/SIZE] [SIZE="+1"]/[/SIZE] [SIZE="+1"]CyanogenMod[/SIZE] [SIZE="+1"]/[/SIZE] [SIZE="+1"]Replicant[/SIZE], etc platform/os:
Total Commander by C. Ghisler : file management software/tool, available in Google Android PlayStore, it can compress & browse/view, encrypt only. It requires such Permissions: Photos/Media/Files (modify or delete the contents of your USB storage, read the contents of your USB storage), Other (access Bluetooth settings, pair with Bluetooth devices, full network access, view network connections, prevent device from sleeping, install shortcuts).
http://www.ghisler.com/android.htm
https://play.google.com/store/apps/details?id=com.ghisler.android.TotalCommander
ZArchiver by ZDevs : available in PlayStore, free, it can compress+decompress and browse/view, encrypt/decrypt, it does not use Un-Necessary Permissions or System Level Accesses.
https://play.google.com/store/apps/details?id=ru.zdevs.zarchiver&hl=en
UnZip & Unrar - Zip file by UCWeb Inc : To use it, user must also install the tiny web-browser "UC Browser Mini - Save Data" (1.5MB) from same developer, (unselect the "Cloud Acceleration - wap access via server" option in UC Browser after install, if you prefer higher-level "security" more, than slightly higher speed). Unzip-&-Unrar is available in play appstore, free, decompress, decrypt, it does not require extra unnecessary permission, but the web-browser does need access to many Permissions.
https://play.google.com/store/apps/details?id=com.uc.addon.decompress
https://play.google.com/store/apps/details?id=com.uc.browser.en
Unzip Tool by lichy : available in play appstore, free, decompress + compress, file browse, encrypt/decrypt. though it works on many android version but it uses lots of unnecessary Permissions & accesses, like: Location (precise location (GPS and network-based), approximate location (network-based)), Photos/Media/Files (modify or delete the contents of your USB storage, read the contents of your USB storage), Wi-Fi connection information (view Wi-Fi connections), Device ID & call information (read phone status and identity), Other (view network connections, full network access). So avoid it if you care more about higher-level "security", unless you must have to have a such tool's functionalities. (i included it, because i also have firewall (frwl) and it is configured to not-allow send/receive any stuff through internet, and i have noticed it's file-browsing feature was slightly better than few other similar apps in older android os).
https://play.google.com/store/apps/details?id=com.lichy.unzip
-.-.-.-.-.-.-. -.-.-.-.-.-.-. -.-.-.-.-.-.-. -.-.-.-.-.-.-.
[SIZE="+1"]iOS[/SIZE] (iPhone/iPad) platform/os:
zip rar tool free - (zip/unzip/unrar/un7z) from email & File manager for Dropbox, Box (by tau xu) : available in iOS/iPhone/iPad iTunes AppStore, free, compress+decompress tool, encrypt/decrypt.
https://itunes.apple.com/us/app/zip-rar-tool-free-zip-unzip/id649649718?mt=8
ZipApp Free - The Unarchiver (by Langui.net) : available in iOS/iPhone/iPad iTunes AppStore, free, multi-format decompression tool & zip-only compression), multi format decrypt & zip-only encryption.
https://itunes.apple.com/us/app/zipapp-free-the-unarchiver/id585600850?mt=8
-.-.-.-.-.-.-. -.-.-.-.-.-.-. -.-.-.-.-.-.-. -.-.-.-.-.-.-.
[SIZE="+1"]Windows 10 Mobile / Windows Phone[/SIZE] platform/os:
"Windows Phone" is successor of "Windows Mobile", and "Windows 10 Mobile" is successor of "Windows Phone".
STARchiver ZIP RAR (by Attractor Mobile Software) : free, compress/decompress, encrypt/decrypt.
https://www.microsoft.com/en-us/store/apps/starchiver-zip-rar/9nblggh67q7l
-.-.-.-.-.-.-. -.-.-.-.-.-.-. -.-.-.-.-.-.-. -.-.-.-.-.-.-.
REFERENCES & List of AppStores & Repositories:
* wikipedia.org/wiki/Comparison_of_file_archivers
* https://apps.microsoft.com/ (Windows Store, aka Windows AppStore, for Microsoft Windows OS based PC, Laptop, Notebook/Netbook, Surface, Tablets, etc x86/x86-64/ARM)
* https://Cygwin.com/ (Repository of Linux & Unix & open-source POSIX tools & apps & packages, made usable for (Microsoft) Windows OS. It does not require an administrative user access during install & update. Also used for loading required dependencies, compiling, and to obtain cygwin*.DLL for POSIX apps/tools).
* https://MinGW-w64.org/ (Repository of Linux & Unix & open-source POSIX tools & apps & packages, made usable for (Microsoft) Windows OS. It does not require an administrative user access during install & update. Also used for loading required dependencies, and includes GCC compiler. Note: This website uses SSL/TLS cert from "nautica.notk.org" which is issued by CAcert.org, so you will have to add that SSL/TLS cert as a temporary exception in your web-browser, for accessing the website over HTTPS connection).
* https://itunes.apple.com/us/genre/mac/id39 (Apple iTunes AppStore, for Mac OS X computers)
* https://www.apple.com/osx/apps/app-store (Apple Mac OS X AppStore, for Mac OS X computers)
* https://www.MacPorts.org/ (Repository of Linux & Unix tools & apps & packages, made usable for Mac OS X. It requires an administrative user access during install & update. Also used for loading required dependencies, and compiling.)
* https://Brew.sh/ (HomeBrew) (Repository of Linux & Unix tools & apps & packages, made usable for Mac OS X. It does not require an administrative user access during install & update. Also used for loading required dependencies, and compiling. This website is using a common SSL/TLS cert from their GitHub project, so used SSL/TLS cert is not their own)
* https://addons.mozilla.org/en-US/firefox/ (Mozilla's Firefox web-browser Addons & web-browser based App list, for Windows OS, Mac OSX, Linux, Unix, etc computers)
* https://chrome.google.com/webstore/category/extensions/ (Google's Chrome web-browser extension list, for Windows OS, Mac OSX, Linux, Unix, etc computers)
* https://chrome.google.com/webstore/category/apps/ (Chrome web-browser based App list, for Windows OS, Mac OSX, Linux, Unix, etc computers)
* wikipedia.org/wiki/List_of_free_and_open-source_iOS_applications
* https://github.com/dkhamsing/open-source-ios-apps
* https://itunes.apple.com/us/genre/ios/id36 (Apple iTunes AppStore for iOS/iPhone/iPad/etc)
* https://www.apple.com/appstore (Apple iOS App Store. Note: unless an iOS based web-browser's user-agent string is set or found, this URL will detect user-agent string and user's IP-address location, and then it will auto-forward users/visitors to a different appstore. Another simpler alternative is, use the iTunes app to browse+view iOS App Store apps).
* http://apt.saurik.com/ (SaurikIT Repository, aka Cydia appstore, for Jailbroken iOS/iPhone/iPad etc, more info)
* wikipedia.org/wiki/List_of_free_and_open-source_Android_applications
* https://play.google.com/store (Google Android Play Store AppStore, aka Android Market, aka "Vending" appstore, aka Google AppStore, aka, Google-Play AppStore)
* https://F-Droid.org/repository/browse/ (F-Droid.org Repository for Android & AOSP based OS)
* https://www.WindowsPhone.com/store (includes apps for both Windows Phone, and Windows 10 Mobile)
* https://addons.mozilla.org/en-US/android/ (List of web-browser based addons & apps for Mozilla's Firefox web-browser for Android) (Firefox Browser for Android from Play-store, Firefox web browser for iOS/iPhone/iPad etc, from iTunes appstore for iOS/iPhone/iPad etc) (Note: Firefox for iOS does not support addons yet)
* http://www.GetJar.com/mobile-apps/ (List of Java Jar based apps for various mobile multiple platforms)
* List of more Software Package Management Systems (wikipedia).
If you find free tools are useful or helpful or not-intrusive for you, then please try to donate what you can, so that developer/group can continue to develop & update & provide a non-intrusive program for free. Please do not donate & do not encourage those, who make intrusive/spying programs.
GPG / PGP Based File Integrity And Actual File Author Authentication / Verification
[SIZE="+1"]How to verify a file's integrity & same file's author/developer, both/etc all at same time ?[/SIZE]
A Brief/Short ([SIZE="+1"]PGP / GPG[/SIZE]) Summary is:
When we carry out a file's checksum/hash verification process, or a file's integrity checkup process, then this process makes sure if the file under investigation, whether has correct & intact (md5/sha1/sha256 etc) integrity or has got modified/altered, it answers or clarifies ONLY those area or aspect. An integrity verification process does not verify a file's author, and does not verify if the file has correct byte-size or not.
When only checksum/hash/intergrity code is shown & obtained from a popular HTTPS based (encrypted) website webpages, then it has suffice (a minimum low-level of) security or suffice (a minimum low-level of) trust-level, but Not One-of-the-Best (O-o-t-B) security-level or O-o-t-B trust-level. Because, it does not tell or indicate & does not PROVE to users/visitors, WHO EXACTLY made that file (aka, Which exact developer developed that file, or Which exact author created that file), AND, it (checking only hash-integrity) also does not prove WHAT'S the actual file size (which was released by the actual-&-original developer or author).
So, to verify a main file's integrity, and to verify the actual maker/creator/author/developer/releaser of main file, and to verify if the main file has correct size, ... any shared main file must also have a (PGP or OpenPGP or GPG based) "signature" file (aka, "sig" or "asc" file), and such file must be shown next to the main file download link. And a "signature" file (it is a very small file, usually under 8 kilo-bytes) must be delivered to user/visitor over a HTTPS encrypted connection. And then, main file can be delivered to user/visitor over any type of open or not-encrypted connection, (or even over any encrypted connection).
And for this to work, user/visitor also needs the FILE-SIGNING public (aka, pub) KEY, which was used to create the signature-file (SIG or ASC). And user must obtain it over a HTTPS encrypted webpage or connection. So, developer or author MUST SHARE file-signing GPG/PGP pub-key over an encrypted webpage or file, shared from their OWN main/source website/server (it means, pub-key MUST be shown from a such Server Computer which the original developer/author has full-control & kept in their/his/her own office/home, it means, Beside the original author/developer NONE-OTHER have any-control on it. And original author/developer MUST ALSO OWN the SSL/TLS certificate for the sub-domain or main domain used in that server). When a File-Signing Gpg/Pgp/OpenPgp Pub Key is shared/shown from a Mirror or CDN or hosting or Cloud Hosting server or Forum website or shared project site (like Github, SourceForge) etc 3RD-PARTY websites, or, When pub-key is shared/shown over open/unencrypted connection like FTP or HTTP etc, then such Gpg/Pgp pub KEY has "ZERO" (aka, NO, none, nada) security. When used all components or all tools or all factors/vectors or all connection or all software or all portions, etc ALL & each, are secured (encrypted & verified & authenticated), to keep the security-level & trustworthiness-level checked at a Fully/Totally/Completely-"TRUSTED" level. If EVEN-ONE of the "SINGLE" used tool/portion/factor/vector is NOT WHAT is mentioned previously, then it is NOT-TRUSTED (aka, NOT-SECURED), or Not-Fully-Trusted, or Not-Totally-Trusted, or Not-Completely-Trusted, etc. We also need to realize, Reaching an absolutely "Trusted"-level (for infinite amount of time duration into future) may not be possible in real life (with finite amount of resources), So we MUST need to TRY AT-LEAST to reach a "COMPARATIVELY-MORE TRUSTED-Level" or "COMPARATIVELY-MORE SECURED" level, FOR "SIGNIFICANT" AMOUNT OF TIME (INTO FUTURE), so that, those who are "REMOVING-TRUST" (or those who are "DECRYPTING & STEALING" private-data), CANNOT COMPLETE decryption+theft process for SIGNIFICANT amount of TIME DURATION, so that we can avoid assist them in decrypting+stealing our private-data, so that we can make it MORE-HARDER for them to decrypt+steal our private-data. Always use most strongest encryption, because each new computing hardware, in each 12 to 18 months, is becoming double-time powerful & capable than before, to decrypt quickly. Encryption is like a cloth/jacket/envelope (a wrapper/cover) for digital data packet, we use cloth/dress on a civilized human-body for privacy & decency & for protection of body, and we use envelope when we send private/personal mail via post-office, to a destination person's address. HTTP/FTP/POP/SMTP/IMAP etc is like sending or mailing a postcard, which is open, anyone can see+steal+record. But, HTTPS/SSH/VPN/PGP/GPG/IMAPS/POPS/SMTP+STARTTLS etc is encrypted, it is like sending an enveloped mail or using a non-transparent tube for data-transfer or communication. Read the top-most 1st post (in this forum topic thread), to understand more on Encryption, Decryption, Privacy-Rights, Civil-Rights, etc.
Non-encrypted data packets are faster, because its easier & faster to generate non-encrypted data packets, as such data packets require lesser computing & lesser processing & lesser verification. Generation of Encrypted data packets are computing resource consuming, and thus time consuming, (inside the server computer which will generate it), as these type of encrypted data packets are intended & directed toward certain specific & different destinations, and each destination's encrypted data packets need to be different & unique than other destination. Once encrypted data packets are generated, then transfer process of it via/thru other computers, is comparatively less resource consuming.
Public = pub. Openly available for any public/person. for public use, for general use, for open use.
Private = prv = priv = pvt. Private or personal or secret portion-&-use purpose, it is Not for public/general eyes.
A file's author/maker/developer need to load an OpenPGP or GPG or PGP software, and create an openpgp/gpg based (encryption) key-pair for file-signing purpose, and keep the "private-key" (or "secret-key") portion private (in an external write-protectable SD flash-memory media/storage drive or inside a secured read&write-protected Keyring or Keychain usb device), and then author/dev can share the file-signing "public-key" portion (aka, public-key-file) of file-signing key-pair, with the users/visitors over a HTTPS encrypted secured webpage.
Some dev/author may also choose to "sign" files, with their own primary identity pub-key-file profile. Portable apps (like, email client software, portable gpg/pgp/openpgp software/tools, etc) can be kept in a portable usb storage device or in a (write-protectable) flash memory media/storage card. These "portable" software must not write into or use host computer's storage media, for better security. Multi partitions can be created inside external storage media/cards, for storing "secret"/"private" portion, and "public"/general portion.
Then author/developer of software tool, can (bundle into a zip/7zip/tar etc compressed format file, and then author/dev can) gpg-sign (or pgp-sign) the main file before releasing it, and gpg/openpgp/pgp tool will create a signature-file for the main file, and then author/dev need to share & show the url-link of the "signature"-file (next to the url-link of main file) in the author's/dev's own primary/source website (not in a mirror or 3rd-party website), for all users/visitors, over a HTTPS encrypted webpage. Also show link to a (HTTPS based) webpage (or show a link to a HTTPS based file-url) from where any user/visitor can get dev's/author's file-signing pub-key code or pub-key-file. And certain command-line option or appending (or piping) command can also output & create a signature-file with the main-file's hash/checksum integrity code & it's byte-size, etc shown inside it, beside the must-have the file-signing openpgp/pgp/gpg code.
On the other side (OTOS), a visitor/user also need to load a openpgp or gpg or pgp software in their side on a secured laptop computer or store sensitive private file stuff (like, gpg/pgp "keyring"-file) inside an external secured portable private flash-memory storage usb-drive, or inside a write-protectable flash-memory media/storage SD drive, or inside a (read & write) RW-protected Keyring or Keychain device.
id = identity, identification.
And then all users/visitors must 1st try to obtain software or file author's/developer's file-signing public-key-file by using a very trustworthy way:
either directly from him/her from a convention or from a key-signing party, which he/she is attending, after a face-to-face conversation. Give the author your (primary-id) pub-key CD/DVD disc (or your write-protectable SD storage card). And get back your signed pub-key and also get author's (primary-id) public-key-file and file-signing pub-key-file, before the end of key-signing party or convention, in a different (write-protectable or write-protected) secured storage media (like, another CD/DVD disc or another SD flash-memory card), to reach one-of-the-highest-trust-level (OOTHTL) or to reach highest-trusted-authority-level (HTAL) in PGP or GPG WEB-OF-TRUST (WOT) LEVEL. If you have original pub-key-files, then GPG/PGP commands can show with higher assurity, that, if the author/developer himself/herself has trusted his/her own file-signing pub-key or not. And, gpg/pgp tool can also show, if the "signature"-file & main-file has been authenticated or not, when you will have author's/developer's file-signing pub-key (inside your own gpg/pgp tool's keyring fille).
And if its not possible for a user/visitor to meet face-to-face, then such user/visitor can obtain file-author's or file-developer's FULL fingerprint-code for his/her file-signing public-key-file, or file-author's primary-id public-key-file, from the author's own-hand-given visiting-card or business-card (if it is published or written or shown in it), then user/visitor can use a gpg/pgp command, to initiate a HKPS encrypted download of author's public key from a public key-server, and then, user can match if the fingerprint-code shown on hand-given visiting/business card has matched with the downloaded key file or not. And then user can also check, if author/developer has indeed trusted his/her own file-signing key or not.
And if even-that-is not-possible, then such category of user/visitor can obtain file-author's older public-key-file codes from the author's any paper-based published book (if entire code was published in it) or obtain shown fingerprint-code of author's pub-key-file from any published book, and use a public key-server & HKPS encrypted protocol, to obtain the full pub-key, and then match book-shown fingerprint code with the downloaded key's fingerprint code.
And if even-that-is not-possible, then such user/visitor can obtain file-author's pub-key file over a HTTPS encrypted webpage or connection from author's own (and author's very trustworthy) website, (which should be DNSSEC secured authenticated domain as well, to reach a double-trust-authority trusted level).
And also, always try to match any downloaded key file's fingerprint, with fingerprint code obtained from author's any published paper source materials. And then find out, if author/devloper has "signed"/"trusted" his/her own file-signing key or not.
And, when any user/visitor is obtaining author's pub-key-file from a public Key-server (even if an encrypted HKPS connection is used) and when that user/visitor does not have the author's/developer's fingerprint code from a trustworthy trusted-authority (TA) or from any published paper materials, then such pub-key cannot be trusted enough, and in such case public key-server is just a middle-man entity, which is very likely to have various multiple keys with same (or similar) name as file-author's name, but actually only one of them or none is correct, which is very likely not possible to be detected by a general level visitor/user.
And, if author shows file-signing pubkey file or fingerprint code on a HTTP (not-encrypted) webpage, then it is not trustworthy enough either, but slightly-better than none/nothing at all.
After previous steps, then a visitor/user is finally ready to do a PGP or GPG based "AUTHENTICATION" of file & file's author, correctly. So now user/visitor can use a pgp or gpg software and load the obtained file-signing (and author's primary-id) pub-key into his/her own gpg/pgp-"keyring"-file, and run a gpg/pgp command, to use (author's file-signing pub-key code and) the "signature"-file which was downloaded (encryptedly), to authenticate (aka, verify) the downloaded main file. GPG / PGP software can show if a downloaded file is specifically verified by the specific author/developer or not, AND, it can also show if the file INTEGRITY is intact or modified, and if the file byte-size has matched or not.
Usually authors & developers associate the shared (primary-id & file-signing) public-key with one of their own (or different) email address. Users/visitors should also create their own key-pair, and try to obtain trust+sign on their pub-key from other people, after meeting them face-to-face & get to know each-other via key-signing party/events or conventions or meetings etc.
When a developer/author is publicly known in real physical world, or has public events with video of lectures/training/guides seminar/convention etc, which are present or visible publicly, then such dev/author person should attend key-signing parties/sessions/events, and increase your WOT level & connections+network with other trusted devs+authors. Exchange business-card or visting card. Share your updated pub-key or at-least share your (long+full) fingerprint with general or other users, from your own website (HTTPS/TLS secured + DNSSEC signed). Also create a file-signing key, and trust+sign it with your main/real/primary identity key, with a higher-level of trust-level. Then you can sign the file-to-be-released with your file-signing key. Also share full file signing pub-key or at-least it's fingerprint-code over a trustworthy HTTPS/TLS secured+encrypted website + DNSSEC signed domain name-servers. Also declare (aka, publicly share) your (and your group member's) main/primary id pub-key & file-signing pub-key fingerprints, in your domain's DNS record & dnssec sign it. When you will reload back your own pub-key after (or during) a key-signing party, then your own keyring will have all necessary codes & data showing who have signed it and who has set what trust levels on it. Then if you update your pub-key with a key-server, then key-server will have updated key, and it will contain data showing who has trusted+signed your pub-key.
But when a dev user or a dev-persona or a user, has some reason(s) to remain less-known physically in real world, or wants to protect privacy or if a dev/user prefers to remain as a virtual presence only person in cyberworld (aka, internet-world, aka, virtual-world), then don't do gpg-sign & don't do gpg-trust with highest trust level, for your pub-key which you will be using for file-signing purpose, with your main/real/primary world identity key. Keep real world main or primary identity pub-key file aspects separate, from a cyberworld-only identity's file-signing pub-key aspects. But if you want to, you can & may sign+trust a pub-key of a cyberworld person or cyberworld person's file-signing pub-key, with a lesser-trust level (like, internet-level or cyberworld level). If a cyberworld entity or identity owns domain & website, then such user can also publish the identity pub-key or file-signing pub-keys, fingerprints, etc over HTTPS+TLS secured/encrypted webpage + DNSSEC signed domain + DNNSEC signed key-fingerprint.
General users or a general visitors, when has not physically seen a person face-to-face in real world, and do not fully trust, and do not really know what this person is really doing in various times, and did not see/view/inspect this person's any official/government issued ID (and photo-ID), then in such cases, general users or visitors should not set trust or gpg/pgp sign any type of (real world or cyber world) pub-key with a Higher-Trust level.
But when a released software/tool file was helpful, and if it was checked via multiple checking / monitoring / benchmarking / analysis / inspecting tools, and if the software/tool was found to have no backdoor, and if the tool did Not send user's private or personal info back to some outsider data-harvestor or data-mining or mass-surveillance or bulk-data-collection entities or adversaries or groups, and if the tool has Not violated various public Privacy-Rights & Civil-Rights & Laws which were passed with majority public's voted public decision, and if the tool is Not assisting corrupted-groups (or corrupted-interests) who created unhelpful & conniving newer Rights & newer Laws, and if the tool is Not assisting corrupted-groups (or corrupted-interests) who created unhelpful & conniving newer Rights or newer Laws or newer Provisions or newer Codes inside a closed-door & non-public & non-publicly-voted session, and if the tool has earned+gained real provable trustworthiness, ONLY then a general user/visitor can trust that specific file's file-signing pub-key with a lower-level trust (cyber-level / internet-level trust), to indicate this dev/releaser/author is trustworthy, at-least at that lower-level of trust-level.
REFERENCES:
* PGP ~=~ OpenPGP ~=~ GPG ~=~ GnuPG ~=~ IETF RFC 4880 . WOT . PGP/GPG Keys Via DANE DNSSEC , DNS OpenPGP Key , DANE .
* https://www.GnuPG.org/ , GnuPG-HowTOs , GnuPG-FAQ , GnuPG-Handbook/Manual/Guides
* https://EmailSelfDefense.FSF.org/ , https://EmailSelfDefense.FSF.org/en/windows.html
* https://people.via.ECP.fr/~clem/nist/gpg-enigmail-howto.php
* http://www.CryptNet.net/fdp/crypto/keysigning_party/en/keysigning_party.html (GnuPG/GPG/PGP/OpenPGP Key Signing Party, WOT) -- by V. Alex Brennen.
* http://pgp.cs.uu.nl/ - Trust Paths of keys, and Key statistics (WOT) -- by Henk P. Penning.
* https://www.rubin.ch//pgp/weboftrust.en.html -- by Patrick Feisthammel.
* key server article on Wikipedia , https://sks-keyservers.net/status/ (Pool list of SKS = Synchronizing Key Servers).
* https://www.gnupg.org/related_software/swlist.html
* https://trac.torproject.org/projects/tor/wiki/doc/TorifyHOWTO/GnuPG (GnuPG, Keyservers, WoT, Key Signing, Trust Levels, Cyberspace, Privacy-Rights, Anonymity, Tor).
Note: i have copied various info portion on this & my other posts, from various other websites & authors, with their permissions obtained.
GPG/PGP 2
reserved this 6th post here.
How To Securely Share Files, Password & Hash With Destination Users, OTR / END-TO-END
[SIZE="+1"]How To Securely Share Files or Password or Hash Codes With Destination Users, Over OTR (Off-The-record) or END-TO-END (E2E) ENCRYPTION Supported Secure (IM) Instant Messengers[/SIZE]
Compression & decompression tools which also have encryption & decryption support or feature, those tools can protect your any files (when files are encrypted), inside your phones, computers, etc devices, from being watched/viewed/modified by outsiders or unwanted person or unwanted software/script/bot, and Encryption can also protect your files while in transit via Internet from one user or you, to another (destination) user, when you are sending it via emails or other file-sharing medium.
As devices are connected with Internet most of the time, Encryption can also protect files from being modified or watched/viewed by unwanted person with backdoor access into your devices, and can also protect files from being modified/watched/viewed by unwanted software script/bot, which are pre-programmed to call or connect with remote-server or remote developer's computers, without your awareness, running as a background software or service.
quoting: "We Now Live In A Nation Where Doctors Destroy Health, Lawyers Destroy Justice, Universities Destroy Knowledge, Governments Destroy Freedom, The Press Destroys Information, Religion Destroys Morals, And Our Banks Destroy The Economy." - by Chris Hedges.
Though filename is visible (after general encryption), but content of file can be kept completely hidden from unwanted viewers. If directory structure inside the archive/zip/7zip file is also encrypted, then filename will also be hidden from unwanted viewers, after encryption.
When longer length password is used, and when such password has combination of random alphabets, numbers, symbols, etc, and when very strong encryption ciphers & algorithms are used for encryption, then breaking such encryption-protected file would take very very very very long time, when less powerful computer-systems will be used for file decryption.
When you want to send any picture-files, video-files, document-files, ROM-files, software-files, etc to another (destination) user, then always compress+encrypt first before sending out. If pictures, videos, documents, ROMs, software, etc are attached in email & sent WITHOUT ENCRYPTING, then anyone else (like, gateway & router computers) in transit and any people (or any software or any script or any bot) with access to email-servers, gateway-computers, and anyone who has access to your email-client (email receiving & sending) software in your side, is able to VIEW such pictures, videos, documents, ROMs, software-files, etc because by-default emails are OPEN, it means, they are NOT-ENCRYPTED, it means, they are very easily view-able by anyone, it also means, those files are NOT-PRIVATE & NOT-PERSONAL ANYMORE. And not-private or not-personal items (without-encryption) may be considered as OPEN & PUBLIC items on various situations, when it has traveled thru OPEN (means, non-encrypted) internet. So email attachment encryption, is extremely necessary step, when you want to share private files, or when your files contain private or personal or non-public information.
If you need to send 20 original files to a destination user, safely & securely, then (for example), you will need total of 10 emails, with each email having two attachment files, to send those all original files to the destination user, if you encrypt each of those 20 files individually. But one of the better alternative is to do such as this: Combine & compress & encrypt (by using above mentioned software tools) all of those 20 files into a set of compressed SPLIT pieces of files, let's say for example, 20 files are converted into 4 split 7z (7zip) files, with split piece size is set onto 9999000 bytes or 9.99 MBytes, then in such case you would need only 2 emails, and each email would need two attachments of 7z files, for combindly sending all of those 20 original files.
A Zip or Compression type of software tools with encryption support, should allow any user to combine all pictures, videos, documents, ROMs, software, etc inside one SINGLE compressed & encrypted large sized FILE, then such single compressed (and encrypted) file can be uploaded into a file-sharing website, and then file-sharing website's specific URL (for your uploaded file), can be shared with your destination user, so that destination user can download it in his/her side.
And some Compression tools will also allow you to compress & split the target compressed file into multiple pieces, so that each split pieces can be attached with multiple emails, or when you need to split files because file-sharing websites have some restriction on upload file's size. Most email-service providers also usually do not allow usage of email attachments of a file which has file-size of over 10 or 20 MegaBytes. So we need to combine all of our picture, video, document, ROM or software files (which we want to send to the destination user), and turn those all files into a set of multiple compressed-file pieces, where each compressed-file piece size must need be 10 or 20 MegaBytes or below, to efficiently use email service.
And to increase Security & Safety level of your compressed & encrypted single file or a set of split-files, you should share such file's password over a different communication medium, and you MUST OBSCURE the PASSWORD secret word or sentence. Which means, do not type-out & send the actual password directly as a single word. Instead use a puzzle or few wrong-characters inside the password, and instruct your destination user to use his/her human-brain to do something 1st on the shown wrong-password, to obtain the actual password. And you MUST also INCLUDE the HASH/CHECKSUM code of compressed (and encrypted) single file, or include hash/checksum of the 1st file of the compressed set of split-files, after or with the password.
For example, if the actual password was "pass1word2", then do not send out password directly as "pass1word2" ! to your destination user. Instead send this, (for example) "pass3word9", and then write some instruction such as these inside brace symbols or inside some other symbols, after the wrong-password: (change 3 into 5-four, change 9 into four-2), or like this: (change 3 into this number: # of nose in human, change 9 into: 4 - # of eyes in human), or like this (change the "3" into this number: my position in highschool game, change 9 into a number: my son's day of birth).
If you have chosen to send compressed files over email, let's say for example: gmail (Google Email), then send password+hash over a DIFFERENT MEDIUM, like, via IM (instant messaging) software of a different email-service provider, like YIM (Yahoo IM), or MSN-IM (Microsoft IM), or SMS, or Apple Messenger, etc.
And configure & enable your IM software to use END-TO-END ENCRYPTION (E2EE) feature/support, it may also be known as OTR (Off The Record) feature. If you are not using or unable to use strong END-TO-END encryption, and if you still send password with such deficiencies, then your password is visible & available to unwanted person & unwanted software, because most IM systems are using (middle-man) servers to store your messages & to route messages from one user to another user. Connecting with a remote IM server computers over TLS or SSL encrypted connection without using any E2E/OTR does not make your conversation Private or Personal or secure, between you & destination user. Only when very strong End-to-End encryption system is used, then you & destination user's conversation is really Private & Personal & secure, for longer amount of time duration, if less powerful computers are used for IM message IP-packet decryption.
When mentioned type of obscuring process and when Distribute Different Portions in Different Medium (DDPDM) process are used, then it makes bulk or mass-surveillance type of data-collection related illegal jobs and constitutional-rights violating jobs, "comparatively" slightly more harder, for data-harvesters or data-miners or data-spy or data-thief, etc violators. Please do not make things easy for those who violate laws & rules, created by majority of people with majority of people's votes, and do not make it easy for those who disrespect your Privacy-Rights, Civil-Rights, etc, and do not make it easy for those who do activities behind closed-door, without any accountability from majority of public. These type of violators & violator groups & violator INDUSTRIES (and their family and their supporters) are ADDICTED to the POWER and derived benefits & PROFITS, and these violators are addicted to the JOB OF ABUSING other people's Human Rights & Civil Rights, these violators would DO ANYTHING & say anything to keep these abusive POWERS & their JOBS within their domain as abusive tool-sets/tools, including creating their own-terror events or manufacture their own INSIDER-JOB operations, and then violator-groups systematically place blame of terror-events on others & minorities, to create FEAR/DOUBT/HATE among IGNORANT people AND to influence & generate SUPPORT & FUND for even further-more abusive HUMAN-RIGHTS violating tool-sets & jobs, these violators have thousands of vendors & contractors (from local & foreign nations) in their group who are manufacturing & supplying & profiting from different components (and parts) for abusive toolsets, and acquiring+bribing (aka, funding) law-makers (aka, public-servants) into their pocket or turning them as their mouth-piece or assisting each-others through REVOLVING-CHAIR mechanisms, and these violators will not disclose to general public: how these VIOLATOR INDUSTRIES & GROUPS are really collaborating & really abusing these abusive tool-sets in mass-scale. Those are the processes how these type of violator-groups live & run their life generation after generation, and how they carry-out their life-style. And those are the real actions what they really do or act in their life, and they say something-else in public with their mouth.
List of software which allows END-TO-END Encryption: * Email related: PGP/GPG & S/MIME supported email client software:
items will be added here later.
* IM (Instant Messaging) related: OTR or E2E supported IM client software:
Adium (for Mac OSX),
Pidgin (for Windows OS),
iMessage (for iOS/iPhone/iPad, it's pre-included),
Signal by Whisper Systems: Signal Private Messenger for Android, CyanogenMod, Replicant, etc, Signal - Private messenger for iOS/iPhone/iPad, unfortunately "Signal Private Messenger" app on both Android/CM & iOS/iPhone/iPad, uses massive amounts of Un-Necessary system Permissions & Accesses, so my suggestion is "avoid-it", when other respectful software or tools are not found. Or use it when devs will release a "lite" edition which does not access any un-necessary system Permissions & Accesses,
Miranda-NG (for Windows OS, get OTR plugin from Addons),
ChatSecure by Guardian Project is slightly better than "Signal", but it also needs to reduce un-necessary system Permissions & Accesses: ChatSecure for Android/CM/Replicant, ChatSecure for iOS/iPhone/iPad.
* Cloud storage related: Tresorit, MEGA, SpiderOak.
* IP-Telephony related: ZRTP or FaceTime. IP-Radio related: TETRA.
Choose only such apps, which will use only the necessary Permissions & Accesses, for your required specific functionalities and nothing more than that. Also avoid apps, that packs way too many features and start to use too many extra Permissions & Accesses when simple functions are configured & expected. There are some system apps which can be configured to disable some Permissions & Accesses of other apps, which use too much un-necessary Permissions & Accesses, but usually such system apps requires a rooted phone to disable Permissions. Also 1st try to use NoRoot based firewall in your device which uses built-in VPN-service to limit unnecessary outbound & inbound internet connections, if such is not suffice or not enough to control bad (internet) behavior of bad Apps, with access to unnecessary system Permissions & unnecessary remote connections, then use stronger firewall which requires rooted phone, and can change (android "iptables") firewall rules or filtering rules, for all internet packets.
Some communication (or data-transfer) mediums or communication channels are heavily monitored & heavily stored (means, all messages are recorded for un-disclosed amount of time period), "comparatively" more than some other mediums/channels, and ofcourse such major (Privacy-Right is 4TH amendment in constitution of USA) Right violating activities are illegal because these illegal activities are carried out without the voted consensus from majority of public. Majority of people would never vote to allow such illegal & immoral activities. So try to avoid using such heavily monitored and heavily recorded communication mediums/channels, (for sharing password), unless you (and destination user) are using very very strong (End-to-End) E2E / OTR encryption, or you are distributing different portions in different medium (DDPDM). For example, avoid using Non-E2E open & plain SMS/Text message via wireless carriers, or avoid using Non-E2E open & plain SMS/Text message via VoIP or IP-telephony companies, (example providers are: Google Voice, etc), for sharing any password for main-files. Here, IP means, Internet Protocol.
I'm not including list of file-sharing websites, for now. But website which can be accessed over https://... connection, is obviously better than websites with only http://... connection. When password+hash is shared or given over a secure & end-to-end (E2E) or OTR encrypted IM message, or when given over PGP or GPG encrypted-only email, then it does not matter weather a file-sharing website is using https or not. But https is always better than a http based website.
REFERENCES:
* wikipedia.org/wiki/End-to-end_encryption (E2E).
* wikipedia.org/wiki/Off-the-Record_Messaging (OTR).
* wikipedia.org/wiki/Comparison_of_instant_messaging_clients & Secure Messengers
Note: i have copied various info & portion of paragraphs, on this post & in my other posts, from various other websites & authors, with their permissions obtained.
Display Checksum Code In 1st Post, Hash Calculating, Un/-Zip, Encrypt, GPG, OTR, E2E
reserved this 8th post here.
added content in 7th post.