[INFO] How digital signatures work

[INFO] How digital signatures work - Security Discussion

I remember that when I used to frequent these forums a year or two ago, there were often times when people would ask why we couldn't use the signing key to get bootloaders or devices to accept arbitrary code. Presumably, the more experienced here understand digital signatures, but maybe not the specific math behind them. This is intended to be a short informational guide on how these work.
Symmetric-key cryptography
The most ubiquitous form of encryption involves keys that are the same for encryption and decryption. This has existed since cryptography first became a thing. Historically, the plebeians of a given polity were illiterate. Only a small portion of society was capable of reading and writing. This is how the Roman Catholic Church held something of a monopoly on the Bible—which was written in Latin, by the way—until printing press lead to increased literacy.
All the people who know a particular key can encrypt and decrypt messages equally. This requires tedious amounts of work to keep the key secret (ergo, "secret key cryptography"). If secret keys are ever implemented on hardware, they must be stored in such a way that attempting to probe for it would simultaneously destroy it. The first iPhone, which lacked hardware-based verification of the bootloader, encrypted the first stage bootloader. If you didn't have the correct key, any code you placed there would decrypt to gibberish (it could presumably still run because it offered no authentication or integrity protection, but the chances of this happening were unlikely). Now, with a MAC algorithm, a tag could be attached for verification purposes, but this would still require having the key burned into the mask ROM.
Asymmetric-key cryptography
Asymmetric cryptography emerged in the 1970s with the Diffie-Hellman protocol—which admittedly wasn't a cryptosystem, but a key agreement protocol—and RSA. RSA is the most widely used public key cryptosystem, but there are others, most being variants on the difficulty of integer factorization or discrete logarithms (i.e., Paillier, Rabin, ElGamal, ECC, DSA, etc.), but there are more exotic ones based on lattices (NTRUEncrypt and NTRUSign), linear codes (McEliece), polynomials (HFE and multivariate cryptography), and hashes (Lamport signatures). There is a public key and private key (sometimes the which is key is which doesn't matter). Crypographic operations with the public key are one way. You can encrypt a message using my public key, but I'm the only who can decrypt it since I generated the key pair.
RSA, the most popular, operates on the fact that with a given exponent and a modulus of secret factorization. An example:
p=41 (prime number)
q=43 (prime number)
N=p*q=1763
e=11 (public exponent)To calculate the private exponent, I must find the number (d) that satisfies e*d mod ((p-1)*(q-1))=1. This number is called a modular multiplicative inverse and it is easy to determine when one knows the factors or N. In this case, d=611. Let's say you want to send me m=10. The ciphertext is c=m^e mod N=10^11 mod 1763=789. To get the message, I only need to calculate swap out my public exponent for my private exponent, giving m=c^d mod N=789^611 mod 1763=10.
These operations can also go the other way, allowing me to "sign" hashes of messages.
Digital signatures
Unlike encryption, signing a message goes the other way and involves using the private key to create a number that can be verified with the public key. With RSA, you just need to do what I did above in reverse. On devices with hardware-based or software-based verifications of code, all that is needed is the public key associated with the identity that is authorized to create runnable code. In a lot of cases, it is burned into the mask ROM of an SoC, allowing no way to change the change anything without some serious molecular rearrangement. If it's in the software, then all you have to do is edit the code that performs the signature check. Seeing as most companies are not stupid, however, this often impossible because that software is verified by a previous stage, with the verification going all the way down to the hardware level.
In the case of UEFI secure boot, the UEFI firmware (which can usually be changed), has a database of public keys that it uses to verify the "first stage" bootloader (in quotes because it's really not the first stage). I don't know if the UEFI firmware is also checked by a previous mechanism, but if it is, it's done in a way that's dissimilar to how ARM-based devices do it.
Questions, comments, concerns? I'm here all day.

Related

HOWTO generate self-signed certificates to sign apk's and zips

This was taken from: openssl.org/docs/HOWTO/certificates.txt
1. Introduction
How you handle certificates depend a great deal on what your role is.
Your role can be one or several of:
- User of some client software
- User of some server software
- Certificate authority
This file is for users who wish to get a certificate of their own.
Certificate authorities should read ca.txt.
In all the cases shown below, the standard configuration file, as
compiled into openssl, will be used. You may find it in /etc/,
/usr/local/ssl/ or somewhere else. The name is openssl.cnf, and
is better described in another HOWTO <config.txt?>. If you want to
use a different configuration file, use the argument '-config {file}'
with the command shown below.
2. Relationship with keys
Certificates are related to public key cryptography by containing a
public key. To be useful, there must be a corresponding private key
somewhere. With OpenSSL, public keys are easily derived from private
keys, so before you create a certificate or a certificate request, you
need to create a private key.
Private keys are generated with 'openssl genrsa' if you want a RSA
private key, or 'openssl gendsa' if you want a DSA private key.
Further information on how to create private keys can be found in
another HOWTO <keys.txt?>. The rest of this text assumes you have
a private key in the file privkey.pem.
3. Creating a certificate request
To create a certificate, you need to start with a certificate
request (or, as some certificate authorities like to put
it, "certificate signing request", since that's exactly what they do,
they sign it and give you the result back, thus making it authentic
according to their policies). A certificate request can then be sent
to a certificate authority to get it signed into a certificate, or if
you have your own certificate authority, you may sign it yourself, or
if you need a self-signed certificate (because you just want a test
certificate or because you are setting up your own CA).
The certificate request is created like this:
openssl req -new -key privkey.pem -out cert.csr
Now, cert.csr can be sent to the certificate authority, if they can
handle files in PEM format. If not, use the extra argument '-outform'
followed by the keyword for the format to use (see another HOWTO
<formats.txt?>). In some cases, that isn't sufficient and you will
have to be more creative.
When the certificate authority has then done the checks the need to
do (and probably gotten payment from you), they will hand over your
new certificate to you.
Section 5 will tell you more on how to handle the certificate you
received.
4. Creating a self-signed test certificate
If you don't want to deal with another certificate authority, or just
want to create a test certificate for yourself. This is similar to
creating a certificate request, but creates a certificate instead of
a certificate request. This is NOT the recommended way to create a
CA certificate, see ca.txt.
openssl req -new -x509 -key privkey.pem -out cacert.pem -days 1095
5. What to do with the certificate
If you created everything yourself, or if the certificate authority
was kind enough, your certificate is a raw DER thing in PEM format.
Your key most definitely is if you have followed the examples above.
However, some (most?) certificate authorities will encode them with
things like PKCS7 or PKCS12, or something else. Depending on your
applications, this may be perfectly OK, it all depends on what they
know how to decode. If not, There are a number of OpenSSL tools to
convert between some (most?) formats.
So, depending on your application, you may have to convert your
certificate and your key to various formats, most often also putting
them together into one file. The ways to do this is described in
another HOWTO <formats.txt?>, I will just mention the simplest case.
In the case of a raw DER thing in PEM format, and assuming that's all
right for yor applications, simply concatenating the certificate and
the key into a new file and using that one should be enough. With
some applications, you don't even have to do that.
By now, you have your cetificate and your private key and can start
using the software that depend on it.
--
Richard Levitte

Android and Oracle?

Just wondered what is the long term future for the Java-ish language on android given the current case. I wrote a bit of part satire, part idea at the following address.
http://my.opera.com/jackokring/blog/java-oracle-android-and-google
Does anyone else recognize the immense opportunity opening for a new language across the mobile market for a new syntax, and rationalized smaller library?

More on supa
Apart from the following alterations to the base language and the ones proposed earlier, I'd like some feedback on what should go into the libraries...
I'd also remove short, char and byte as types, and have a PackedArray class for such needs. To muddy the base type system with anything less than an int maybe is an obscure homage to history. I'd then be left with just int and long and object pointer and void.
Any other types would be library based. For example String.
The scoping rules being strict relates to SMP. For recursive functions, the extra need to pass some extra parameters, to get extra locals is not a bad idea, as it forces an understanding that automatic synchronization, would already enforce. And would lead to simpler recursive functions using the instance variables as type 'static in the c function sense' for data pass back to the single writer previous recursion instance.
Now if your thinking how would the usual ijk for loop variables be defined within multiple methods, and not generate a 'multiple writer method error' this is just syntax, and forcing actually descriptive variable names is surely a good thing. The fact that the data segment would grow in size, as the method instance variable set grew would be more of an issue. But then again, I never suggested removing the word 'transient'. After all if a stack frame local is not transient then what is? The word volatile also becomes redundant, as all class variables are volatile.
The keyword strictfp is also useless in supa.

Trident Encoder : Encryption for Windows RT

I implemented a browser based encryption solution which runs on Windows RT (and many other Windows computers). All I wrote was the HTML page, I am leveraging Crypto.JS javascript library for encryption algorithm. I am using the HTML 5 File API implementation which Microsoft provides for reading and writing files.
I make no claim on this but seems to work good for me. Feel free to feedback if you have any suggestions. The crypto.js library supports many different algorithms and configuration so feel free to modify it to your own purposes.
You can download the zip file to your surface, extract it and load the TridentEncode.htm file into Internet Explorer.
If you want to save to custom directory you probably need to load it from the Desktop IE instead of metro IE (to get the file save dialog). I usually drag and drop the file onto desktop IE and from there I can make favorite. This should work in all IE 11 and probably IE 10 browsers... if you use other browsers you may need to copy paste into the fields since the File API implementation seems rather browser specific. Running the html page from the local filesystem means that there is no man-in-the-middle which helps eliminate some of the vulnerabilities of using a javascript crypto implementation. You could also copy the attached zip file to your skydrive to decrypt your files from other computers.
Skydrive files in theory are secure (unless they are shared to public) so this might be useful for adding another layer of protection to certain info.
Again, use at your own risk, but feel free to play around and test it, and offer any suggestions or critiques of its soundness, or just use it as a template for your own apps.

Ok... this is really cool! Nice idea, and a good first implementation.
With that said, I have a few comments (from a security perspective). As an aside, minimized JS is the devil and should be annihilated with extreme prejudice (where not actually being used in a bandwidth-sensitive context). Reviewing this thing took way too long...
1) Your random number generation is extremely weak. Math.random() in JS (or any other language I'm aware of, for that matter) is not suitable for use in cryptographic operations. I recommend reading http://stackoverflow.com/questions/4083204/secure-random-numbers-in-javascript for suggestions. The answer by user ZeroG (bottom one, with three votes, as of this writing) gets my recommendation. Unfortunately, the only really good options require IE11 (or a recent, non-IE browser) so RT8.0 users are SOL.
NOTE: For the particular case in question here (where the only place I can see that random numbers are needed is the salt for the key derivation), a weak PRNG is not a critical failing so long as the attacker does not know, before the attack, what time the function is called at. If they do know, they can pre-compute the likely keys and possibly succeed in a dictionary attack faster than if they were able to generate every key only after accessing the encrypted file.
2) Similarly, I really recommend not using a third-party crypto lib, if possible; window.crypto (or window.msCrypto, for IE11) will provide operations that are both faster and *much* better reviewed. In theory, using a JS library means anybody who wants to can review the code; in practice, the vast majority of people are unqualified to either write or review crypto implementations, and it's very easy for weaknesses to creep in through subtle errors.
3) The default key derivation function (as used for CryptoJS.AES.encrypt({string}, {string})) is a single iteration of MD5 with a 64-bit salt. This is very fast, but that is actually a downside here; an attacker can extremely quickly derive different keys to attempt a dictionary attack (a type of brute-force attack where commonly used passwords are attempted; in practice, people choose fairly predictable passwords so such attacks often succeed quickly). Dictionary attacks can be made vastly more difficult if the key derivation process is made more computationally expensive. While this may not matter so much for large files (where the time to perform the decryption will dominate the total time required for the attack), it could matter very much for small ones. The typical approach here is to use a function such as PBKDF2 (Password-Based Key Derivation Function) with a large number of iterations (in native code, values of 20000-50000 are not uncommon; tune this value to avoid an undesirably long delay) although other "slow" KDFs exist.
4) There's no mechanism in place to determine whether or not the file was tampered with. It is often possible to modify encrypted data, without knowing the exact contents, in such a way that the data decrypts "successfully" but to the wrong output. In some cases, an attacker can even control enough of the output to achieve some goal, such as compromising a program that parses the file. While the use of PKCS7 padding usually makes naïve tampering detectable (because the padding bytes will be incorrect), it is not a safe guarantee. For example, a message of 7 bytes (or 15 or 23 or 31 or any other multiple of 8 + 7) will have only 1 byte of padding; thus there is about a 0.4% (1 / 256) chance that even a random change to the ciphertext will produce a valid padding. To combat this, use an HMAC (Hash-based Message Authentication Code) and verify it before attempting decryption. Without knowing the key, the attacker will be unable to correct the HMAC after modifying the ciphertext. See http://en.wikipedia.org/wiki/HMAC
5) The same problem as 4, but from a different angle: there's no way to be sure that the correct key was entered. In the case of an incorrect key, the plaintext will almost certainly be wrong... but it is possible that the padding byte(s) will be correct anyhow. With a binary file, it may not be possible to distinguish a correct decryption from an incorrect one. The solution (an HMAC) is the same, as the odds of an HMAC collision (especially if a good hash function is used) are infinitesimal.
6) Passwords are relatively weak and often easily guessed. Keyfiles (binary keys generated from cryptographically strong random number generators and stored in a file - possibly on a flashdrive - rather than in your head) are more secure, assuming you can generate them. It is even possible to encrypt the keyfile itself with a password, which is a form of two-factor authentication: to decrypt the data that an attacker wants to get at, they need the keyfile (a thing you have) and its password (a thing you know). Adding support for loading and using keyfiles, and possibly generating them too, would be a good feature.
The solutions to 3-5 will break backward compatibility, and will also break compatibility with the default parameters for openssl's "enc" operation. This is not a bad thing; backward compatibility can be maintained by either keeping the old version around or adding a decrypt-version selector, and openssl's defaults for many things are bad (it is possible, and wise, to override the defaults with more secure options). For forward compatibility, some version metadata could be prepended to the ciphertext (or appended to the file name, perhaps as an additional extension) to allow you to make changes in the future, and allow the encryption software to select the correct algorithms and parameters for a given file automatically.

Wow thanks GDTD that's great feedback
Not sure about his minified sources, the unminified aes.js in components is smaller than the minified version (which I am using) in rollups. I'll have to look into what his process for 'rollup' is to see if I can derive a functional set of non-minified script includes. If I can do that it would be easier to replace (what I would guess is) his reliance on Math.random.
His source here mirrors the unminified files in components folder : https://code.google.com/p/crypto-js/source/browse/tags/3.1.2/src
msCrypto that would be great, I had no idea that was in there. I found a few (Microsoft) samples so I will have to test them out and see if I can completely substitute that for crypto.js. Would be more keeping in line with the name I came up with.
Currently this version only works for text files, I am using the FileAPI method reader.readAsText(). I have been trying to devise a solution for binary files utilizing reader.readAsArrayBuffer but as yet I haven't been able to convert or pass this to crypto.js. I will need to experiment more with base64 or other interim buffer formats (which Crypto.js or msCrypto can work with) until I can get a better understanding of it.
Metadata is a great idea, maybe i can accommodate that with a hex encoded interim format.
You seem extremely knowledgeable in the area of encryption, hopefully i can refine the approach to address some of the issues you raised by setting up proper key, salt, and IV configuration... I'm sure I will understand more of your post as i progress (and after reading it about 20 times more as a reference).
Too bad we don't a web server for RT, that would at least open up localStorage for json serialization (mostly for other apps I had in mind). I guess they might not allow that in app store though. Could probably run one of a developers license though (renewed every 1-2 months)?

nazoraios said:
Too bad we don't a web server for RT, that would at least open up localStorage for json serialization (mostly for other apps I had in mind). I guess they might not allow that in app store though. Could probably run one of a developers license though (renewed every 1-2 months)?
Click to expand...
Click to collapse
I cant comment too much on the encryption, GoodDayToDie has covered anything I could contribute and more. But there is a functioning web server on RT. Apache 2.0 was ported: http://forum.xda-developers.com/showthread.php?t=2408106 I dont know if everything is working on it, I dont own an RT device and last time I tried I couldnt get apache to run on 64 bit windows 8 anyway (needed it at uni, spent hours going through troubleshooting guides and it never worked on my laptop, gave up and ran it under linux in virtualbox where it took 2 minutes to have functioning the way I needed it to).

Curious about the performance. Speaking of encryption, 7-Zip has it built-in, and from the discuss in StackExchange, it seems pretty good.

One of the neat things about this thing (local web app? Pseudo-HTA (HTml Application)? Not sure if there's a proper name for such things) is that it runs just fine even on non-jailbroken devices. That's a significant advantage, at least for now.
Running a web server should be easy enough. I wrote one for WP8 (which has a subset of the allowed APIs for WinRT) and while the app *I* use it in won't be allowed in the store, other developers have taken the HTTP server component (I open-sourced it) and packaged it in other apps which have been allowed just fine. With that said, there are of course already file crypto utilities in the store anyhow... but they're "Modern" apps so you might want to develop such a server anyhow so you can use it from a desktop web browser instead.
Web cryptography (window.crypto / window.msCrypto) is brand new; it's not even close to standardization yet. I'm actually kind of shocked MS implemented it already, even if they put it in a different name. It's pretty great, though; for a long time, things like secure random numbers have required plugins (Flash/Java/Silverlight/whatever). Still, bear in mind that (as it's still far from standardized), the API might change over time.

Yep, I think of them as Trident apps since trident is what Microsoft calls their IE rendering engine, but I guess they are sort of offline web apps (which come from null domain). Being from null domain you are not allowed to use localstorage which is domain specific. You also are not allowed to make ajax requests. You just have file api and json object serialization to make do with I/O.
Another app I am working on is a kind of Fiddler app similar to http://jsfiddle.net/ where you can sandbox some simple script programs.
Kind of turning an RT device into a modern/retro version of a commodore 64 or other on-device development environments. Instead of basic interpreter you've got your html markup and script.
I have an attached demo version which makes available jquery, jquery-ui, alertify javascript libraries in a sandbox environment that you can save as .prg files.
I put a few sample programs in the samples subfolder. Some of the animation samples (like solar system) set up timers which may persist even after cleared so you might need to reload the page to clear those.
It takes a while to extract (lots of little files for all the libraries) but once it extracts you can run the html page and I included a sample program 'Demo Fiddle.prg' you can load and run to get an idea.
I added syntax highlighting editors (EditArea) which seems to work ok and let's you zoom each editor full screen.
The idea would be to take the best third party javascript libraries and make them available and even make shortcuts or minimal API for making it easier to use them. Common global variable, global helper methods, ide manipulation. I'd like to include jqplot for charting graphs, maybe for mathematical programs and provide api for user to do their own I/O within the environment.
These are just rough initial demos, and obviously open source so if anyone wants to take the ideas and run with them i'd be interested in seeing what others do. Otherwise I will slowly evolve the demos and release when there are significant changes.

Figuring out Samsung Accesory Protocol internals

Hello,
I want to figure out the Samsung Accesory Protocol in order to create a "open source" Gear Manager app replacement. This thread is to ask if anyone has been trying to do the same thing as well as try to gather as much information about this protocol as possible. Generic discussion is also accepted, in case anyone has better ideas.
Right now all I know is that this protocol is based on RFCOMM, albeit it can be transported over TCP too. It has a level 1 "framing" which consists basically on
Code:
packed struct Frame {
uint16_be length_of_data;
char data[length_of_data];
}
packed struct FrameWithCRC {
uint16_be length_of_data;
uint16_be crc_of_length;
char data[length_of_data];
uint16_be crc_of_data;
}
I also know that there are various types of packets. "Hello" packets are exchanged early during the connection and contain the product name, etc. Authentication packets are exchanged right after the initial "hello" and contain some varying hashes (crypto warning!). Then the normal data packets are "multiplexed", as in usbmuxd: they have 'session' IDs which described towards which watch program they are talking with. All Hello and authentication packets are sent without CRC, but normal data packets are. The CRC implementation used is crc16, same poly as in the linux kernel.
I suspect that whatever we uncover about this protocol might be useful to e.g. pair Gear with an iPhone, with a PC, things like that.
Note: most of this comes from viewing Bluetooth logs. However it's clear that reverse engineering will be required for the cryptographic parts. In this case I believe it's legally OK to do so in the EU because it's purely for interoperability reasons. I don't want to create a competitor to the Gear2, I just want to talk to it.
Motivation: I bought a Gear2 in order to replace a LiveView that was dying (buttons wearing out, broken wriststrap clips, etc.) . I used it both for notifications as well as map/navigation.
Since I have a Jolla, no programs are available to pair with most smartwatches, but I've been developing my own so far (MetaWatch, LiveView). Thus I decided on a replacement based purely on hardware characteristics and price. Also Tizen seems more open than Android, thus I figured out it would be easier for me to adapt to the watch.
However it seems that I understimated the complexity of the protocol that connects the Gear with the GearManager. So my options in order to make use of this watch are:
Sell Gear2 back and buy something that's easier to hack (e.g. another LiveView ),
Figure out the SAP protocol and write a replacement Gear Manager app (what this thread is about),
Write replacement Tizen applications that don't use SAP. This involves writing new programs for Calls, Messages, Notifications, Alarms, Camera, watchOn, Pulse monitor, etc. i.e. a _lot_ of work if I want to exploit all features of the watch.
But at least one can reuse the existing Tizen settings app, launcher, drivers, etc. (I started porting Qt to the Gear2 with this idea)
Use a different Linux distro on the Gear 2. Such as Sailfish, Mer, etc. This involves all the work of option 3 + possibly driver work.
As of now I've not decided which option is easier for me so I'll keep trying to push them all.

javispedro said:
Hello,
I want to figure out the Samsung Accesory Protocol in order to create a "open source" Gear Manager app replacement. This thread is to ask if anyone has been trying to do the same thing as well as try to gather as much information about this protocol as possible. Generic discussion is also accepted, in case anyone has better ideas.
Right now all I know is that this protocol is based on RFCOMM, albeit it can be transported over TCP too. It has a level 1 "framing" which consists basically on
Code:
packed struct Frame {
uint16_be length_of_data;
char data[length_of_data];
}
packed struct FrameWithCRC {
uint16_be length_of_data;
uint16_be crc_of_length;
char data[length_of_data];
uint16_be crc_of_data;
}
I also know that there are various types of packets. "Hello" packets are exchanged early during the connection and contain the product name, etc. Authentication packets are exchanged right after the initial "hello" and contain some varying hashes (crypto warning!). Then the normal data packets are "multiplexed", as in usbmuxd: they have 'session' IDs which described towards which watch program they are talking with. All Hello and authentication packets are sent without CRC, but normal data packets are. The CRC implementation used is crc16, same poly as in the linux kernel.
I suspect that whatever we uncover about this protocol might be useful to e.g. pair Gear with an iPhone, with a PC, things like that.
Note: most of this comes from viewing Bluetooth logs. However it's clear that reverse engineering will be required for the cryptographic parts. In this case I believe it's legally OK to do so in the EU because it's purely for interoperability reasons. I don't want to create a competitor to the Gear2, I just want to talk to it.
Motivation: I bought a Gear2 in order to replace a LiveView that was dying (buttons wearing out, broken wriststrap clips, etc.) . I used it both for notifications as well as map/navigation.
Since I have a Jolla, no programs are available to pair with most smartwatches, but I've been developing my own so far (MetaWatch, LiveView). Thus I decided on a replacement based purely on hardware characteristics and price. Also Tizen seems more open than Android, thus I figured out it would be easier for me to adapt to the watch.
However it seems that I understimated the complexity of the protocol that connects the Gear with the GearManager. So my options in order to make use of this watch are:
Sell Gear2 back and buy something that's easier to hack (e.g. another LiveView ),
Figure out the SAP protocol and write a replacement Gear Manager app (what this thread is about),
Write replacement Tizen applications that don't use SAP. This involves writing new programs for Calls, Messages, Notifications, Alarms, Camera, watchOn, Pulse monitor, etc. i.e. a _lot_ of work if I want to exploit all features of the watch.
But at least one can reuse the existing Tizen settings app, launcher, drivers, etc. (I started porting Qt to the Gear2 with this idea)
Use a different Linux distro on the Gear 2. Such as Sailfish, Mer, etc. This involves all the work of option 3 + possibly driver work.
As of now I've not decided which option is easier for me so I'll keep trying to push them all.
Click to expand...
Click to collapse
I think your thread should probably go in the Dev section for Tizen. Have you made any development? If your want it moved, report your own post with the button in top right labeled report. You can then suggest your thread be moved to the new Tizen Development section. Ok, I wish you all the luck, you seem to be very talented programmer/dev. Thanks for your contributions.
Chris

noellenchris said:
I think your thread should probably go in the Dev section for Tizen.
Click to expand...
Click to collapse
Well, some mod already moved this thread from Development, where I originally posted it, into Q&A. This is not exactly "Tizen" development (SAP is used in may Samsung devices seemingly).
noellenchris said:
Have you made any development?
Click to expand...
Click to collapse
Yes, lots of progress. I have been able to write a program that connects to the Gear2 from my PC, succesfully "completes" the setup program and synchronizes the date&time. Things like changing the background color etc. are now trivial. I will soon port it to my Jolla.
I am now looking into how to send notifications to the watch. I've not been able to get Gear Manager to actually send any notifications (to use as "reference"), because goproviders crashes when I try to simulate notifications on my android_x86 VM
If anyone can send me an HCI / Bluetooth packet capture of their Android device while it is sending notifications to the Gear2 I would really appreciate it.
Unfortunately, the main problem here is that Samsung uses some cryptographic authentication as a form of "DRM". I am not exactly sure why.
There was no way for me to discover how the crypto worked so I took the unclean approach and dissasembled their crypto code (libwms.so). That means there's no way I would be able to distribute the code now without risking a lawsuit from Samsung.
Sadly this means that while I can distribute the protocol specifications I obtained, legally distributing "Gear Manager replacements" is probably impossible.

javispedro said:
Well, some mod already moved this thread from Development, where I originally posted it, into Q&A. This is not exactly "Tizen" development (SAP is used in may Samsung devices seemingly).
Click to expand...
Click to collapse
Ya, I was kinda in a Gear 1 mind set, and they have separate threads for Android and Tizen....
Chris

javispedro said:
Unfortunately, the main problem here is that Samsung uses some cryptographic authentication as a form of "DRM". I am not exactly sure why.
There was no way for me to discover how the crypto worked so I took the unclean approach and dissasembled their crypto code (libwms.so). That means there's no way I would be able to distribute the code now without risking a lawsuit from Samsung.
Sadly this means that while I can distribute the protocol specifications I obtained, legally distributing "Gear Manager replacements" is probably impossible.
Click to expand...
Click to collapse
I would gladly write a MIT-licensed C library implementing your protocol specifications. That would be correctly following the chinese-wall approach to reverse-engineering, right?
Anyway, AFAIK, being in Europe decompiling for interoperability purposes is allowed -- I know that wikipedia is not to be taken at face value, but: en.wikipedia.org/wiki/Reverse_engineering#European_Union

Antartica said:
I would gladly write a MIT-licensed C library implementing your protocol specifications. That would be correctly following the chinese-wall approach to reverse-engineering, right?
Anyway, AFAIK, being in Europe decompiling for interoperability purposes is allowed -- I know that wikipedia is not to be taken at face value, but: en.wikipedia.org/wiki/Reverse_engineering#European_Union
Click to expand...
Click to collapse
Well, the problem is not the protocol specifications per se, which I'm actually quite confident I'd be able to redistribute (I'm in EU). The problem is the cryptography part, which is basically ripped off from the Samsung lib "libwsm.so" . Unless we can find out what cryptographic method that lib uses, distributing alternate implementations Is a no-go.

javispedro said:
Well, the problem is not the protocol specifications per se, which I'm actually quite confident I'd be able to redistribute (I'm in EU). The problem is the cryptography part, which is basically ripped off from the Samsung lib "libwsm.so" . Unless we can find out what cryptographic method that lib uses, distributing alternate implementations Is a no-go.
Click to expand...
Click to collapse
If you have the time, I don't mind researching the possible crypto used (although I've only studied DES/3DES, AES and Serpent, hope that whatever scheme used is not very different from them).
Some ideas to start from somewhere:
1. As you have used its functions, it is a block cipher? I will assume that it is.
2. What is the key size and the block size?
3. Are there signs that it is using a stack of ciphers? (that is, applying one cipher, then another to the first result and so on)

Antartica said:
If you have the time, I don't mind researching the possible crypto used (although I've only studied DES/3DES, AES and Serpent, hope that whatever scheme used is not very different from them).
Some ideas to start from somewhere:
1. As you have used its functions, it is a block cipher? I will assume that it is.
2. What is the key size and the block size?
3. Are there signs that it is using a stack of ciphers? (that is, applying one cipher, then another to the first result and so on)
Click to expand...
Click to collapse
Hello, I've not forgotten about this, just somewhat busy and been using the MetaWatch lately
1. Yes it is clearly a block cipher, and the block size Is 16bytes.
2. I don't know about the key size, it is obfuscated.
3. Doesn't seem like a stack of ciphers. It looks like some overcomplicated AES. But to be honest AES is the only encryption I know of
By the way I think I will upload my current test "manager" source code to somewhere after removing the crypto specific files . Since the protocol itself has been obtained cleanly. Note I've used Qt (not the GUI parts) so it's useless for creating a library; the code will probably need to be rewritten to do so, but it may be useful as "protocol specs".

javispedro said:
Hello, I've not forgotten about this, just somewhat busy and been using the MetaWatch lately
Click to expand...
Click to collapse
No problem. Curiously, I've transitioned from the metawatch to the Gear1 fully (null rom, not pairing with bluetooth to the phone but gear used as a standalone device).
[off-topic]I'm not using my metawatch anymore. I was modifying Nils' oswald firmware to make it prettier and to have some features I wanted (calendar, stopwatch), but it was very inaccurate, supposedly because of missing timer interrupts (the existing LCD drawing routines were too slow). I rewrote the graphics subsystem just to stumble into a known mspgcc bug, and trying to use the new redhat's mspgcc resulted in more problems (memory model, interrupt conventions). In the end I couldn't commit enough time to fix that and my metawatch is now in a drawer[/off-topic]
Returning to the topic:
javispedro said:
1. Yes it is clearly a block cipher, and the block size Is 16bytes.
Click to expand...
Click to collapse
Good. We can at least say it isn't DES/3DES nor blowfish (64 bits block size). Regrettably there are a lot of ciphers using 128-bits block size; that I know: AES, Twofish and serpent.
Perusing the wikipedia there are some more of that size in use: Camellia, sometimes RC5 and SEED.
javispedro said:
2. I don't know about the key size, it is obfuscated.
3. Doesn't seem like a stack of ciphers. It looks like some overcomplicated AES. But to be honest AES is the only encryption I know of
Click to expand...
Click to collapse
I understand that to mean that you cannot use that library passing your own key, right?
What a pity! One way to test for these ciphers would have been to just cipher a known string (i.e. all zeroes) with a known key (i.e. also all zeroes) and compare the result with each of the normal ciphers :-/.
javispedro said:
By the way I think I will upload my current test "manager" source code to somewhere after removing the crypto specific files . Since the protocol itself has been obtained cleanly. Note I've used Qt (not the GUI parts) so it's useless for creating a library; the code will probably need to be rewritten to do so, but it may be useful as "protocol specs".
Click to expand...
Click to collapse
Perfect. I don't need anything more .

Ok, so I've uploaded my SAP protocol implementation: https://git.javispedro.com/cgit/sapd.git/ . It's "phone" side only, ie it can be used to initiate a connection to the watch but not to simulate one. In addition, it's missing two important files: wmscrypt.cc and wmspeer.cc which implement the closed crypto required to "pair" the watch. The most important file is sapprotocol.cc which implements the packing/unpacking of the most important packet types. The license of those files is GPLv3 albeit I'm very happy if you use the information contained on them to build your "Gear Manager" program under whichever license you'd prefer.
For anyone who hasn't been following the above discussion: I've figured out a large part (useful for at least establish contact with the watch and syncing time/date) of the SAP protocol used between the Gear watch and the Gear manager program on the phone. This has been done mostly by studying traces and afterwards talking to the watch using my test implementation above to figure out the remaining and some error codes. The debug messages left by the watch's SAP daemon were also immensely helpful. As long as I understand this is perfectly safe to do, publish and use as I'm in the EU and is basically the same method Samba uses.
Unfortunately, the protocol contains some crypto parts required for the initial sync (subsequent connections require authentication). However, the communication itself is not encrypted in any way, which helped a lot with the process. Because it's impossible for me to figure out whatever authentication method is used, I had to disassemble the library implementing this stuff (libwms.so). This is still OK according to EU law, but I'm no longer to release that information to the public. I'm looking for alternatives or ideas on how to handle this fact.
In the meanwhile, let's talk about the protocol. It's basically a reimplementation of the TCP(/IP) ideas on top of a Bluetooth RFCOMM socket. This means that it's connection oriented and that it can multiplex several active connections (called "sessions") over a single RFCOMM link. Either side of the connection can request opening a connection based on the identifier of the listening endpoint (called a "service"). Strings are used to identify services instead of numeric ports as in TCP. For example, "/system/hostmanager" is a service that listens on the watch side. Once you open a session towards this service (i.e. once you connect to it) you can send the time/date sync commands. In addition to be the above the protocol also seems to implement QoS and reliability (automatic retransmission, ordering, etc.). It's not clear to me why they reimplemented all of this since RFCOMM is a STREAM protocol, and thus reliability is already guaranteed!! So I've not focused much on these (seemingly useless) QoS+reliability parts of the protocol.
Let's start with the link level. There are two important RFCOMM services exposed by the watch: {a49eb41e-cb06-495c-9f4f-aa80a90cdf4a} and {a49eb41e-cb06-495c-9f4f-bb80a90cdf00}. I am going to respectively call those two services "data" and "nudge" from now on. These names, as many of the following ones, are mostly made up by me .
The communication starts with Gear manager trying to open a RFCOMM socket towards the "nudge" service in the watch. This causes the watch to immediately reply back by trying to open a connection to the "data" service _on the phone_ side. So obviously this means that your phone needs to expose the "data" RFCOMM service at least. In addition, the watch will try to open a HFP-AG connection (aka it will try to simulate being a headset) to your phone. Most phones have no problem doing this so no work is required. Of course, if your phone is a PC (as in my case ) then you'll need to fake the HFP profile. I give some examples in my code above (see scripts/test-hfp-ag and hfpag.cc).
Once the RFCOMM socket from the watch to the phone "data" service is opened, the watch will immediately send what I call a "peer description" frame. This includes stuff such as the model of the watch as well as some QoS parameters which I still don't understand. The phone is supposed to reply back to this message with a peer description of its own. See sapprotocol.cc for the packet format.
After the description exchange is done, the watch will send a "authentication request" packet. This is a 65 byte bigint plus a 2 byte "challenge". The response from the phone should contain a similar 65 byte bigint, the 2 byte response, and an additional 32 byte bigint. If correct, the watch will reply with some packet I don't care about. Otherwise the connection will be dropped. It obviously looks like some key exchange. But this is the crypto part that's implemented in libwms.so....
After these two exchanges link is now set up. The first connection that needs to be opened is towards a service that is always guaranteed to be present, called "/System/Reserved/ServiceCapabilityDiscovery". It is used by both sides of the connection to know the list of available services present on the other side. Despite this, you cannot query for all services; instead, you must always know the name of the remote service you're looking for. There's some 16-byte checksum there which I don't know how to calculate, but fortunately the watch seems to ignore it!! I suspect that you're expected to actually persist the database of available services in order to shave a roundtrip when connection is being established. But this is not necessary for normal function. This service is implemented in capabilityagent.cc, capabilitypeer.cc . This part was actually one of the most complex ones because of the many concepts. I suggest reading the SDK documentation to understand all the terms ("service", "profile", "role", etc.).
If everything's gone well, now the watch will try to open a connection to a service in your phone called "/system/hostmanager". Once you get to this message things start to get fun, because the protocol used for this service is JSON! It's implementation resides in hostmanageragent.cc, hostmanagerconn.cc . For example, Gear Manager sends the following JSON message once you accept the EULA: {"btMac":"XX:XX:XX:XX:XX:XX", "msgId":"mgr_setupwizard_eula_finished_req", "isOld":1}. At this point, the watch hides the setup screen and goes straight to the menu.
Well, this concludes my high-level overview of the SAP protocol. Hope it is useful for at least someone!
Things to do:
Personally I'm looking for some traces of the notification service. Ie the one that forwards Android notifications towards the watch. For some reason it doesn't work on my phone, so I can't get traces. I suspect it's going to be a simple protocol so a few traces will be OK. It's the only stuff I'm missing in order to be able to actually use the Gear as a proper smartwatch with my Jolla.
We still need to tackle the problem of the cryptographic parts. Several options: either "wrap" the stock libwms.so file, try to RE it the "proper way", .... I'm not sure of the feasibility of any of these.
Many other services.

javispedro said:
After the description exchange is done, the watch will send a "authentication request" packet. This is a 65 byte bigint plus a 2 byte "challenge". The response from the phone should contain a similar 65 byte bigint, the 2 byte response, and an additional 32 byte bigint. If correct, the watch will reply with some packet I don't care about. Otherwise the connection will be dropped. It obviously looks like some key exchange. But this is the crypto part that's implemented in libwms.so....
Click to expand...
Click to collapse
About that 65-byte bigint... that is a 520-bit key. The usual length of ECDSA keys is exactly 520-bits, so we may have something there: it is possible that they are using ECDSA signing (just like in bitcoin, so there are a lot of implementations of that code).

Not forgotten about this!
Just an status update:
I'm still in the process of defining the API of the C library using javispedro's sources as template.
It's tougher than I originally supposed because the C++ code has a lot of forward-declarations of classes, which is very difficult to map into C. To counter that I have to move elements between structures and I'm not so comfortable with the codebase yet.
And then there is still the hard work of translating the Qt signals/slots to plain' old callbacks... and implementing the bluetooth part using bluez API... and... well, I hope that is all.
Anyway, patience .

I've now had access to a Samsung S2 and thus I have been able to obtain more traces. The latest Git now contains code to connect to the notification manager service, thus allowing to send notifications from the phone to the watch.
That was the last missing part to be able to use the Gear 2 as a 'daily' smartwatch with my Jolla, so I've now also ported the code to run under Sailfish. In fact I'm using this setup at the moment. My first comment is "wow the vibrator IS weak".
You can find a log of sapd's (ie my code) startup qDebug() messages; they may be useful (if you can't yet get your code to run)
I suspect that there may still be some important battery issues because the watch keeps printing error messages about SAP services it can't find on the phone (and instead of sleeping, it starts busy polling for them.... :/ ). It does not seem to happen while the watch is out of the charging cradle, so it may not be important, but not sure yet.
As for the encryption, I'm not sure how to proceed. I could describe the code to you, but that would be risky, because I don't understand what it does. Thus the only way (for me) to describe it would be to pass on the mathematical formulas/pseudocode ... Apart from that, we also have the problem of the keys...
Antartica said:
The usual length of ECDSA keys is exactly 520-bits, so we may have something there: it is possible that they are using ECDSA signing
Click to expand...
Click to collapse
They do use ECDH indeed, and they link with OpenSSL and import the ECDH functions. However it's not clear if they use ECDSA; while the crypto algorithm DOES resemble DSA, I cannot fully identify it.

Congratulations for managing to make it work with the Jolla .
I have finally found a suitable "flattened" class hierarchy as to be able to map your code into C; see the attachs. Basically, I have to move the functionality of SAPConnectionRequest, SAPSocket, CapabilityPeer and SAPConnection into SAPPeer, and then it is suitable for my needs.
javispedro said:
As for the encryption, I'm not sure how to proceed. I could describe the code to you, but that would be risky, because I don't understand what it does. Thus the only way (for me) to describe it would be to pass on the mathematical formulas/pseudocode ... Apart from that, we also have the problem of the keys...
They do use ECDH indeed, and they link with OpenSSL and import the ECDH functions. However it's not clear if they use ECDSA; while the crypto algorithm DOES resemble DSA, I cannot fully identify it.
Click to expand...
Click to collapse
If you manage to describe it using mathematical formulas as in
http://en.wikipedia.org/wiki/Ellipt...ture_Algorithm#Signature_generation_algorithm
it would be perfect, but I reckon that to be able write that you need intimate knowledge of the code and don't know if you have time for that :angel:
And identifying the hash function used would be a problem in itself...
One idea: how about a ltrace so we have the calls to the openssl library? That may uncover new hints.
Anyway, I have a lot of work before me until I need that, so don't fret over it.

Hi there! Any chance that the Gear can (really) work with an iPhone?

gidi said:
Hi there! Any chance that the Gear can (really) work with an iPhone?
Click to expand...
Click to collapse
agreed. Needs iPhone support please.

Antartica said:
Congratulations for managing to make it work with the Jolla .
I have finally found a suitable "flattened" class hierarchy as to be able to map your code into C; see the attachs. Basically, I have to move the functionality of SAPConnectionRequest, SAPSocket, CapabilityPeer and SAPConnection into SAPPeer, and then it is suitable for my needs.
Click to expand...
Click to collapse
You may want to look at the official Samsung SDK docs to match their class hierarchy. I tried to match my hierarchy to theirs, but this happened very late in the development process, so there is some weirdness.
Antartica said:
One idea: how about a ltrace so we have the calls to the openssl library? That may uncover new hints.
Click to expand...
Click to collapse
I more or less know what it is doing with OpenSSL, but that's because I looked at the dissassembly. They use OpenSSL for key derivation (ECDH), but the actual cryptographic algorithm is their own. This 'block cipher' is the part they have tried to obfuscate. Not much, but still enough to require more time than what I have available It is basically a set of arithmetical operations with some tables hardcoded in the libwsm.so binary, so no external calls to any library. The hardcoded tables are probably derivated from their private key, which is most definitely not on the binary. In fact I suspect this is basically AES with some changes to make it hard to extract the actual key used, so that's where I've centered my efforts.
Technically it should not even be copyrightable, so maybe I could just redistribute my C reimplementation of the algorithm, but as with any other DRM who knows these days... and that still leaves the problem of the tables/"private key".
Digiguest said:
agreed. Needs iPhone support please.
Click to expand...
Click to collapse
Well you are welcome to implement one such iPhone program yourself. Will be happy to resolve all the protocol questions you have.
(But please stop with the nagging).

Wasn't nagging at all. Just agreeing with him. I am no programmer so I have to rely on others for answers. Sorry if you thought otherwise.
Looking for to see more work on it though. Keep it up.

Hi there! Nice work on getting Gear2 to work with Jolla.
I'd love to get Gear1 to work with WP8.1. Do you have the code for Jolla
on github/bitbucket so I could give it a peek? Thanks in advance.

Duobix said:
Hi there! Nice work on getting Gear2 to work with Jolla.
I'd love to get Gear1 to work with WP8.1. Do you have the code for Jolla
on github/bitbucket so I could give it a peek? Thanks in advance.
Click to expand...
Click to collapse
javispedro had the sources in gitorius, but they are not there anymore (surely related to gitlab buying gitorius).
I attach a tarball with javispedro sources as of 19 October 2014.
Note that it lacks the files implementing the crypto, so just porting it is not enough to be able to communicate to the gear. OTOH, I know that there are some differences in the protocol between the Android Gear1 and the Tizen Gear2 (if the gear1 has been updated to Tizen, it uses the same protocol as gear2). Specifically, to be able to communicate with both watches, the gear manager package has both gear manager 1.7.x and gear manager 2.x. javispedro's code implements the gear 2 protocol.
Personally, I have my port on hold (I have problems with bluetooth in my phone, so there is no point in porting sapd right now as I would not be able to use it).

Display HASH/Checksum Code Of Files Inside 1st Post, Privacy Encrypt GPG OTR E2E Zip

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

Database Info

welcome