Practical BCrypt plus XOR encryption for small messages This is a practical solution available and potentially useful to everyone, so please give some leeway not banning this question. Details are at the end, but here is the question: 

How secure is the following encryption approach? 

In few words, it uses BCrypt to hash passwords. BCrypt is then used repeatedly on the result of prior hashing, and all the hashes are concatenated to make a Key as long as the Message itself. The encryption is a simple Key XOR Message. Details are below:

Note. BCrypt salt is hard coded and is removed from the resulting hash, when applying BCrypt function.

Encryption


  
  Message = Any Ascii128 text
  Pass1, Pass2, Pass3, Pass4, Pass5 = Ascii128 based 5 password fields 
  Password = Pass1 XOR Pass2 XOR Pass3 XOR Pass4 XOR Pass5
  Checksum = {
  
  
  ShortMessage = Message 
  Repeat while ShortMessage is longer than 50 chars,

ShortMessage is cut in half, and the halves XOR to get new ShortMessage

  ChecksumBase = fromBase64toAscii128(BCrypt(ShortMessage XOR Password))
  Checksum = ChecksumBase.substring(1 to 4)}
  
  Key = {
  
  
  LongKey = BCrypt(Password + Checksum)
  CurrentKey = LongKey + Checksum
  Repeat while LongKey.length &lt; Message.length :

CurrentKey = BCrypt(CurrentKey)
LongKey = CurrentKey + LongKey

  Key = fromBase64toAscii128(LongKey)
  }
  
  SecureCode = Checksum + (Message XOR Key)
  SafeMessage = fromAscii128toBase32(SecureCode)
  


Decryption


  
  SecureCode = fromBase32toAscii128(SafeMessage)
  CheckSum = SecureCode.substring(1 to 4) 
  Password = see in Encryption      
  Key = see in Encryption       
  Message = SecureCode.substring(from 5) XOR Key
  CalculatedCheckSum = see in Encryption
  Integrity check = recovered CheckSum must match CalculatedCheckSum
  


Please, rate the safety of the approach on a scale from "kids safe" to "unbreakable", as quite a few people use the program, and want to know how secret their secrets are.

There is a link from the project's page to this question, so your answers will be a validation of the project for better or for worse. 

The program can be run here. It is on GitHub and cannot be maliciously altered without a public record of the change. (There are no plans for change as this would compromise current user base).

If someone would care to take a look at the JavaScript, to ensure it does what is declared and put a comment in here, this would be awesome.
No that is not secure.

If someone knows the first part of the message (27 characters I think), they can extract the first part of the LongKey and regenerate the rest of it, WITHOUT THE PASSWORD.

The so called checksum is not cryptographic, not even as robust as CRC32, if you have a 100 character message with the first and 2nd half the same, the checksum is 0. You can also swap message halves without changing the checksum. And worst of all, the checksum is both unencrypted and gives away information about the plaintext, assisting in a plaintext recovery effort.

Trying to use the checksum like a salt as part of the bcrypt input is ineffective, and if the password is long enough, is ignored, making all of LongKey first blocks identical, allowing immediate breakage of all messages that used the same passwords.

The passwords being XOR'd together makes the combined password length only as long as the longest one, and might help prevent a dictionary attack but does not increase entropy like concatenation would.

If you want me to rate from "kids safe" to "unbreakable", you might have gotten it up to "kids safe" if almost every step of the way wasnt done incorrectly.