Importing from LastPass, encountered the 10k character max limit. Found the offending records, removed them, successfully imported the rest.
Here comes the fun part: I then split the offending records into <= 9000 char, attempted to create new records for them individually, but I’m still getting the 10k error when pasting some of them in. I can plainly see each has well under 10k char (wc -m ), yet Bitwarden tells me it’s over 10k. Am I missing something?
Thanks
The character limit applies to your data after it’s been encrypted. Our encryption algorithm increases the length of your data, so 9,000 characters unencrypted will exceed the 10,000 limit after encryption. It seems you can use 7,500 characters as an approximate limit for unencrypted text - see the recent discussion here: The field Notes exceeds the maximum encrypted value length of 10000 characters (when it is false) · Issue #1618 · bitwarden/browser · GitHub
Ah, great, makes sense, thanks for clarifying!
Is there the option to increase this character limit?
This for sure is the biggest issue with bitwarden. Limited notes.
Does BitWarden compress the data before encrypting?
No, we don’t compress encrypted strings.
Out of interest I created a secure note by repeating the characters 1234567890 until I got the error about about “the field note exceeds the maximum encrypted value length of 10,000 characters”
The maximum BW note size is 7,439 characters (using the method I described)
I then encrypted the same message with GPG/PGP (which I know compresses before encrypting) and the result is just 227 ascii characters
That is 227 versus 10,000, both AES256. Maybe BW should compress before encrypting to help alleviate the problem of the restriction of the note size
password is password LOL
-----BEGIN PGP MESSAGE-----jA0ECQMCawdQ9PkaBTv/0o0BQke9ab/HBWuFBD/nuZ66pqYqNQgOfPjiKhbwXiMo
lU6KeG0wLIEGfDtL5TbHZ4Z0mzx6b+zLDYEqngL9xvtHOISlhP/SYfNx2ritrWn7
uQBYODSLUGf3HJaOnpZHZZtK9L5WnlIQqsdrVQDaHVYxuc0A6ujLUY/sAbYITR4t
nEQz9QG9egPAsDNkqYA=
=Pt8T
-----END PGP MESSAGE-----
This is not a bad idea, but your example is misleading:
Because of the way compression algorithms work, repeated patterns compress much more efficiently than other data (for example, I can create a “compressed” representation of the string 1234567890 repeated 750 times, simply by encoding this pattern as 750X1234567890, thus reducing the data size from 7500 bytes to 14 bytes).
Below is a more realistic experiment, using an online text compression tool. In each case, the input text consisted of 7500 characters:
| Text Source | Compressed Size | Compression |
|---|---|---|
Repeated “1234567890” |
68 bytes | 99% |
| Lorem Ipsum pseudo-Latin | 1896 bytes | 75% |
| Moby Dick Chapter 1 | 4824 bytes | 36% |
| Random ASCII characters | 7724 bytes | –3% |
The Moby Dick example suggests that for English text, it may be possible to store a Secure Note that is up to 12k in length. However, for storing encryption keys and other random data, you would be better off not using any compression (since the compression algorithm actually expanded the data size).
The character limitation of Bitwarden Login not field is still 10000 characters ? (I have not seen something about the limitation in the FAQ)
It is possible to use bit of markdown or it is strictly plain text ?
@Christop Yes, the character limit for Notes fields is still 10,000 characters after encryption. Markdown is not supported.
I’m not sure. My best guess is that encrypted strings are usually already quite small (the size of a single field, e.g. a username or password) so compression wouldn’t yield much benefit in exchange for slowing down decryption (which is already quite intensive for large vaults).
I might be wrong on that though, or there might be better ways to do it - this is just how we do it today.
Another reason not to compress before encrypting is that if attempting to compress a string that is random (e.g., a password, or a note containing an encryption key or recovery code), then compression algorithms will typically return an output that is larger in size than the input. For the same reason, it would not be a good idea to compress ciphers after encrypting.
