actualNoteContentPart: ## Changing a Standard Note to a Vault Note
  Vault Notes disable a number of features - like sharing and public links - that otherwise rely on the server having access to the user's Standard Key. To ensure that the user doesn't lose access to some of their Vault Notes due to a typo, a verification value is stored in the database that allows the client applications to check that the same Vault Password is used for all Vault Notes.
  
  The client requests Vault Note Key setup parameters from the server. The server responds with the Vault Key Challenge and two randomly generated Initialization Vectors. The Initialization Vectors will be used by the client when encrypting the Note Key and the Vault Key Challenge.
  	If this is the first time the user has changed a Standard Note to a Vault Note, the Initialization Vector used when encrypting the Vault Key Challenge will be randomly generated at this time. Otherwise, the Initialization Vector previously used when encrypting the Vault Key Challenge will be returned.
  The client encrypts the Vault Key Challenge with AES-256-CBC using the Vault Key and one of the returned Initialization Vectors to produce the Vault Key Response.
  The client encrypts the Note Key with the Vault Key and one of the Initialization Vectors to produce a Vault Note Key.
  The Vault Key Response and Vault Note Key are sent to the server with the corresponding Initialization Vectors.
  The server [uses BCrypt to hash]()  the Vault Key Response and concatenates the Initialization Vector to produce the Vault Key Verifier. The Vault Key Verifier is stored in the database [encrypted with AES-256-GCM]()  using a key that the database server does not have access to and a randomly generated Initialization Vector
  The server replaces the stored Standard Note Key with the supplied Vault Note Key
  
   
  # Appendix: End-to-end (E2E) encryption
  
  As described in this document, Standard Notes in Amplenote are **not** end-to-end encrypted by default. This allows for a number of key features, such as note sharing; note publishing; server-side note exporting; password reset - and more - which are not currently possible with our end-to-end encrypted Vault Notes. However, all notes **are** encrypted before they leave your device **and **they remain encrypted at-rest on the Amplenote servers.
  
   
  # Appendix: Attachments
  
  The astute reader may have noticed that attachments - such as images and PDF documents - have not been mentioned in this document. Attachments are not encrypted - even in Vault Notes - rather they are uploaded to a location that is described by a [random 122-bit number]()  and the identifier of the note where the attachment was originally uploaded. With knowledge of a note's identifier, there are 5,316,911,983,139,663,491,615,228,241,121,378,304 possible addresses at which an attachment could be found, leaving an infinitesimally small chance of guessing an attachment's address. A more likely scenario is accidental disclosure of the attachment address, for example by referencing an image in an email or on another website. Encrypted attachments are on the roadmap for Vault Notes, and the feasibility will be evaluated at that point for Standard Notes as well.
  
   
  # Glossary
processedNoteContent: ---
  title: Amplenote Security Design
  headers: ## Changing a Standard Note to a Vault Note
  ---
  Changing a Standard Note to a Vault Note
  Vault Notes disable a number of features - like sharing and public links - that otherwise rely on the server having access to the user's Standard Key. To ensure that the user doesn't lose access to some of their Vault Notes due to a typo, a verification value is stored in the database that allows the client applications to check that the same Vault Password is used for all Vault Notes. The client requests Vault Note Key setup parameters from the server. The server responds with the Vault Key Challenge and two randomly generated Initialization Vectors. The Initialization Vectors will be used by the client when encrypting the Note Key and the Vault Key Challenge.
  If this is the first time the user has changed a Standard Note to a Vault Note, the Initialization Vector used when encrypting the Vault Key Challenge will be randomly generated at this time. Otherwise, the Initialization Vector previously used when encrypting the Vault Key Challenge will be returned.
  The client encrypts the Vault Key Challenge with AES-256-CBC using the Vault Key and one of the returned Initialization Vectors to produce the Vault Key Response.
  The client encrypts the Note Key with the Vault Key and one of the Initialization Vectors to produce a Vault Note Key.
  The Vault Key Response and Vault Note Key are sent to the server with the corresponding Initialization Vectors.
  The server [uses BCrypt to hash]()
    the Vault Key Response and concatenates the Initialization Vector to produce the Vault Key Verifier. The Vault Key Verifier is stored in the database [encrypted with AES-256-GCM]()
    using a key that the database server does not have access to and a randomly generated Initialization Vector
  The server replaces the stored Standard Note Key with the supplied Vault Note Key 
  Appendix: End-to-end (E2E) encryption
  As described in this document, Standard Notes in Amplenote are not
   end-to-end encrypted by default. This allows for a number of key features, such as note sharing; note publishing; server-side note exporting; password reset - and more - which are not currently possible with our end-to-end encrypted Vault Notes. However, all notes are
   encrypted before they leave your device **and **they remain encrypted at-rest on the Amplenote servers. 
  Appendix: Attachments
  The astute reader may have noticed that attachments - such as images and PDF documents - have not been mentioned in this document. Attachments are not encrypted - even in Vault Notes - rather they are uploaded to a location that is described by a [random 122-bit number]()
    and the identifier of the note where the attachment was originally uploaded. With knowledge of a note's identifier, there are 5,316,911,983,139,663,491,615,228,241,121,378,304 possible addresses at which an attachment could be found, leaving an infinitesimally small chance of guessing an attachment's address. A more likely scenario is accidental disclosure of the attachment address, for example by referencing an image in an email or on another website. Encrypted attachments are on the roadmap for Vault Notes, and the feasibility will be evaluated at that point for Standard Notes as well. 
  Glossary
noteTitle: Amplenote Security Design