How insecure is AES-128-CTR to encrypt any kind of data using the Ethereum keystore file format? I am using the Ethereum keystore file format to encrypt any other data such a plain text or JSON.

Here is an example of pseudocode of the implementation:

MY_PASSWORD = "VeryDifficultPasword432131!@!#%"
MY_TEXT = "This is my secret text"

iv = randomBytes(16)
kdfparams = {
    dklen: 32,
    n: 262144,
    r: 1,
    p: 8,
    salt: randomBytes(32)
}
key = scrypt(MY_PASSWORD, kdfparams)
ciphertext = encryptCipheriv("aes-128-ctr", MY_TEXT, key, iv)
mac = sha3(key[16:32], ciphertext)


With this code I can generate the keystore file that looks like this:

{
    "crypto" : {
        "cipher" : "aes-128-ctr",
        "cipherparams" : {
            "iv" : "83dbcc02d8ccb40e466191a123791e0e"
        },
        "ciphertext" : "d172bf743a674da9cdad04534d56926ef8358534d458fffccd4e6ad2fbde479c",
        "kdf" : "scrypt",
        "kdfparams" : {
            "dklen" : 32,
            "n" : 262144,
            "r" : 1,
            "p" : 8,
            "salt" : "ab0c7876052600dd703518d6fc3fe8984592145b591fc8fb5c6d43190334ba19"
        },
        "mac": "102aedfe8c308c735a76295f9908d9b7de40fb1c07f2f71e05de7a0b2f323a12"
    }
}


This is the standard file that store millions of dollars of people in Ethers.

Questions:


Is this secure? 
If not, why?
If yes, is also secure
encrypting plain text or JSON (no hexadecimal format)?
Is secure to set a smaller kdfparams.n?




Edit:
To clarify why I'm asking this is because another person said this:


  This is not secure at all. This implementation contains many basic errors. One example is using
  an insecure random number generator, which utterly destroys the
  security of the encryption. Another is using AES-128-CTR without
  authentication.
The worst purely cryptographic weakness is the password (1). The worst (and much worse) practical weaknesses are likely to be in the implementation (6) (7), and those (4) (5) that cryptographers dismiss as out of scope of encryption (the question's only stated objective).

Candidates for weaknesses, from cryptographic (but still to consider) to implementation:


The password: it is hard to remember a password with over about 48 bits of entropy (that's about equivalent to a 16-digit number, like 3141592653589793 or 2718281828459045, and more than envisioned by the obligatory XKCD). Using N=262144=218, r=1, p=8=23, buys at the very least 18+3+1=22 bits (see this) compared to a straight SHA-256 hash followed by AES-128, I guess about 32 bits stronger, thus the key might be about 80-bit good, which is not entirely unbreakable by brute force but still quite secure.
AES-128: this has a 128-bit key, no known purely cryptanalytic attack better than brute force, and is thus much better than the password.
CTR mode: with AES's 128-bit block, the only way key-stream reuse could kick in would be a bad random number generator for the IV (see 6)
The size of the plaintext can be effortlessly deduced from the size of the ciphertext. This is explicitly not a theoretical weakness of encryption, since length is excluded from what a cipher is supposed to hide about plaintext. However, that can be a practical weakness. Say analysis of ciphertext concludes that it is 17267095423 octets; and there exists, somewhere in the prosecution's exhibits a file with exactly that size, demonstrably predating search and seizure of the ciphertext, and which mere detention is illegal.
Lack of detection of (intentional or accidental) ciphertext alterations, corresponding to predictable alteration in the plaintext: again this is explicitly not a theoretical weakness of encryption, but can allow some attacks if the adversary can alter the ciphertext (example: if the plaintext is an executable or PDF with a known fraction, that can allow changing what the executable does to about anything, or make the PDF display as about anything). Authenticated encryption (AES-GCM..) solves that.
Random number generator: if this is bad, or worse gets more or less stuck (obligatory XKCD and Dilbert which turn to reality all too often), that would enable recovering plaintext in many scenarios, including repeatedly enciphering different English text or email addresses with the same password.
A side channel, that is broadly speaking unforeseen or unmitigated leak of information in the implementation or usage context. There are so many:


Password recovery from the password holder by exploiting a procedural goof (password on a postit note, master password list), rubber-hose cryptanalysis (obligatory XKCD), legal variants (involving use of expressions on the tune of contempt of court), bribery, chemical impregnation..
Password recovery by shoulder surfing, key logger (software or hardware), camera, microphone (a good audio capture of the sound of keys when entering a password leaks a lot of info about the password, especially when correlated with known keyboard entry by same operator under same conditions)..
Straight compromise of plaintext as shown on screen (with TEMPEST variants of that), printed, while transmitted to a printer or remotely accessed by a network, or just "temporarily" stored..
Straight compromise of the OS of the machine doing encryption or decryption (getting temporary root access is enough, means in 7.7 are game to the attacker).
Cryptanalytic side channel at a distance, including DPA and electromagnetic variant DEMA, and hypothetically timing if the machine doing the encryption/decryption is accessed by a network and does not use AES instructions.
Cryptanalytic side channel from a process running on the same hardware (including another VM), including cache-based targeting for AES when not using AES instructions, or more general ones (Meltdown, Spectre) which are all the rage these days.
Exploitation of various software bugs; that's huge.