Lines Matching refs:code
61 two versions of some parts of the code: one using PSA, the other using the
69 maintaining dual code paths until the next major version. (Note: these
101 `ENTROPY_C`. This requires going through the PSA code base to adjust
106 available in entropy-less builds. (Then code using those functions still needs
127 current strategy is to keep using those identifiers in most of the code, in
142 code anywhere.
170 code size.
171 - Downside: TLS/X.509 code has to be done for each operation.
182 - Upside: changes mostly contained in one place, TLS/X.509 code only needs to
188 changes in application code.
201 the TLS/X.509 code, but a contained change in the application.
206 code, and a contained change in TLS code. (It only supported a subset of
211 support for key isolation, but at the (unavoidable) code of change in
212 application code, while the other requires no application change to get
232 This section presents a plan towards G5: save code size by compiling out our
306 convenient, for example in parts of the code that accept old-style identifiers
318 There are currently two (complementary) ways for crypto-using code to check if a
320 `PSA_WANT_xxx` macros. For example, PSA-based code that want to use SHA-256
321 will check for `PSA_WANT_ALG_SHA_256`, while legacy-based code that wants to
327 if it is, the code want the algorithm available in PSA, otherwise, it wants it
332 code that should always use `PSA_WANT`). For example, for hashes this is the
336 Note that in order to achieve that goal, even for code that obeys
380 to reduce the number of places where library code needs to be changed. It's
382 layers) for facilitating migration of application code.
390 runtime, RAM usage or code size penalty), for example just a bunch of
415 Since this would still represent a non-zero cost, not only in terms of code
425 the rest of the code is structured, it may be worth holding the key data in