0

標準の iOS AES 実装を使用するために、独自の AES 実装を置き換えようとしています (独自の AES アルゴリズム実装を使用する場合、アプリは FIPS 140-2 に準拠しますか? を参照してください)。)。元の AES 実装は、ソース データ バッファーで暗号化および復号化するため、新しい割り当て/解放はありません。標準の iOS AES 実装では、宛先データ バッファーのメモリを動的に malloc して、データを暗号化/復号化する必要があります。メモリの割り当てと解放が頻繁に行われると、メモリの断片化が発生するのではないかと心配しています。現在のメモリ割り当てサイズは 1K から 8K バイト (iOS ディスク セクタ サイズに応じて、1 つの特定のデバイスで固定されます) になるため、常に 1K の倍になるはずです。ただし、この割り当て/解放は他のサイズのメモリ割り当てと混同され、多くのメモリの断片化が発生するのではないかと心配しています。

これを解決する方法の 1 つは、固定サイズ (実際には sqlite3 ページ サイズ) のローカル変数を使用することです。唯一の問題は、さまざまなデバイスでページ サイズが 1K から 8K の範囲になる可能性があることです (iOS ディスク セクター サイズによって異なりますが、iOS デバイスが 8K に到達できるかどうかは不明です)。したがって、8K ローカルを割り当てる必要があります。コンパイル時にこのサイズを割り当てる必要があるため、毎回バッファします。または、大多数のケースを処理するために、2K などの小さなローカル バッファーのみを常に割り当てることができます (私の iPhone では 1K です)。データ バッファーが 2K より大きい場合は、動的割り当てを使用します。それも理想的ではないようです。

ここは気にするべきでしょうか?たぶん、他の標準的な暗号化された sqlite3 実装は、すでに頻繁にメモリの割り当て/解放を行っているので、ここではそれほど悪くはありませんか? 洞察を知っている場合は、ここでいくつかの光を当ててください。本当に感謝しています。

4

0 に答える 0