[General Topics] atErik:
[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,

nu

dity

) 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.